Coffee Quest 2600 postmortem

The Mini-Ludum Dare for this month had the theme of Demakes so I decided to create a version of Coffee Quest as it would be had it been created or ported to the Atari 2600. The link is http://blazinggames.com/gamejams/2014/MiniLD50/ but  it is going to be my April game. That means it is time for a postmortem.

What went right

For rendering the 3D view, the program emulates the play field graphics of the 2600 by having a function that takes the pf0, pf1, and pf2 registers along with 3 alternate values for the right side of the screen. While writing the rasterizer as if I was really coding for the 2600 took a lot longer than I like, it ensured that the resulting game was actually something that could run on the machine.  For me, the whole purpose of this challenge was to create a game that could actually run on real hardware. With a bit of work, it would be quite possible to create a full-fledged RPG along the lines of Coffee Quest IV on the 2600. Sure, the graphics would not be that great and a pretty big cartridge would have to be used but it is doable.

Mixed blessings

While the rendering is done the way it would have been coded for the 2600, the map is not. The map is 32x32 bytes which is far too large. If this was coded properly, the map would have been broken into a wall bitmap (which would have only taken 128 bytes of ROM) with an additional 16 bytes to hold the coordinates of the objects. The time taken getting the renderer working made this impractical so I went with a traditional tile map approach so the game could be finished over the weekend. As I know my reduced memory approach will work, this is not that huge of a deal as the game is clearly still possible.

What went wrong

I simply did not have the time necessary to create this game for the 2600 so had to roughly emulate the limitations of the system.  Having researched the 2600 before starting this project, I found the limitations of the platform really intriguing so was sad that doing this project for real hardware (or at least a properly emulated version of real hardware) was not practical. The problem is justifying the amount of time that would be required to create this game on a 2600 emulator. Even considering that modern tools allow for much greater efficiency in creating the game, I suspect that it would take at least a solid month of work to finish this game. With no real way of recouping the value of my time, this project is sadly not worth doing. If enough people were interest (or if someone was willing to sponsor the game) then I might reconsider this project. So, if anybody wants to see this project running on a 2600 emulator, email me at spelchan at blazinggames dot com and let me know.

Next week, partly as a continuation of this topic and partly to demonstrate how different machines can be when it comes to assembly language, I will be going over the Hello World program that I wrote for the Atari 2600. Just quickly going over what is required to do that simple program will give you much more respect for those poor 2600 programmers.

Schrodinger's Kitten Postmortem

My Ludum Dare 28 entry was a game-show style game involving kittens. As usual, here is the postmortem for that game.

What went right

Kittens. What? That's not a good enough explanation? When the theme was announced my first thought was "great, another theme that almost any game could meet with only minor changes." Then I started thinking of all the possible games and not only were there too many options to choose from but most of the ideas were too big for a weekend. With a need to narrow things down I went to One Game A Month and picked one of their three December themes. Kittens lead me to thinking about Schrödinger's cat which lead me to zombie kittens. Not entirely sure how this led to a Bayesian logic game but that is what came into my mind.

Mixed blessings

One of my biggest weaknesses is sound. Having a Gameshow theme allowed me to at least have sounds that I could actually handle. The results were not what I would call good, but neither was it overly bad. I did learn the importance of having a decent mike as my headset clearly does not qualify. The biggest issue was as I moved there would be clicking sounds caused by head-motions. I tried using audacity to remove the clicks but there were still some clicks that snuck through. Considering I had to use myself as voice talent, I don't think I did too bad. I tend to speak in a monotone so had to put effort into making sure that wasn't the case. I didn't quite get the Gameshow voice I wanted but I am not entirely sure what is wrong. I am thinking it is an issue with my delivery speed but I am not a sound guy so that is just a guess.

What went wrong

Time management was by far the biggest issue this time. Part of this was my fault as I really had a hard time getting into my programming groove so spent far too much time with distractions. Part of my time loss was the result of interruptions. Phone calls, relatives with computer problems, and neighbours that can't comprehend what a game jam is took up a good chunk of my time.  Considering the time of year, I suppose this is to be expected.

Overall, this was not too bad of a game but could have used a bit more graphical polish and a theme song. One of these days I am going to have to start playing with some of the music software I own. Then again, considering my sound skills, the world may be better off if I don't.

Learning NES

This month's Mini-Ludum Dare has a theme of Low Level. The idea being that the game created should be created in a language like C so that the developer can learn something about how computers work. I figure the learning part is the key to this challenge so developing a game in C/C++ wouldn't really teach me anything. Then I thought about creating a game for a platform I haven't worked with before. This immediately got me thinking about the NES. I like 6502 assembly language so figured it would be a fun challenge.

The last few days I have spent my evenings researching the NES. There is a surprisingly large amount of info on it, most of it poor. I suppose this is not too big of a surprise considering that the big N didn't want anybody programming their platform without their blessing so most information was the result of  hobbyists digging into the system on their own and learning how it worked by disassembling existing games. There are some really good tutorials and tools available, but a lot of the stuff is old DOS tools. I ended up finding NESAsm for my 6502 assembler and YY-Chr for editing the 2-bit tile-based graphics.

I have put together a simple skeleton (a title-screen and gamepad controlled spite screen) that I will use as my starting code for this weekend. the link is http://blazinggames.com/gamejams/minild45/miniLD45.php and while it is far from the best assembly code I have written, it isn't too bad for first-project code.

The sad thing is that I was expecting it to be programmed more like the C64. With that you simply had a range of memory that the graphics unit used so simply wrote to that ram like it was regular memory. On the NES, the PPU's (Picture Processing Unit) memory is separate so you have a small number of addresses that you use to communicate with it. You set the address of PPU memory you want to write to by writing to a register with the hi then the lo (which is strange as the 6502 is lo-hi for addressing) then write or read from another register which increments the address that you are looking at.  The way colors are selected is also over-complicated. You have 4 palettes of 4 colors that are chosen from 64 colors. Sprites have another 4 sets of 4 palettes but each of the 64 sprites have their own choice of colors. For background tiles, 2x2 blocks share the same palette. This isn't overly convoluted, so to make things more confusing the attribute byte for selecting the palette is grouped in 2x2 blocks of the 2x2 tile blocks (which probably explains why mario seemed to be broken into 4x4 chunks of tiles).

The gamepads for me were the strangest thing. They have 8 buttons so you would assume you simply read a gamepad port and get back a byte with each bit being the state of a button. Nope. You first have to strobe an address to get the gamepad to start transmitting bits. You then have to read each of the 8 bits separately.

Even if I don't finish my game, I have certainly learned a lot from this challenge so consider it a success. If nothing else, it reminded me of how different similar-looking things can be.

Apple Harvest Postmortem

For the August Ludum Dare #27 I released a simple game called apple harvest. The game was simpler than I would have liked due to what went wrong but it was finished and isn't too bad of a game all things considered. Here is my postmortem of the game.

What went wrong

Unfortunately Ludum Dare #27 happened to take place the same weekend as one of my cousins' was getting married. This meant that instead of having 48 hours to work on a game I only had about 8. This greatly reduced both my options for what type of  games I could develop and the amount of polishing that could be applied to the game. As I really need to work on my polishing skills, this was disappointing.

What went right and wrong

I have been moving away from Flash preferring HTML 5 solutions as they do not require plug-ins. Right now my choice is to use Dart, but depending on what happens with ECMAScript 6 this could change. Still, when there is a limited amount of time, Flash is a bit faster to work with. Part of the reason that Flash is more efficient is simply due to the fact that the art/animation tools are built right in so you are not switching between multiple tools and writing code to load the various assets into the game as that is all handled automatically for you. While I would have preferred a HTML 5 solution, using Flash allowed me to finish the game at a relatively reasonable time so I wasn't overly tired for the Wedding.

What went right

The first thought that I had when I read the theme was a money booth type game. The kind radio shows like to have where you have a short amount of time to grab as much money as you can. Playing around with air dynamics would have been great fun but probably would have taken me more than 8 hours so I had to apply a  Keep It Super Simple approach. I replaced harvesting money with apples. Why apples? I wanted some type of motion to the harvesting and falling apples is what came into my head so I just went with it. The apple life cycle was fairly simple with a flower, then a growing green fruit then a transition to a mature fruit. The transitions had a per-frame probability of  happening adding a slight random element.  Spawning new blossoms was also easy as I just pick a random spot on the trees. If there are no apples near enough then it takes otherwise, no spawning happens that frame. The simple artwork for the apple also got co-opted into the buttons for the menus.

Conclusion

For a very rapid game I think it turned out good. If I do revisit the game I would add multiple levels with quotas per level, and possibly different types of fruit trees.

Metal Galaxy Postmortem

I am a few days late with this blog post as I decided to wait and see if I participated in the 7DRTS before writing it. Due to other obligations I was not able to spend a week, or for that matter evenings during the week, to work on the 7DRTS challenge but having worked out a simplified 4X game in my mind I wanted to give it a go. This is not that game but hints at what I had in mind are all throughout this postmortem. The game was posted on Ludum Dare, but is going to be August 2nd Blazing Games release. For those who don't want to wait a few days, here is the link to the page so you can try the game out right now. http://blazinggames.com/gamejams/minild44/miniLD44.php

What Went Right

In addition to the Mini-Ludum Dare theme of 7DRTS, I decided even before I started that I would try and incorporate the One Game a Month theme of Metal into whatever game I designed. Massive space fleets battling each other on a galactic map fit this theme but when I had to reduce my scope as it was probably not realistic, fitting that theme into colonizing planets was a bit trickier. Coming up with the amount of metal different stars have affecting the production rate worked really well as it definitely determines which strategies are most effective. The most effective strategy is focusing on heavy metal stars but bottlenecking the opponent by taking advantage of the 10 light-year limit is also effective.

What Went Right and Wrong

When I first heard of the RTS component of the challenge, my first thought was a galactic conquest game with a focus on fleets. As I only had a couple of the seven days this wasn't possible, at least not the way I had in mind. While playing with my galaxy generation code I added code to detect clicking on stars and making sure that a star was within 10 light years of a star the player already owns. This is when I realized that a race to colonize the galaxy is ultimately what the game is about and by eliminating the combat it becomes easy to finish the game over the weekend. Of course, by not having any type of production choices, or fleet dynamics, the strategy element of the game is significantly reduced. My what went right added a bit of strategy back to the game so while still simple on the strategy level, the game is fun and fairly quick to play.

What Went Wrong

As was already mentioned, the original plans for this game was to be a strategic space combat game so I spent time working out a simplified fleet management system. Had there been a full week to work on this game I have no doubts that I would have been able to pull this off. As it was, after spending a few hours of putting together some basic fleet management code, I quickly realized that the game simply was too large for a weekend so scrapped the code. Except that I still want to do the original game. Yet another game in my ever growing list of projects. Ah well.

Towels for Earth Postmortem

As a fan of Douglas Adams since I was a kid, there was very little chance of me not partaking the Towel Day Mini-Ludum Dare. I find it really interesting that Mini-Ludum Dare#42 happened to occur just in time for Towel Day but as Douglas Adams has repeatedly said "42 seems to show up a lot." For those not familiar with The Hitchhikers Guide to the Galaxy, 42 is an important number as it happens to be the answer to "life, the universe, and everything". I decided to take the challenge a bit further and make it a Towel Day challenge instead of a weekend challenge. Here is my postmortem.

What Went Right

Making Towel Day an important part of the project was my personal goal of this challenge. Technically, the theme was "Earth will be Destroyed" to make the challenge accessible to those sad souls who are not Douglas Adams fans.  I managed to incorporate the reason Earth is being destroyed, a two headed alien, adding nutrient enrichment to a towel, towels and 42 . Not too bad for a rushed project.

What Went Right and Wrong

The decision to create the game on towel day was a mixed blessing. A game jam is short enough without artificial restrictions. In this case there simply wasn't enough time to add sound and other minor gameplay enhancements such as an unlimited mode. Time limits and other restrictions do help build creativity and let you refine your skills so the extra self-imposed restrictions are useful. To be perfectly honest, though, the real reason for the extra restrictions were the emotions related to creating a game on Towel Day.

What Went Wrong

When I first heard about the challenge, my plans were to create the game using HTML5. I figured that work porting my GameJam library would be useful as it would make it easier to finish the game in time. As creating the functionality of the Flash libraries in JavaScript would be a lot of work, taking advantage of the existing CreateJS library seemed like a good plan. From my experience with this library, it works great but it is still in development. When I ran into issues with the event handling, it became clear that rethinking the jam plans was in order. While I think these issues are JavaScript issues related to the way I am creating classes, they could be CreateJS bugs or some  other code issues I am unaware of so the time needed to solve or work-around the issues was too random to chance it. With not enough time to solve the issues I resorted to my Plan B and created the game in Flash.

Loot Run Postmortem

While I did not particularly like the theme of Ludum Dare #26 as  it was far too general, I did have Saturday free to work on so I created a quick game. To me minimalism means eliminating all that is unnecessary. For games, this means graphics and sound. The idea is to focus on the essential gameplay. Loot Run is a platform game done entirely with text.

What Went Right

Keeping with the theme, I wanted to keep the gameplay as simple as possible while still being fun. While scrolling would have been easy to do, keeping levels limited to a single screen seemed to fit the theme better. The player needs an objective. Collecting money is a very obvious motivation and is something that most players can relate to.  Having just the environment as the obstacle did not seem like enough so monsters were added. While the original plans called for title, instructions, winning and about screens, it became obvious that these things could be integrated right into the game levels.

What was Both Right and Wrong

Using just text was the right decision, but in hindsight it would have been more efficient to use a canvas with the letters as a tile set. This would have resulted in a lot less garbage collection. While this had little impact on the game, knowing that all the needless garbage collection is happening does bother me. For those not familiar with JavaScript, let me briefly explain.

JavaScript strings are immutable. This means that every time you modify a string you are actually creating a new string and essentially dumping the old string onto the garbage heap. When there are enough dead strings lying about the garbage collector gets called and frees up the memory. As generating a frame results in numerous dead strings, this is not very efficient. It is kind of ironic that faking strings by using tile-maps would have been more efficient.

What went Wrong

The controls for the game were probably the biggest problem. The method I used was to track whether keys were up or down and during the main event loop adjusting the player based on the keys. For most games this would be fine but because I am only updating the frame every 150ms this can result in too big of a lag between the players key press and the processing. For instance, if a player hits up to jump and releases the key within the 150ms it is possible that the jump will be missed. What I should have done is had an array for next actions as well as key states. The next action would have been set as soon as a key was pressed, and every interval the actions would be ORed with the keys that are still down.

Whale of a Tale postmortem

Last week I released Whale of a Tale for Mini-Ludum Dare #41, so that means that it is time for my postmortem. I kind of like the right, right & wrong, wrong approach that I used for my last postmortem so think that is the format I will use for future postmortems.

What went right

Part of the reason for doing game jams is it lets you branch out and try something different with the only loss being a weekend. So when my first thought for this game was a combat game done underwater, I decided I didn't want the player to do anything violent, but the only blood in the game would be from the player or other innocent bystanders. I was thinking of sharks being hunted for their fins but sharks are vilified so didn't think the player would sympathise with one. Then I thought of a whale and the game immediately came together in my mind.

What went right and wrong

The game does need a bit more balancing. In theory more and more ships appear but I chose to go with a random spawn approach rather than a specific interval which makes the difficult ramp-up sporadic  Likewise, running out of energy only makes you move slowly so to emphasize the need to eat (and move into greater danger) I should probably have energy coming out of the player's health bar once the energy bar has been depleted.

What went wrong

A relative going into the hospital almost killed this game. Had this been a regular game jam it would have. Thankfully the lax rules allowed me to so I did the second day of work a few days later rather than consecutive days. The person doing my art simply didn't have the time to do all the art that was planned but enough of it was done that I am happy with the look. Still, a better ocean, moving clouds, fish that look like fish, animated waves, would have added to the look of the game.

Conclusion

I actually like this game so am thinking about putting it on my ever growing revisit list where I would spend another day or two fine-tuning the game and touching up the graphics. Not sure if this will happen but you never know.

CRA Agent Postmortem

David S. Gallant was fired for the dreadful sin of creating a game about his job. Ludum Dare decided to host a game jam related to this. I created my CRA Agent game as part of this CRAJam. Now I am writing my postmortem about the development of this game.

What went right.

I had a very clear vision of the game I wanted to make. Having clear and realistic goals made getting the game done fairly quickly. The fact that the game was fairly simple from a coding perspective was a bonus. While I had hoped to have the adventure game kit portion of my GameJam library ready, it simply was too far from completion to contemplate using it which may have been a blessing as I probably would have spent far more time working on my generic adventure game library than on the game.

One big change from my original plan did occur, which is why it is always good to have some flexibility with your designs. Instead of the single inevitable ending I was planning for, I decided that the underlying score systems could be tweaked to allow for three different endings based on how the player plays. It actually didn't take very long to tweak the numbers and I think the game benefited from this change. It is still a short game that can be finished in a couple of minutes but now it has enough replay-ability that it allows more exploration of the theme.

What went wrong

Politics. I hate politics so having a politically themed game was certainly an issue for me. While I think my political opinions can be discerned from this game, some of the decisions that the player could take clearly went against my beliefs. I think I handled both cases with enough humour that the game should be enjoyable even by people with differing opinions than mine, but the fact that politics happens to be one of those subjects that invoke strong irrational emotions from people I am sure I have pissed some people off.

Too much art.  Instead of creating unique art for the agent, the 8 people being audited, and the boss, I may have been better off creating a face-making program that would generate a huge number of faces based on a small number of art pieces. I could have then spent more time creating text for people being audited which would have added a lot more content to the game.

Conclusion

I think even though this game is likely to piss some people off, it turned out pretty good.

Mini-Ludum Dare #39 Postmortem

The theme for this challenge was Hindsight. A chance to redo a challenge or to partake in a challenge that was missed. While there are a lot of Ludum Dare's that I missed, so I had a lot of choices, a redo of the previous challenge was my immediate thought. While my last game was not a bad game, it was not the game that I wanted to do with that theme but with a school shooting taking place right before the challenge I simply couldn't bring myself to create an overly violent game. Interestingly enough, there was another shooting a couple of days ago so it is a good thing that I took on this challenge when I did or I may never have created Zombie Forever. The goal of the game is to form a zombie army by enlisting all the campers near your secret lair. As usual, now that the game has been released, here is the mini-postmortem.

What went right

Even though the Mini challenges have very lax rules, I try to treat them like a regular challenge. When offered help with the art, I decided that it would be acceptable to go with a Jam entry. The extra time, having someone else handle some of the art and ability to use existing art really helped me get quite a bit done. I  may have to take the Jam option with some of the future Ludum Dare challenges. At least in cases where the theme is one I can interest other people in joining me.

While I suppose the second point is a subjective one, I really think I got the feel of building a zombie army. I think slowing down as the zombie takes damage really adds to the feel of being a zombie. Likewise, when you have a large number of zombies slogging toward your next victim,  it has that zombie hoard feel.

What went wrong

The downside to switching to the Jam format is that having more time and help means that more can be accomplished which means that my  over-ambitious tendencies have a chance to surface. My original plans called for three levels and 9 character types. I would have been better off just focusing on the secret base and having just the zombie, scientist, and security guards. Still, I do plan on finishing the extra game levels so the original design will eventually see the light of day.

The AI also ended up taking more time than anticipated. Working on the AI resulted in one of the most humorous bugs I have had. The random walk state originally would only check the map tile in the direction it was heading to make sure the character could enter the tile. When the desired moved was passed to the game core, it would interpret an attempt to enter an occupied tile as an attack on that character. The best part was not only would humans attack other humans, but if they killed that human, the victim would become a zombie!

Conclusion

I know that there are a lot of people who don't like turn-based strategy games, but I personally really like them. I am planning on releasing an additional two maps, and if the game proves to be popular would consider doing a sequel game with more abilities and challenges.

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.

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.