Zooming Out

From discussions last week, it seemed like a "Player" object is something that people can easily grasp.   The player object would hopefully address the adjustable difficulty and score keeping features I discussed in last week's post.  In attempting to figure out where to put the Player object, it became apparent that I needed to zoom out and do some things on paper before I dive head first into coding it.

I started by considering what goals of having the Player object and other tools I will be creating.  I am supporting general game creation, but the physical therapy games are of special significance.  

In the case of the physical therapy games, it makes sense to have games that are already built which are easily modifiable with custom theming and variable difficulty.  This would allow caregivers to gain the benefits of the game customization without having to invest a lot of time in game creation.  From this step, the users could learn the knowledge they gained from working with existing games to create their own.

In order to facilitate this kind of learning, it's important that the example games are well organized and easy to understand.  I am still trying to decide how much of that organization should be enforced by the tools and how much of it should be that the example games just serve as a good model to follow.  For instance, should the tools force difficulty settings to be in the same place? Or should the example games just put them all in the same place and hope that people do the same?

Another aspect of this is that I need to make sure the basic tweaks to a game are very apparent and easy for the caregivers that only want to make minor changes and aren't necessarily interested in creating an entirely new game.

In an effort to come up with a good way to organize game concepts, I looked at the games I created so far as well as some other well known games and described them in plain English.  By writing out how the games worked in English, I hoped I could find some similarities which could be used as a way to organize components of all games.

I discovered four categories that the statements describing the game fell into: intial game setup (the helicopter starts on the ground) , game world changes (the helicopter moves to the right, the birds move up and down, balls are thrown at the wolf), player input (the player pushes a key), and events (the helicopter collides with a bird, the pose matches in simon says).  I believe it makes sense group code pertaining to these categories together.

These categories are pretty abstract, so in order to make them more concrete and see if they hold up, I will be going through the games I discovered and imagining ways to change their code to fit more readily into these categories.