LD#25 postmortem

As is becoming a regular feature with Ludum Dare challenges, shortly after the challenge I like to write a postmortem of the game I created. The theme for Ludum Dare #25 was "You are the Villain." The game that I created for the challenge was "Evil Gnome's Revenge." This game has you playing the Evil Gnome from one of my earlier Christmas games (Santa's Snowball). As the gnome is not able to steal toys, he is instead going to release Santa's reindeer from the corral that he keeps them in.

What went right

The first thing that I did right was choosing a simple game to develop.  Even simple games take longer than you think they will to create. As polishing games is one of my weaknesses, I figured that the sooner the game was functional the  sooner I could start polishing the game and perhaps end up with a really great game. While I was able to get the basic chase mechanics working right away, I still spent a lot of time coding so didn't get as much polishing done as I would have liked. Missing features include fully animated reindeer, idle actions for the reindeer, and an evil version of a Christmas song for the theme.

The second thing that went right was getting proper rest. As Todd was having his 24 hour podcast while the challenge was going on, I had plans on listening to the whole podcast while I was fine-tuning the game. When I realized that I simply was not far enough along. There is a big difference between an hour of work done when exhausted and a productive hour of work. By spending a few hours sleeping I was able to regain my focus and get the game done. I honestly believe that the extra productivity gained from getting a few hours of sleep more than made up for the hours lost.

What went wrong

While I  liked the theme when voting, shortly before the announcement there was a major high school shooting which really  put a damper on it.  When I heard the theme I knew that I wanted a non-violent game.  It took me about an hour to come up with an idea that would fit the theme yet would not be violent. Had the shooting not happened I would have gone with one of my other ideas which probably would have resulted in a more entertaining game.

The other big problem that I had was the realization that I was writing far too much code. A lot of the code I was writing was fairly straight-forward and should be handled by my GameJam library. The library is in a early state so this is understandable, but I am going to have to find ways of creating classes that incorporate a lot of the generic code that I was writing into them.  Basic movement logic and collision detection are common to most games so having that inheritable in a generic game screen class would be a huge time-saver.

Conclusion

While I ended up with a fairly solid game, it simply is not quite as polished as it should have been. I am going to have to find spare time  before the next game jam and update my library to incorporate a lot of the more generic game elements so rapid game development will be easier.

GameJam library release 0.01

For 2013 I plan on focusing more on my larger scale potentially commercial projects with Blazing Games content coming from game-jam competitions such as the Ludum Dare challenge that is taking place this weekend. As these challenges allow for use of your own libraries as long as they are shared before hand, I am planning on creating a GameJam library to make it easy to create games quickly. The first release of this library is located at http://blazinggames.com/other/openLibrary/html5Libs.php but I don't recommend anybody use it yet. This is still a very primitive release. For those who are curious, I am going to outline my plans for this library.

First, I want to get basic 2D game elements, such as scrolling maps and multiple layers of sprites fully working. This is mostly there but the code needs a lot of cleaning yet before I would be happy with other people using it. I suspect that seeing where things need improvement while participating in a couple of game-jams will get me to the ready for consumption point.

Once this is done, I will add a couple of kits to the game focused on the major elements of common Genres of games. The idea here is that there would be core mechanics for a number of types of games that can be mixed and matched. That way if I go into a game-jam and think that a RPG would be ideal, the core elements such as character sheets, inventory systems, conversations, dice rolls would all be ready to go so I could get the game skeleton done in a few hours and spend the rest of the competition focusing on the content of the game. Essentially, I want the ease of a game-making tool yet with the flexibility of total control of the code. More important, at least to me, I want the library to be mine. I am making a slight exception to my-own-code ideal by using the starling library for 3D acceleration of the 2D graphics but when I get to my final step in this project, that will not be the case.

Once I have the ActionScript library in a stable state, I will port the library to HTML5. The decision to develop the library in AS3 initially is due to the fact that I can get something useful much quicker as I am far more comfortable with ActionScript. As the world is shifting to JavaScript, it only makes sense to shift development to that platform. I will probably have both Canvas and WebGL versions of the sprite/map renderers to take advantage of hardware on browsers that support WebGL while still allowing IE users to play the games.

I have no timeline for the library (and am actually not putting in as much time towards the library as I hoped) but plan on updating the library before every game-jam that I plan on entering.

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.

Torchlight II

The best way of improving your skills at something is to actually do it. The old saying that practice makes perfect is mostly true. I am one of those people who don't believe that perfection is possible as there is always room for improvement. The second best way of learning is by learning through others. That is at least the excuse that I use when playing games. Just playing a game is not enough, though. To learn from a game you need to think about why you are enjoying the game. Think about why the elements work. Often even the annoying things serve a purpose. I have found that it is easier to learn from a bad game than a good game as the mistakes that make the game un-enjoyable tend to stand out far more than things that make a game good.

My sister got me Torchlight II as an early birthday present (yes, she told me I could install and play it before my birthday this Sunday) so I decided to take a look at why this game is getting such good reviews. I am only a few hours into the game but have enjoyed the game so far. The biggest lesson to be learned is that small cute dogs can be extremely vicious.

The game supposedly randomly generates the maps to increase the replay-ability.  The levels I have played so far are pretty good but I have noticed that a lever puzzle was repeated making my second attempt at getting the treasure exceedingly easy as I knew exactly what steps were needed to solve the puzzle. What I suspect is going on is that the random dungeon uses a mix of random dungeon generation and canned chunks of dungeon.

This is actually a good approach to take, as it gives the replay-ability of randomly generated dungeons while also giving the much more streamlined and thought out designs that human created maps have. For me, and probably a large number of Torchlight players, this random generation of maps is lost on me as I have such a backlog of games that it is unlikely I will be replaying the game multiple times.

One advantage of hand-crafting the maps, at least in theory, is that it gives the designer more control of the game difficulty. Torchlight II appears to have solved this problem by using the player's current level when generating the quest map. So far every map I have come across has had the levels exactly mach my current level. I am not sure if this is actually the case or my exploration has just coincidently matched the level suggestions. I am hoping the later as one advantage that canned levels have is that it is possible to grind if the game gets too difficult. If all the levels are based on the level I am when I reach the quest then if the game is getting too hard, I am going to have problems.

MiniLD#37 Postmortem

As anybody who read the previous blog post already knows, I entered the Mini-Ludum Dare #37 challenge. This had the not-a-game and real-time themes. My entry was Musatic, which was a rhythm game but with the twist that you create your own song and dance in real time. As the initial phase of creation was in real-time and the focus was on the creation of music/dance instead of the actual game, I feel that both themes were at least loosely met. Now that the challenge is finished and I have had time to reflect on it, this post will be my mini-postmortem.

What went Right

Choosing music for my theme seemed like a really risky thing when you consider how little I know about the subject. Still, I believe that the best way of learning something is by doing it so writing a game that revolves around music would at the minimum give me some working experience. My goal behind this project was to create something that someone who knows nothing about music could use to create a short song. The first step was to create notes. As Audacity has a pluck generator, a range of notes were created. I decided that the easiest way of handling music would be to have all the notes that make up the song the same length. This made editing and replaying the music much easier as I would only need a grid that indicated what notes to be played at what interval.

This lead to my first day of work being focused on the creation of the music editor. My original thought was this would be a cheat mode, but I wanted to have the editor functioning for testing. When it took far longer than I originally anticipated to get the editor to a functional state, I had thought that focusing on the editor was going to be a what went wrong entry, but as I started playing with the editor, I realized that it was kind of fun so upgraded the editor to a main-menu item.

What went Wrong

Yet again, I made the mistake of not having a library ready. As creating a game engine, even one for such a simple game, is time consuming, it would be wise to go into a game jam with an existing game engine. I've noticed that a number of participants use game creating tools such as Game Maker, but I would prefer to have my own engine. Something that handles all the basics of a game so that the 48 hours (less with sleep) can be focused on the game not on the plumbing of the game. Some people may point out that I am using the Starling framework, which could be considered a library. This really is not the case as Starling is more for giving Flash a 3D acceleration boost rather than adding new capabilities.

Speaking of Starling, using an unfamiliar framework would be my second mistake. While I had been playing around with Starling before starting on this project, I had not actually finished a project using it. As a result, there are a lot of things that I did not know about the framework so did not know what issues there were. I actually did run into an issue with the way I implemented the editor. I am not sure what exactly the problem was, but suspect that I simply had too many objects with listeners attached to them. Had I been more familiar with the framework, the approach I took towards creating the editor screen would have been different and the performance of the editor would probably have been much greater.

Going forward

I actually really enjoyed this project and learned a lot. It is a project that most certainly be expanded upon so is probably something that will be revisited if only to enhance the music editor so quick and dirty music scores can be created for future game jam projects. If I do decide to update the full game, I suspect that it would take the form of an AIR application so that it would be easy to save and play levels.