Amazing Machine

REDACTED

Please disregard my application since I have decided to not participate in GSoC this year. Thank you.

Ben Johnson

Dr. Wrinkle's Amazing Machine

Amazing machine is designed to be a creative game where players are trying to make bizarre machines while at the same time improving their math skills. The game will:

• allow players to feel creative
• teach/train players math while having fun
• give players a more creative view of math, where solving the problem is about creating the right function (or string of functions)

Core Gameplay

The point of amazing machine is for the player to construct one machine out of a string of the following 2 core components:

• gadgets that each have a specific purpose and unique input/output (i.e. mathematically, they take an integer as input and return an integer as output, or, in game terms, a gadget that takes logs and turns them into hats). These do not perform math operations, all they do is take input and return output. to the player though, they do take one object and turn it into another. All gadgets have a specific numerical input and output but their actual object input and output will be variable.

• widgets that connect to gadgets and other widgets. The input and output of widgets is completely dependent on the output and input of what it is connected to. Basically, widgets just apply math operators to their input which affects their output. For example, lets say there are two gadgets, one which outputs an 8 and the other with takes a 3 as input. These two gadgets could be connected by a "-5" widget which will take the output value 8 from the first gadget and convert it to the input value 3 of the other. It should be noted that widgets do not affect the "object" they took as input, they just pass the onjects from one gadget to another. Only the integer value associated with the object is changed.

Every unique combination and ordering of the gadgets will produce an entirely new product, like a machine that turns logs into 1 dozen chickens, or a machine that turns tires into giant stone statues. This is the thing that will make kids want to play the game: to see what kind of crazy machines they can make.

The Play Area

The on screen area is made up of 2 main sections:

• the work bench, where the player sets out and connects up all the gadgets and widgets.
• the tool box, there all the individual gadgets and widgets are laid out.

There are 2 buttons on the screen:

• "Build" which attempts to build the current machine. If there are less than 2 gadgets, there is no ending gadget, or the gadgets are improperly connected by their widgets (i.e. the math between two gadgets doesn't work) then the build will fail and the player will be told/shown why.
• "Run" will light up if the machine builds successfully. When pressed, the machine will begin to run through to the end and once the end result is made the player will be praised and asked if they want to continue working, start a new project, or quit.

The player can choose to lay out all their gadgets first and then connect them later, or go one step at a time from gadget to gadget. Both the work bench and tool box should be scrollable areas so the player should always have room enough for their machines.

Game Flow

At the start of a game the input/output values of the gadgets and the functions associated with the widgets are randomly generated, so that the math is different every time while some of the gameplay may not. The player must first lay down their starting machine and then decide which next gadget to use. every 2 successive gadgets must be connected by at least one widget, and so the order in which the player lays down gadgets doesn't matter so long as they are connectible by widgets. The player continues this until they lay down their final gadget and hit the "Build" button, their amazing machine builds fine, and they run their amazing machine. The player may then chose to start a new machine, continue working on the current, or quit the game.

The Math

The math in Amazing machine is simple integer + - x / math. It would be interesting to have a hard mode that dealt with rational numbers, but for the time being, the simple version will do. All the player will have to do is figure out which operations to use to turn the output of one machine into the input of another using the provided operations. This should provide little to no challenge to students experienced with math, moderate challenge to students currently learning this math, and great challenge to students inexperienced or just starting this kind of math. The recommended age for this game is 5-12

The Win/Lose state

The player wins by creating a functioning machine. This is not an end-game by any means. The player may continue working on their current machine or start a new one at any point. As far as losing, if the player cannot figure out the math necessary, then they will be shown how to do it (time permitting). If the case comes up where it is impossible to complete with the widgets remaining, then the player will be notified. If the situation comes up where it is impossible to complete because of the randomization, then the randomization will be dropped. In fact, the first prototype of the game will probably use static attributes for the widgets/gadgets. As stated previously, the major goal of the game is for players to have fun and be rewarded for doing math.

Formal Proposal

Name: Ben Johnson

Project: Dr. Wrinkle's Amazing Machine - A game in Python for the OLPC

Project Synopsis

This proposal is to create a small game in Python that allows the player to improve their math skills in a fun and creative way. Intended for children ages 5-13, this game will let them build strange machines out of various gadgets, which receive integer input and return integer output, and widgets, which apply mathematical operators to these input.output, like taking an output of 5 and applying "+7" to it. Along with the mathematical aspect, these gadgets and widgets take certain objects like logs, hats, baseballs, etc. and turn them into something other object. once all the gadgets and widgets have been put together, they can be built into one big machine which will turn the very first input object into the very last output object, thus forming an amazing machine that, for example, turns 5 hats into 12 chickens. The goal for this is to help children develop their math skills and give them a more creative view of math.

Benefit to the OLPC Community

The benefit OLPC receives form this project is that:

• OLPC gains a fun math game for a wide range of players that helps improve math skills and may be more approachable to girls and students starting math, because it is primarily designed to be a fun game.
• Game designed by an individual with 2+ years focused student-level game development experience, and 3+ years game design experience with a passion for game design and innovation.

Project Deliverables

• First, the definition of both gadgets and widgets, all their associated functionality, as well as the definition of an input/output object. Also, initial graphical representation of the play are, including definition of the tool box and the work bench, and placeholder art for most objects and play are. The player will be able to:
  • Start the program
  • see the play area and any objects within it
  • place objects in the tool box onto the workbench.
• Second, interactions between widgets and gadgets will be defined, more placeholder art, better if possible, and an initial set of widgets, gadgets, and objects all with their values defines and ability to interconnect. If time allows, initial sprite animations here would be nice too. At this point the player will be able to:
  • pick widgets and gadgets out of the tool box and lay them out on the work bench and have them working together. If object snapping together is not yet supported, then they will have to be within a certain pixels width away from one another.
  • see the math result of the widgets and gadgets connected
  • see warnings if connections from one gadget to another will not yield the correct value.
• Third, the play are will now be well defined, enabling the snapping together and apart of different gadgets and widgets, be able to build and run their machine with the appropriate buttons. much more refined animations and better art if possible. A decent amount of player help should also be featured here. The player will now be able to:
  • play through a complete game
  • build and run machines built from widgets and gadgets in their toolbox which will have static data that does not change from game to game.
  • snap widgets and gadgets together on the work bench.
  • when a machine runs, they will see it animate, see an object put in one end, and watch it come through to the other side and see all their math along the way get executed.
  • player can now issue commands to attack from one map territory to another with some number of untis and the conflict can now be resolved. the player can queue as many attacks as he/she has territories controlled, but each attack must be against a territory that has not yet been attacked this turn.
• Finally, with what time remains, I would focus on polishing and refining the animations and player help. Polishing will entail:
  • better art and animations
  • prettier player help.
  • play testing
  • game flow tweaking such that the game is easy to pick up and fun to play.
  • etc.

Project Details

For everything you need to know about my current vision for the game, please see the OLPC wiki page Amazing Macine.

Project Schedule

My core principle in this schedule is giving myself one month for each deliverable with a decent amount of learning time built in to each, since I have no previous Python experience. As soon as my final exams end, April 25th, there will be 2 weeks of devoted Python research/OLPC feature familiarity. If things progress quicker than this then that is great, but there is currently time built into the schedule such that even if a task goes longer that the personal deadline for every task, I should have the three major deliverables complete by early April, which is my overall personal completion deadline. It should also be noted that I will be taking one summer class and working on my own game for some of my time, so I cannot make the assumption that my time will be spent "full time" on the project, but I initially estimate that as of 2008-04-26 4-6 hours a day will be spent working on the project, not including weekends.

• 2008-04-14 - 2008-05-26: Community/Mentor bonding, Python language, OLPC feature research. First deliverable prototyping will begin as soon as possible because the sooner the core tech is done, the sooner cool features and polish can be added. But, that said though, a good deal of language research will have to be done before any prototyping can begin. It should be noted though that finals end 2008-04-25, so that is the point when I will begin my 2 week Python research period.
• 2008-05-10 - 2008-06-10: work begins on the first deliverable. Hopefully I will be able to start coding right on the 10th, but there is no guarantee and I may not have gotten to do all the research necessary before the 10th, so this could push my code start date as far as May 17th. Currently June 10th is my personal deadline for first deliverable but should be no later than mid June
• 2008-06-11 - 2008-07-11: with a base prototype in hand, work begins on widget and gadget interaction and startup definition, etc. If the previous prototype takes longer than expected, the start date for this deliverable could get pushed to June 18th or so, but my personal completion date for this deliverable is July 11th with a late completion date of July 20th.
• 2008-07-12 - 2008-08-12: finally, with most of the key elements intact, work begins on the finishing elements to make it a fully functioning and decent game. As with the previous task, some prep work will probably be involved. If work up to this point has taken longer than expected this doesn't get started until late July, August 12th will remain a hard end date unless otherwise advised by mentor(s). This is because it is more important to me to have a good block of time to test and polish other things then it is to rush the final stages.
• 2008-08-12 - 2008-08-??: whatever time is left over will be spent polishing gameplay and art/animations.
• 2008-08-?? - 2008-09-1: whatever wrap-up is required of me by mentors/Google/et al. can be done in this time frame.

Risks

• No prior knowledge of Python or scripting: I have no prior knowledge of Python or scripting languages in general. I have over 4 years of programming experience so I do not foresee any giant problems, but my general method of learning new languages is to buy a good book and read/work through it, implementing any programming exercises I can work with. In this case, I have a good python code base to learn from and view the ruleset as one big programming exercise. I think I can be ready to start programming within 2 weeks from the end of my finals on 2008-04-26, but if not, the latest start time I can foresee is 2008-05-24. If this occurs, some features of the map may be cut, like continents, and possibly less work may be put in on combat. This is so that I may make a 2008-08-12 pencils down date.
• Since I have never worked with the OLPC or the XO before, there is obviously a need for time to be allocated to understanding the What there might already be on the XO that I can use to expedite development. This is also exaggerated because I will have less than a months worth of experience with Python. I do not anticipate any humongous barriers to my learning, but if so, it may mean less time put into the art for the game, since this is the only area that can really be filled in later by someone else. This is a scenario I would rather not come to, but if it does not look like I can make my 2008-08-12 pencils down date, then art would be the first thing to go.

Personal Background

My Name is Ben Johnson. I am 26 and originally from San Diego, CA but now living in Seattle, WA. I spent 5 years at Point Loma Nazarene University getting my B.A. in Psychology with a Minor in Computer Science. I basically accomplished the first two years of the B.Sc. Computer Science program in my last two years at the school.

I am currently attending DigiPen Institute of Technology and am enrolled in the B.Sc. Real Time Interactive Simulation program that is entirely focused on game development. I have literally spent almost the last 3 years making games from the ground up in C/C++ with a different team each year along with working towards what is basically 5 year B.Sc. Computer Science program. Im am currently finishing my 3rd year and am on track to graduate this coming year.

Personally, I am very much devoted to game design and have spent my three years at DigiPen learning game design and honing my skills in it, as well as my programming skills. I would say that I am a good game designer and am a proficient coder. I believe what gives me an edge is that I actually have experience implementing game systems in C++ along with all the traditional knowledge required of a B.Sc. CompSci student. Although, I will say that, although I am trained as a programmer, I think more naturally in terms of game design and when problem solving, I tend to resolve things better when I can put it in terms of game design.

If you are at all interested in my resume and portfolio of previous code and design work, it all can be found on my resume web page here.

Community Feedback

Please leave your constructive feedback here, I greatly appreciate it.

About Me

• My Little Piece of the Internet (Bio)
• My Resume