Fleet Postmortem

Fleet is one of the first Java games that I wrote. As the game was written in Java, and Kotlin is a replacement to Java which can compile to JavaScript, I decided to see how well Kotlin works for HTML5 games. The create.js library was used for handling the GUI aspects of the game. To make the game more playable on tablets, I had to rework the user interface quite a bit which makes this more of a re-write than port.

Fleet was released on Spelchan.com on June 1st and is based on the classic pen and paper game that is now played on a board with easily lost plastic pieces. You control a fleet of ships. You have an opponent who also controls a fleet of ships. Your goal is to destroy your opponents fleet of ships before your opponent can destroy your fleet of ships.

What Went Wrong

In the original Fleet, ship placement was done one ship at a time with the player using the space bar to rotate the ships. As I wanted this to work on touch-only devices this meant that requiring a key stroke was out of the question. Dragging the ships around to move them seemed like the ideal touch-based controls. Double-clicking on a ship to rotate the ship became the obvious solution for ship orientation.

While create.js does have some support for drag-and-drop, I still had to write a fair bit of code to get this to work. Getting it working with the mouse was easy but for some reason it would not work on the tablets that I have access to. I finally searched on-line for any information where I discovered that you had to enable touch by using the Touch class. Seconds later I was running it fine on my tablet, but my Dad's older tablet ran very poorly and inconsistently. While I suspect that this is predominantly due to the age and slow speed of the device, I decided it would be a good idea to have the initial layout of the player's ship be randomly generated just like the AI ships so that if a player was having problems moving ships around, they could just go with the default random layout.

Testing the dragging and dropping of ships resulted in the ship often not going where the player was expecting due to the way the sprite snapped to the grid. One solution to this problem was to simply have the grid snapping happen as you dragged the ship but this simply did not feel right. The original version would highlight the grid squares where you were going to place a ship in white or red so I figured that I would do the same thing here but opted for yellow and red. This took a bit of work to accomplish but I think the results are quite nice.

Mixed Blessings

Kotlin is a rather new language that came to the scene more as an alternative to Java programming on Android but with the ability to compile to JVM, JavaScript, or Native it has a lot of potential. I started my Atari 2600 project to try out the language where I found myself enjoying the language. I wanted to see if it could be used for porting games so decided that as Fleet was originally written in Java, it would be a good contender.

One of the nice features of Kotlin is that you are able to use the "native" features of the platform you are compiling to so a JavaScript project can make use of JavaScript libraries and other native features. This has to be specified using the external designation but there is a utility to convert TypeScript definition files into Kotlin definitions so it was simple enough to get a create.js definition. Using create.js with Kotlin always felt like a kludge and its JavaScript nature made working with it awkward for many activities such as tweening.

The biggest downside to using Kotlin and Create.js together is that both are large libraries making the loading time a bit larger than I would like. For a larger project this would be okay, but startup time for Fleet seemed to be way too long.

What Went Right

The AI that I created for the original version of this game was surprisingly good and yet was fairly simple to implement once the base ideas behind it were worked out.  The version of the AI in this game is essentially the same as the original version except that it was cleaned up. It didn't take too long to port the code over and it just work. If all the code I ported went this smoothly, I would have ported many more games by now.

Summary

I think this version of Fleet is a bit nicer than the original though there is still a lot of things that I would have loved to do had I the time. It is possible that I may revisit this game in the future with a deluxe version of the game, but that will not be for a while.

As for using Kotlin for future HTML games, I am still up in the air. If I could find a good cross-platform library with similar functionality to Create.js, then this would possibly be a good thing. Writing my own cross platform library is not likely in the near term, but after I get my Masters it may be something I would think about. I am still wanting to try out the Rust language, so how much I like that language will determine which of the two languages I will be focusing on in the future.

Towels for Earth Postmortem

This is a postmortem for the game that I will be posting on May 25th for Towel Day which is the HTML5 port of Towels for Earth. Towels for Earth was a game that I created for a Game Jam back in 2013. The theme of the game jam was towels in honor of Douglas Adams. I suspect that there are several Douglas Adams fans who managed to encounter my Blazing Games site somehow as the polls show that there are quite a few people who wanted to see this game ported to HTML5. It is a fun but short missile defense game where missiles are destructor beams and anti-missiles are towels with the player tossing towels at destructor beams to save the Earth.

What Went Right

This was a game-jam entry so it was very quick to port over. I had a bit of time left over from what I budgeted so I decided to add some sounds to the game. The original game is in space for which there is no sound, but purists can simply turn the sound off via a nifty sound toggle that I added. The speaker artwork was taken from another game I wrote that had a sound slider but I didn’t have enough spare time to try and create a slider, but that is probably something I should be doing in the future if I ever get enough spare time, which won't be in the next couple of years.

I started going through some of the public domain and royalty free sounds that I have collected over the years to find a few sounds that would work with the game. While some people may not like my choices, I think they work well for the theme of the game. Sound in Create.js is very easy to play if the files have been downloaded which I am using preload.js to do so this was trivial to add once the sound files were found.

What Went Wrong

I went a bit overboard with the original game and had created a pixel-perfect collision detection routine. This requires the use of bitmap libraries that Create.js doesn’t have and would have been very painful to do – not to mention excruciatingly slow – to do so I reverted to good old-fashioned bounding circles. The wonderful thing about bounding circles is you just find the distance squared between two objects and see if the squared distance is within the combined radiuses. The problem is that if one of the shapes is not spherical, then the collision results can be a bit inaccurate. I don’t really mind too much but suspect that I may hear some complaints about this. I did try to be a bit generous with my circles feeling it is better to have more false positives than false negatives.

Some of you may be wondering why I am using distance squared. This is an old-school technique to save a bit of CPU cycles. Distance is sqrt( (x1-x2)^2 + (y1-y2)^2) which is a slow routine to calculate since square roots are very slow to calculate. On the other hand, radius*radius is very fast to calculate so by forgoing the square root portion of the calculation you can speed up the check while keeping the accuracy of the calculation.

Mixed Blessings

The original game used a combination of background images and vector artwork, but I opted to go with all images even though I could have saved a bit of space by using some vector images. The tradeoff of a slightly larger file size for slightly faster game rendering and a easier coding was arguably worth it. The images I did want to have as vectors were actually fairly large so it wasn’t that much space that I was using. My original plans were to have the backdrops converted into a separate jpeg file while the other parts were stored in a png file so I could get a bit better compression. When using my image view to see how different compression ratios would affect the image quality, I noticed that the images looked pretty good when converted to 8-bit png files with only a small increase in file size so I put all the images into a single image atlas.

For people who still have slow internet connections, these decisions may have resulted in longer loading times. For that I apologize as I know most people with slow internet don’t have a choice in the matter.

Conclusion

Overall, I am happy with how this game turned out. Sound does add a bit to the game, but sound and music is my Achilles heel. I really have to start trying to add more sound to my games in the future.

Drone Defence Postmortem

It is a new month so time for my postmortem of my Blazing Games release for this month. The game is my first game created with OpenFl which is the flash-like library for Haxe. I am not sure why I decided to try doing a similar game to what I did as my Game Maker test game, but I did. The game needs a lot of polish yet, but for the limited time I put into it worked out great.

What Went Right

OpenFL is a flash-like library for Haxe. While Haxe already supports the Flash API for projects exporting to Flash, OpenFL expands this to all the other platforms that programs can be exported to. At least in theory. As I have done a lot of work using the Flash API, this is a great feature for me as it makes getting up to speed with Haxe much easier. If you are not familiar with Flash, this is probably not that big of a deal but it is still a decent library. I have tried a number of different Flash-like libraries for a variety of languages to various results. This library, from what I did with it, worked exactly like I expected (at least until I exported for HTML5) which was nice considering the learning curve that Haxe gave me.

Mixed Blessings

Haxe is a rather interesting language as instead of compiling to machine-language (or a virtual machine-language) it compiles to a number of different programming languages for a variety of different platforms. The idea here is that different platforms have different key languages for development. Windows is C++, IOS/OSX was Objective-C, Android is Java, the internet is HTML5 or Flash. The idea here is that you code in Haxe then fine-tune for each platform in it’s preferred language. It is, however, it’s own language with it’s own way of doing things. While similar to ActionScript, it is different enough to occasionally throw a wrench in the works. One of the nice things it does, which I wish C and all its decedents did, is automatically break switch statements unless you explicitly tell it not to. One thing I didn’t like is the requirement of iterators in for loops.

What Went Wrong

Unfortunately, as is often the case with projects still in development, there are issues with OpenFL. In my case, the HitTestObject method did not work in the HTML5 export. As this is essentially just a bounding box test, I replaced my hit test code with calls to check for rectangle intersections between the bounding boxes for the objects. The problem here then became there always being a collision. After checking the results of the getBounds function, I discovered to my dismay that the width and height of the object were the canvas size and not the size of the sprites. Worse, requesting the width and height of the sprite also returned the canvas width and height. These bugs don’t exist in the other export formats I tried so I ended up releasing the Flash build of the game instead of a HTML5 build like I was originally planning to. I will have to look into this issue a bit more as I really liked OpenFL and think if issues like this can be fixed this would be a great platform to develop for.

"First" postmortem

It is time for my Postmortem of the game that was recently released on Blazing Games. This game is called First as it is my first attempt at creating a game using RPG Maker VX Ace.

What Went Right

It is usually, if not always, wise to have a plan B. When the RPG Maker game competition was announced I knew I was going to attempt to create a game for it. A game that had a chance of winning would require a large time commitment so my plan if I was unable to finish was to forgo the contest and release my first RPG Maker game for July’s game. My first RPG Maker game was created months ago so it was ineligible for the contest. As the Blazing Games release for this month is my first RPG Maker project it is clear I never had enough time to finish the planned game. This was not a result of the game being over-ambitious but was a result of not having anywhere near the amount of spare time as expected. One thing you should always remember when scheduling projects is that unforeseen events (and for that matter, problems) will happen. In this case, the real game was roughed out but needed a lot of polishing before it could be considered a contender. With only a week before the competition deadline a decision on whether to reduce the amount of polish or go with my first RPG Maker project was in order. Had I known my Canada Day plans were going to be rained out, the choice would have been different.

The First game consisted of the player's home, the island map, and the Kobold cave. I quickly came up with a story, added the town and the related buildings, and modified the cave to fit the story. It is still a very simple game but still an entertaining fifteen minutes.

Mixed Blessings

RPG Maker VX Ace is actually a fairly nice tool. There is too much to discuss here so will discuss the tool next week. Using an existing engine saves you a lot of work at the cost of flexibility. While the scripting engine is very flexible and powerful, it is still a huge  amount of work to create a game that is vastly different from the base game that the engine was designed for. This has the unfortunate result that many RPG Maker games feel the same. This problem is true of other game engines, such as Unity and Unreal, as well. If you want your game to stand out, a lot of effort is required even if you are using an existing engine.

What Went Wrong

The biggest issue with the game is the size of the zip file. The reason for this huge file is simply that RPG Maker includes all the files in the resource manager even if they are not being used. This means that in order to get a smaller distribution file you need to manually remove the files that aren't needed. As I had expected RPG Maker to do this for me, no time was allocated for this task. Making this task trickier is the fact that I have very little idea as to which files are needed. Once you have worked with RPG Maker for a while this will probably be less of an issue. Of course, it is also possible that there is a way to get RPG Maker to do this work for you but I simply didn’t figure out how to.

Next week I will go over my thoughts on the RPG Maker VX Ace tool.

NES Trivia Postmortem

For my Blazing Games June game I am releasing my NES Trivia game even though I have not yet quite got to it in the blog. See the what went wrong section for the reason for this. Needless to say, here is the postmortem.

What Went Right

The string library that was developed for general purpose use worked really well. Especially when the macros were used. Lots of the display-related code is very easy to understand thanks to the use of the PrintStringAt macro. While the StrNCmp function was never used in the game, it will be used in the sequel so the code was not wasted, just slightly premature.

Mixed Blessings

The whole reason for this game was to actually create a simple game fairly early in the series. As it turned out, there was a lot more foundation work that I had to write about before I could get to the meat and have a real game. Even at this point there are things that could be improved. The biggest being randomness. Right after that (before that for many people) is sound. Filling up the extra ROM space with questions and touching up the display finish off my list.

What Went Wrong

This was not the game I was planning on releasing for June. I was going to hold off releasing the game until we actually started creating the game in this blog. Unfortunately, the game I was hoping to release for June simply was too large for the amount of time I had available (and my Dad going into the hospital for a hernia operation didn't help). Using this game as filler material was my only option. Sadly the game I was developing is going to be delayed by at least a month as there is a big RPG Maker contest in June. While I suspect there are people who are far more knowledgable about RPG Maker that will probably win, there are real prizes for this challenge and I did want to try out the tool so this will be my June project. If the resulting game got enough interest, and especially if it won money, I would probably shift my focus to developing a full version of that game.

Maze 3D postmortem

While there was not enough interest in Coffee Quest 2600 to warrant developing it, I really wanted to see if my rendering technique really would work on the 2600 with the limitations the system has. This game is the result and proves that CQ2600 could be done. I would love to develop a proper 2600 RPG though it is doubtful this will happen. Still, here is the postmortem for my 2600 3D maze game.

What Went Right

Stella was the code name for the 2600 console and is also then name of an open source 2600 emulator. If you ever decide to develop a home-brew 2600 game, this is an awesome emulator to use during development. The built in debugger is simply wonderful to use. Not only does it have your break-points and stepping through code capabilities, but you also see where the cathode ray is when stepping through the code. As some of the hardest programming/debugging involves the timing of the cathode ray, this is a wonderful feature. Other handy features include actually seeing what the TIA registers hold and smart disassembly.  The disassembler appears to track exactly which parts of the ROM are used for instructions and what parts are used for play-field and sprite data showing graphical representation of the data. This debugger made getting the game working much easier!

Mixed Blessings

The game required reworking the display that was used in my Coffee Quest 2600 game. While a lot of the logic used in that game was usable, there was a fairly large amount of code that needed to be reworked. The decision to have a top bar with a compass in the centre was a direct result of playing Coffee Quest 2600 as I found that it was way too easy to get disoriented while playing the game. The compass at least makes it possible to know which direction you are heading in. I was also going to have coordinates displayed on the bar, but the amount of time and effort to add this was too high so this feature was left out of the game.

What Went Wrong

"Racing the Beam" is a phrase used to describe programming the 2600. This is sort of correct as the entire program revolves around the timing of the display. However, especially when you are doing more complex things such as asymmetrical play-fields, you are not trying to keep ahead of the beam but need to wait for the beam to get ahead of you. With asymmetrical play-fields, you set up the play-field registers for the first half of the display but can only set up the registers for the second half of the display only after the beam has drawn the register you are changing otherwise what is being drawn is incorrect. This results in ugly code where some of the logic that should be done at the end of the block has to be done in the middle of the block. This is so that the beam can draw the play-register that needs to be changed.

This was a very interesting challenge as such tight constraints in memory and timing are rarely issues with modern day programs. With so little time to get things done, seemingly simple things such as shifting mask registers takes too long and has to be replaced with small look-up tables. Yet look-up tables take up precious memory so it is an interesting balancing act.

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.

Spikey Bird Postmortem

This post is slightly late as I wanted to create a game for Flappy Jam. I was going to do this last weekend but as is too often the case, things came up so my plans got postponed.

What Went Right

When I am coding a game, I tend to use the approach of just using placeholder artwork (generally coloured blocks and spheres) replacing it with art once the game is functional. Unity isn’t really a programming-based platform so this approach just didn’t feel right. Instead, the artwork was created first and plugged into the Unity project. This approach really worked well which probably isn’t too surprising as Unity is aimed at designers. The nice thing about this approach is you get something closer to the final product right away.

Mixed Blessings

Writing a script to generate the level on the fly is something that is right up my alley. Procedurally generated content in theory offers unlimited replay as no two games will be alike. In reality, the content always seems to be similar enough that the replay value is never as great as it should be. Controlling the difficulty is also not as easy as it would be with hand-built levels. When it comes to a graphical design tool you also have the disadvantage of not having the level visible until you are running the game.

What Went Wrong

One of the cardinal rules of Game Jams is “be familiar with your tools/language before starting.” I am not familiar with either Unity or with C# so developing a game using Unity with C# for the scripting language was probably not a wise decision. Of the 20 hours I spent creating this game, over half of the time was spent searching documentation and the internet for information. Minor things, such as finding the length of a list (C# Lists use Count instead of the length that I am use to) had to be figured out each time eating up not only the time spent in finding the answer but the extra cost of being knocked out of flow. That said, when you think about how quickly I could have created this game had I already been familiar with Unity/C# I can see why the platform is so popular. But if you are not familiar with the platform you are using, the short timespan that a game jam gives you is not the place to be learning a tool/language if you actually want to get something released.

My overall impressions of Unity are mixed. Lets face it. Unity is very much design driven while I am more programming driven. A lot of the way to do things in Unity are not the way I would do things but the power you are getting out of the tool makes it worth using. I can see how using Unity would make sense for a number of the projects that I want to do so I expect more of my games to be created with it in the future. That said, I am still at the very early stages of learning Unity with a huge amount still to learn.

Saga of the Candy Apple Scroll postmortem

My February game is my CandyJam entry so here is the postmortem.

What Went Right

Despite the rather long time that was theoretically available for the CandyJam entry, I knew that I would probably not have as much time as I expected and planned accordingly. Not counting the time spent playing with Unity (see mixed blessings), the game only took about 8 hours to create though had I been under tighter game-jam rules and had not been able to borrow artwork from some of my other games it would have taken a bit longer. I do not know what has been up with the last few game jams but having only part of the time to work on the game is a trend that seems to be continuing into this year! That said, if I did have more time to work on the game, I would spend the time working on my polishing skills as those are most definitely in need of work.

Mixed Blessings

It is never wise to try and learn something new when you are already under a tight deadline. I originally planned on using this project as my first Unity project as it is a very popular engine which may also be exactly what I need for some of my larger projects. I got bits of this project working and possibly could have finished it but things came up and the next thing I knew the end of the month was upon me. While it may have been possible to finish the game on time with Unity, I didn't want to take any chances so went with Flash. This gleaned enough knowledge of Unity that I should be able to create a simple game with it real soon.

What Went Wrong

Companies abusing IP laws. Technically this is not a problem with the project, yet, but the title of this game  very well could result in trademark complaints for using a common English word as part of my title. Far too often patent and trademark offices grant weak patents or trademarks and leave it up to the courts to decide if the patent or trademark are valid. This actually has the result of having the exact opposite effect that the trademark and patent laws intended. Instead of giving small companies the tools to compete against larger companies on a level playing-field, this gives companies with money (large companies) tools to attack companies without money (small companies) preventing them from competing. In the long term this is harmful to both innovation and consumers.

Color Smash postmortem

When I heard about the New Year's Game Jam, I thought it would be perfect for my first game of the year. Unfortunately, I had some other plans for New Year's Eve which meant that I had a shorter period of time to develop this game. This is the postmortem for that game.

What went right

When I went to the NYGJ site to find out how the challenge worked, I noticed that they did not specify a theme.  Having the option to do anything is nice but if you can't decide what you want to do then there is little chance you will finish a project within such a short timeframe. Having a plan, at least in your head, is important for really time-restricted projects. Thankfully the site had a theme generator (1GAM had not released their January theme yet so I couldn't use that). While the theme I was given, click the button, was rather generic, it was enough to get me to focus on a whack-a-mole style of game.

Mixed blessings

Knowing that I was going to only have a short period of time to work on this game was both a disadvantage and an advantage. By anticipating a short development time I opted to go with a much simpler game than I would have liked to but it also meant that I was able to finish the game and even get a slight polishing pass.

What went wrong

Perhaps anticipating a New Years Eve party is what caused me to make a rookie mistake but a simple order order of execution bug stumped me.  With Flash, it is important to remember that the last playhead adjustment is the one that gets executed. This means a gotoAndPlay() followed by a stop() is not going to work well. This is a fairly obvious bug, but in my case things were a slight bit more complicated so obvious sequence was hidden from me.

For the lights I dispatch an event when an animation sequence finished playing then going to the default "off" animation to wait for orders to change the color of the lights. The problem is that the event dispatcher actually calls the event handling functions before returning. This means I tell my main game that it is time to start the next animation, which calls the light to set the color to the new value causing a gotoAndPlay() call to the appropriate color appearing animation. When the dispatcher returns, the light goes to the default off animation. Simply by moving the gotoAndPlay("off") call to before the dispatchEvent call solved the problem.

This bug is an important reminder that it is important to think about when things get executed. As the trend of having more cores instead of faster speeds continue, future speed gains will come from taking advantage of multiple cores, meaning that I expect to have to write more threaded code in the future. This makes order of execution issues even more prevalent.

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.

Coin Drop Turbo postmortem

Just submitted my Charity Game Jam 2 entry so here is the postmortem.

What Went Right

While I seem to have no problem finishing weekend game jams, the same can not be said for the week-long jams that I enter. While I usually end up with a playable game,  the result is quite far from what I plan on. Figuring that the main reason for this is vastly over-estimating how much time I will have to work on the game, I took the approach of designing a game that I would do during a weekend jam and spending the extra time polishing the game. I would probably have spent a bit more time polishing had it not been for what went wrong. This proved to be fairly successful, especially considering that I missed a couple of evenings as well as had to watch the Doctor Who anniversary special and go to a CFL party. Had I gone with the game I was thinking about developing when the challenge was announced it would have been a total failure.

What Went Right and Wrong

Once I knew what the game was going to be, I had planned out a system for having different levels. This was based on the types of coins that were in the bank, the target goals, and the pig speed. This sort of worked, but was not as effective at controlling difficulty as I would have liked so the game is a lot easier than I had anticipated.  Had I not used real currency I could have had much closer point values for the different items that had to be collected that would have given me more control over the difficulty but that was not an option so the Loony and Toony kind of throw off the game balance. I suppose I could have gone with not using those coins but those are my two favorite coins. I suppose the lesson here is not to let your emotions get in your way of good design.

What Went Wrong

I should be polishing the game some more, perhaps fixing the difficulty issue by getting rid of the Twoony and replacing the Loony with a 50 cent coin but I am calling it a week due to Steam. This is also causing me to spend a lot more money than I should be. The worst part about Steam sales is that I already have a huge library of games so really have no need to buy more but the newer games that I want are on sale for a really good price so I end up caving in and buying some games and simply have to play them right away so I don't feel guilty for buying and then not playing them. Speaking of which, the game I just bought today has finished downloading so I had better finish writing this!

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.

7DFPS 2013 Postmortem

The 7DFPS 2013 challenge is over. Since the first game-jam that I ever entered was the original 7DFPS, I felt that even though I was only going to be able to put in around 40 hours towards a game that I would still try and get an entry this year. Moon Base Z chapter 1 is my entry. It is in a lot rougher state than I would hope but is a fully playable game. As usual, here is my postmortem for the challenge.

What went right

I quickly came up with a story for the game but almost immediately realized that the story was way too ambitious for a week. This gave me two options: break up the story into chapters and just focus on getting the first chapter done for the challenge or re-work the story so it can fit. As much as I wanted a complete stand-alone game for the challenge, going with the chapter route would not only allow me to finish a playable level, but would give me months of extra time to properly create the game I jotted down. Seeing how I barely managed to get a single chapter finished, this clearly was the correct choice.

What went both right and wrong

As people who have been following this blog already know, I am getting heavy into using Dart as my web programming language. The decision to use Dart was actually a good one as I find myself far more productive using Dart than JavaScript. The plan to port my earlier 7DFPS engine to Dart, however, took far longer than I had anticipated. What is intersting, is that some of the bugs I was looking into in CQFPS were clearly marked as errors or warnings once the code was ported over. I find I am really enjoying Dart as a language, even with its idiosyncrasies and really hope that the language does take off.

What went wrong

I was going to get help with the artwork for the game. Sadly other things happened making it impossible for my artist to contribute directly to this game. Instead I had to cut-and-paste existing artwork and create new artwork.  I also did not have the time to experiment with HTML5 sound, which is something I really need to do.

Conclusion

Overall not as good of a showing as I would like, but the game is far from finished. As I finish off the remaining 3 chapters I do hope that the resulting game will be much better than this first chapter indicates. My plans are to release each chapter as a beta each independently playable. Once all the chapters are out, I will do a final reworking of all the levels and combine it into a single game. I have no timeframe for doing this but do hope that it is sooner rather than later.

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.

7DRL Postmortem

My 7DRL project was not what I consider a success. While technically I had a playable game, it was more of a random maze game than anything else. While the RPG code was mostly done (if you look at the source you can see a couple thousand lines of rpg related classes) it simply was not integrated into the rest of the game. This work will be done and the finished version of the game will be releases eventually but it was not finished within the 7 days of the challenge so it is not a success. That said, here is the postmortem.

What went wrong

Memory is a faulty thing. As this game was to be based on an existing Java game, I was thinking about the project as if all the code was already ported to JavaScript. For this reason I never really took a look at how much code there actually was for the original game. I really don't remember the project being as big as it is. Part of the reason for this is due to the fact that the orignal Dungeon Romp was built on top of the other games in the Ultimate Retro Project as well as borrowing a lot of code from the Coffee Quest series so a lot of the work was already done. I really should have reviewed the code before I started and started porting the common libraries beforehand. Ultimately, I made the rookie mistake of taking on far more than was realistic for a one week period. Next year I will be more prepared.

What went both wrong and right

Porting the code was a mixed blessing. As I mentioned above, there was a huge amount of code that I ended up hand-porting to JavaScript. There are some tools that will cross-compile from Java to JavaScript, but when I looked at them the results were not very good. I want to be able to modify and use the JavaScript code not to work in Java and publish the results as hard to read/modify JavaScript that requires large amounts of support libraries to work. While hand-porting is a lot more time consuming then running code through a tool, it has two huge advantages. You really understand the code that you are porting after you have finished porting it. You are able to take advantage of certain features of JavaScript (dynamic classes, for instance) that a cross-compiler simply will not.

What went right

While I suppose this is not the most significant thing, the thing I am most proud of is my pre-loader. This is the first JavaScript game I wrote that really needed some type of pre-loader. After doing a bit of testing, I found that the code started running before all the script files were loading, so the pre-loader could also include the loading of the scripts as long as the pre-loader script was before the other source script tags. Even if this is not a feature in all browsers, the image loading code will still take the bulk of the loading time though there will be a slightly longer delay before any activity happens. To get something on the screen as quickly as possible, a text message is rendered while the title-screen image starts loading. Once the title screen image is loaded, the other images (condensed into a number of image atlases) are loaded.

While finishing the game in a part-time week was not in the cards, the game will eventually be completed. I am hoping for an April release, but am not committing to anything at this point.

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.