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.

Mini Ludum Dare #37

As M.A.D. is a very simple game, I figure that instead of looking at how it was made I would instead discuss the upcoming Ludum Dare mini event that I hope to participate in this weekend. The mini-events are far-less strict than the regular events and are for fun. While judging gives you feedback on your game (something I really don't get enough of) I have been entering game-jams for the fun of creating games. As I am starting to focus on much larger-scaled games, game-jam releases will probably become a much more regular feature on BlazingGames as that will allow me to continue to have regular content on the site yet still be able to put the time necessary to create larger games.

The theme for the game was announced early so I have had a few days to think about what I will do. This is a mixed blessing. On one hand I am able to plan out the game in my mind. On the other hand I am anxious to get started.  The theme for this challenge is not a game. An alternative theme is real-time. After sleeping on it, I came up with a game idea that fits both themes and also focuses on my two biggest weaknesses. My interpretation of the themes might be a bit different than other peoples, but that is part of the fun.

The no-game game makes me think about sandboxes. There are a number of games where the player is given tools to build things. There is no goals or win condition but instead the player has fun creating things.

The real-time game to me has two different meanings. The first is that time passes in real time so what takes a minute in the real world takes a minute in the game world. This is where my idea fits the theme. A more interesting meaning of the theme is to tie the date and time to to the game. I have seen a number of games that do this and if done well adds to the game. This can detract from a game as well as some players may only be able to play a game at a certain time and as a result be limited with what they can do.

The focus on my weaknesses is the best way of improving my skills. More to the point, I am hoping that by the end of the challenge I will have the start of a tool that will allow me to better overcome my weakness in future projects.

While I do want to shift to HTML development, the game will initially be written in Flash as despite the similarities between JavaScript and ActionScript the later is still faster to develop in. For me, Flash professional CS6 and Flash Builder 4.6 are the tools to use for Flash development with Flash pro also being adequate for my art needs. While I don't absolutely need the starling framework, it will be used. Audacity will be used for sound editing.

Ludum Dare #24 postmortem

People who have visited Blazing Games last week or who are following me on Google Plus already know that I recently participated in the Ludum Dare #24 challenge. This is a challenge where you have 48 hours to develop a game that reflects on the theme of the challenge. This theme is announced at the start of the challenge and this time was Evolution. For this fortnight's post, I have decided to write a mini-postmortem of my entry.

What went right

This was my first Ludum Dare but I had participated in the 7DFPS challenge so I was aware of how quick time goes by in these type of challenges so from the beginning decided that the best way of proceeding was to quickly get a functional game and then iterate on it. The theme of evolution immediately gave me the idea of missing links so the first pass of the game was simply a search of the map for the missing links. I then cleaned up the game to make sure I had something to release before the deadline. Finally I added the combat to the game.

My other wise decision was to take advantage of the photography rule. The challenge allows use of photographs and generated sounds as long as they are created during the 48 hours of the challenge. By quickly taking some photos and using a sound effects generator I was quickly able to come up with good looking game assets in a really short period of time. This gave my game a more polished look without the time burden.

What went wrong

The biggest mistake I made was not having a library of game code ready beforehand. Writing an engine from scratch is not really a good idea when you have time pressures. When you consider that one of the complaints for my game was the sluggishness of the scrolling, Having an optimized map class to start with would have been much nicer and would have given me more time to fine tune the game.

The combat was a bit too last-minute so ended up being a bit more difficult than what I would have liked. I should have listened to the voice in the back of my head telling me to cut the speed of the spiders down and lengthen the whip. I didn't and as a result a lot of people found the game too challenging to finish.

I am thinking that entering game jams will become a bigger part of my life. I really don't care if I win, but do enjoy the challenge and can use the resulting game on my site while I start focusing on the development of larger scale games that can actually turn Blazing Games into a real company instead of a hobby.