One Game A Month: February

Now that I have released January’s game to the wild, it is time to begin thinking about my next game. As the month went on, I decided that I did not want to finish my LD48 #24 game from last August where the theme was evolution. I like the game, and I made a lot of neat additions to it, but I think in the end it’s just not going to be fun for very long. The aliens had a bunch of different traits and as you killed them the ones that were most successful in surviving and damaging your ship had their traits passed on to the next round. The problem is that there isn’t much strategy with the player. They click and shoot. Click and shoot. Eventually the aliens would become harder but the strategy remains the same. However, if there were multiple different approaches the player could use to defeat the aliens, they would be forced to try something new as the difficulty ramped up until they found something that worked better. This, in turn, would cause a different set of traits to bubble up to the top and start the difficulty increasing again. The way that game is now, it would need some major remodeling and a rethink of one of the basic rules I had when I started, a static firing location. It makes more sense to start over, and I am not ready for that.

I worked throughout the month on LS-MAN bouncing around to each of the different aspects of development. Coding of many features, but also graphics, sound and UI. This meant that the game grew in many different directions, at roughly the same time. On one hand, when I got bored I just changed gears. On the other hand, it took me until week three to really have a playable game. I have read #1GAM father Crister Kaitila’s ‘McFunkypants Method‘ and think that for February I will try to follow them. The one I want to attempt primarily is to get a simple working game completed in the first week using only placeholders for art and sound. This would mean that I have the rest of the month to add all the cool features and polish.

One of the other tips is the “save points” where you have what you could consider a deliverable. The first deliverable is the working game with placeholders. Not overly exciting, but it’s a game. As you add features you’ll come up with other save points. These make for great moments to tuck the game away in a safe place. Should everything crash and burn, you’ll have something to fall back upon.

I have an idea for a game to be completed later this year, but it is probably too much work for one month. I was trying to figure out how to break it into pieces and realized that I could implement one aspect of the game now as it’s own stand-alone game and use this module later when I work on the game with the bigger picture. February is also a short month, so something with less work would be a plus.

One part of may January game that I really enjoyed was showing my four and a half year old son my progress. He would constantly want to see the game run and watch the creatures explore the maze while LS-MAN gulped the pellets. I drew some concept art for the creatures; he looked at them and did his own versions. It was easier to get him ready for school on days when I had something new to show him, like a newly animated creature or pellets. I thought it might be neat to make something that he could play, so for this month’s game I will likely be making a shooting gallery, not unlike those found in older arcades, carnivals and boardwalks. He’s really good with intuitive touchscreen UI, but this is the desktop so simple point and click with the mouse would be a great introduction. This would then become one aspect of a future game.

First stop, however, is to set up source control that I lost when I upgraded machines. I also want to yank out some of the utility classes that I have created over the past couple years into their own library so I can continue to add to it as the year goes on. I just updated FlashDevelop from 4.0.2 RC2 to 4.2.4 and so far so good!