Simple RPG Postmortem

For the Mini-Ludum Dare#38, the Charity Game Jam, there was a theme of NES-Style games with the restricted size and palette of such a machine.  I created a simple RPG, creatively named Simple RPG. So lets have a mini-postmortem of that challenge.

What went wrong

The biggest mistake made with this challenge was going with such an ambitious project. Creating a role-playing game relatively from scratch is a huge undertaking even when you have lots of time. I suppose that if I had an existing RPG engine that I was building on, this would have been a different matter. But if I had started with an existing RPG engine (such as my Coffee Quest 4 engine) then I wouldn't be creating a game but instead would be making a mod.  Still, when I think of the NES, my thoughts immediately go to RPGs as that is the type of game I gravitate towards. Had I not have created RPGs in the past and had an extremely clear vision in my mind this project would have been a failure. As it turned out, I ended up with a playable game though one that clearly  needs balancing and more content.

The second mistake with this project was using a very early build of my GameJam library. This is a library that I am developing  for use in future GameJam competitions as I am planning on participating in GameJams frequently over the next few years. Partially because they are fun, but mostly so that I will have content for my Blazing Games site while developing some of the larger-scale games that keep being put on my back-burner. The problem with the library at this time is that it still is missing a lot of functionality, has bugs, and still hasn't had it's API locked down. Lack of any type of console support was a big issue as I ended up spending the first few hours of the competition creating a console as the RPG menus rely on console-text. The few hours lost to not having this code could have been spent on balancing the game and improving the artwork.

What went right

While the library was one of my mistakes, it was also one of the things that went right. By having a library of common game functionality, I was able to save a number of hours when it came time to creating the game maps. Ultimately, I want to get my GameJam library to the point where it has the power of the game-creator programs that are available yet still being flexible code that I have created. As it has been a long time since I have played a NES RPG, I couldn't remember if it had smooth scrolling so opted to make the map movement more chunky. Now that I think about it, I probably could have taken advantage of my smooth-scrolling maps. Still, having major functionality  readily available in a library makes rapid development much easier.

Finally, keeping the scope of the game down as much as was reasonable was a huge help.  Multiple multi-level dungeons, stores, a vast array of equipment, and side quests would have been nice to have but was unrealistic with only 48 hours of real time. By limiting the world to only 3 maps, I knew that the game was a reasonable size to finish within the short development time. Even when you have an overly-ambitious project, or rather specifically when you are biting off more than you can chew, keeping the scope of the ambition as small as you can get away with is always a good idea. After all, you can always add more content in the future if the project is successful, but when you throw away partially created material you are throwing away the time invested in that material as well.

Eating Trees

While it is clear that Alien Bugs was inspired by the classic arcade game centipede, the games are quite different. Instead of the worms-style long insect bouncing off of mushrooms, these are giant individual insects who eat trees while bouncing off of each other. Instead of just being able to shoot up, the player is able to shoot in any direction. And the biggest difference is that the playing area is larger than the screen so the player has to hunt down the insects. Actually, old horror movies such as "Them" is probably as much of an inspiration for this game as centipede was. Come to think of it, they haven't made a giant insect movie in quite a while.

This game was a bit rushed as I was originally going to release this game on the 23rd, but as the Mini-Ludum Dare competition is scheduled for that weekend, I figured that I would get this episode out as quickly as possible. Thankfully, a lot of the code from earlier episodes could be utilized in the creation of this episode.

The most interesting challenge in creating this episode was in the handling of eating trees. If the tree is eaten in four quadrants, the possible eating combinations can easily be represented using binary bits for each quadrant.  This means that 16 tiles are needed to represent all possible eating combinations.

Actually eating the trees initially appeared problematic. The new tree state is based on the current state combined with the eating direction. This would result in overly-complex conditional statements but I quickly realized this work could all be pre-computed. By simply having arrays of next-state for each possible tree-state it is simply a matter of looking up the next state. There are a couple of flaws with this system. First is that when you have multiple bugs eating the same tree, there will be cases where the tree is eaten while one of the bugs will continue eating the tree. Likewise, two bugs eating a single quarter of the tree will not eat that quarter faster than a single bug eating it. These problems are not overly noticeable so it is not worth the effort to solve these problems.

Zombie Starlings

While I might have been able to do more with this game had I used the Alein's Zombie game engine as my starting point, I decided to give the Starling framework a shot so spent a good chunk of time porting my existing code over to Starling. Actually this is probably not a big waste as I am going to be using this code as part of my Game Jam library that I am developing for use in future game jam competitions.

One of the reasons that I have decided to experiment with the Starling framework is simply that it is the sister-framework to the native iOS Sparrow framework. My thought is that I can do my prototyping in Starling as I am still fairly productive in ActionScript. If it proves to be too inefficient,  the option of going native is much easier as the frameworks are similar enough to make the porting of code very quick.

The map rendering was greatly modified when porting my old map code over. The old way I handled the map was to simply create a large sprite made up of tiles and simply moved this larger sprite around to scroll the map. While I am sure this technique could be used for Starling, the larger-scale games I am working on will require really large maps. As the size of these maps could exceed Flashes size limits, I opted to go with a slightly different technique.

I create a large sprite that holds just enough tiles to be one tile larger than the screen will hold. The tiles are set to the map tiles that correspond the top-left corner of the screen. Every time the map is scrolled to the point where one of the edges of the viewport sprite is visible then the map is repositioned and a new set of textures are assigned to the tile. This allows for smooth scrolling while not having to worry about size restrictions. It also requires a lot fewer sprites to be created which helps with memory and speed.