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.
Showing posts with label game jam. Show all posts
Showing posts with label game jam. Show all posts
Friday, March 28, 2014
Sunday, February 23, 2014
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.
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.
Friday, January 31, 2014
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.
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.
Thursday, December 26, 2013
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.
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.
Saturday, November 30, 2013
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!
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!
Friday, September 20, 2013
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.
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.
Thursday, September 5, 2013
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.
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.
Friday, August 23, 2013
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.
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.
Sunday, July 28, 2013
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.
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.
Thursday, May 2, 2013
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.
Thursday, March 21, 2013
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.
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.
Thursday, February 21, 2013
Lots of Jam
The next few weeks are going to be interesting as there are a bunch of game jams that I am thinking about participating in. The mini-Ludum Dare this weekend is a game based on the real world. I have a simple but interesting idea for this game. What I haven't decided is if I am going to do the game in Flash or in JavaScript. I do want to move away from Flash and towards HTML5 but I am far more productive in ActionScript.
Shortly after that is the Game in Ten Days #30. This is a longer duration challenge which actually puts me at a huge disadvantage. Clearling out a weekend is something that is easily done. 10 days, not so much. People who have 10 solid days to work on a project will clearly be able to do better than 10 part-time days so winning the prize is probably not remotely likely. Still, if the theme is interesting then it may be worth losing my weekends and evenings. Besides, I really should start trying to take advantage of Kongregate which is something I have never done.
After that challenge is another week-long one. As there is no prize other than a completed game there is no real disadvantage to working on it in my spare time. That said, my plans for this are not to create a new game but to create a JavaScript sequel to a Java game that I created. As a lot of the game logic exists, this should be fairly quick to implement, and I really do want to start porting all of my older Java games to HTML5 especially since there seem to be a lot of vulnerabilities with Java lately.
As I created a twitter account for the One Game a Month challenge, I will post frequent progress updates to my twitter feed, not that anybody actually cares. Still, I figure there may be somebody who does decided to follow me on twitter and if not I will have a record of my work for my personal use if I get around to writing postmortems on any of these challenges.
Thursday, February 7, 2013
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.
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.
Thursday, January 24, 2013
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.
Thursday, January 10, 2013
2013 Plans
I am sure that anybody who regularly reads this blog already has a good idea what my plans for 2013 are, but I figure I should go over them anyway for the record. While I was originally planning on developing Color Collapse Plus over the year, that was before I actually started participating in game jams. I may still work on that project as it was my mothers favorite game, but my priority for 2013 will be on a number of larger commercial projects. As I want to have regular content for the site, I am planning on participating in game jams such as Ludum Dare. The games developed during these challenges will make up the bulk of the site game releases, with the remaining releases being updates of already existing games until I actually finish one of my larger projects.
My larger projects will be targeted towards tablets and possibly smart-phones. The target platforms will be iOS and Android, though I may also port to Windows 8 tablets/phones if the effort will not be too great. Once the tablet releases are done, I intend on porting the game to the browser (probably Flash but HTML 5 isn't inconceivable). The browser versions will be broken into a number of episodes and released in installments.
My game jam work will initially be done in Flash but as my GameJam library reaches maturity (hopefully by this summer) I will port it to HTML 5 and transition to using that if the performance is adequate. While ActionScript and JavaScript are very similar, I am just way more comfortable with ActionScript as it has language constructs that make it much nicer for working with larger-scale projects. Still, JavaScript is quickly becoming the language of the web, though a lot slower than the experts predicted. I personally think Flash will be viable for at least another 3-5 years. If Adobe gets their head out of their butt and create an ActionScript to JavaScript compiler it may be significantly longer though the resulting Flash programs would be "native" HTML 5. Sadly I suspect that Adobe will let Flash whither away and instead try to turn their new Edge Animate software into the replacement for Flash.
I have not decided which games I will be updating, so if anybody reading this feel free to email me with your favorite game and I will put that game on the top of my update list. Updating will include cosmetic updating as well as (for Java and Flash games) porting the game to HTML 5.
My larger projects will be targeted towards tablets and possibly smart-phones. The target platforms will be iOS and Android, though I may also port to Windows 8 tablets/phones if the effort will not be too great. Once the tablet releases are done, I intend on porting the game to the browser (probably Flash but HTML 5 isn't inconceivable). The browser versions will be broken into a number of episodes and released in installments.
My game jam work will initially be done in Flash but as my GameJam library reaches maturity (hopefully by this summer) I will port it to HTML 5 and transition to using that if the performance is adequate. While ActionScript and JavaScript are very similar, I am just way more comfortable with ActionScript as it has language constructs that make it much nicer for working with larger-scale projects. Still, JavaScript is quickly becoming the language of the web, though a lot slower than the experts predicted. I personally think Flash will be viable for at least another 3-5 years. If Adobe gets their head out of their butt and create an ActionScript to JavaScript compiler it may be significantly longer though the resulting Flash programs would be "native" HTML 5. Sadly I suspect that Adobe will let Flash whither away and instead try to turn their new Edge Animate software into the replacement for Flash.
I have not decided which games I will be updating, so if anybody reading this feel free to email me with your favorite game and I will put that game on the top of my update list. Updating will include cosmetic updating as well as (for Java and Flash games) porting the game to HTML 5.
Thursday, December 13, 2012
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.
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.
Thursday, September 6, 2012
Ludum Dare #24 postmortem
People who have visited Blazing Games last week or who are following me on Google Plus already know that I recently participated in the Ludum Dare #24 challenge. This is a challenge where you have 48 hours to develop a game that reflects on the theme of the challenge. This theme is announced at the start of the challenge and this time was Evolution. For this fortnight's post, I have decided to write a mini-postmortem of my entry.
What went right
This was my first Ludum Dare but I had participated in the 7DFPS challenge so I was aware of how quick time goes by in these type of challenges so from the beginning decided that the best way of proceeding was to quickly get a functional game and then iterate on it. The theme of evolution immediately gave me the idea of missing links so the first pass of the game was simply a search of the map for the missing links. I then cleaned up the game to make sure I had something to release before the deadline. Finally I added the combat to the game.
My other wise decision was to take advantage of the photography rule. The challenge allows use of photographs and generated sounds as long as they are created during the 48 hours of the challenge. By quickly taking some photos and using a sound effects generator I was quickly able to come up with good looking game assets in a really short period of time. This gave my game a more polished look without the time burden.
What went wrong
The biggest mistake I made was not having a library of game code ready beforehand. Writing an engine from scratch is not really a good idea when you have time pressures. When you consider that one of the complaints for my game was the sluggishness of the scrolling, Having an optimized map class to start with would have been much nicer and would have given me more time to fine tune the game.
The combat was a bit too last-minute so ended up being a bit more difficult than what I would have liked. I should have listened to the voice in the back of my head telling me to cut the speed of the spiders down and lengthen the whip. I didn't and as a result a lot of people found the game too challenging to finish.
I am thinking that entering game jams will become a bigger part of my life. I really don't care if I win, but do enjoy the challenge and can use the resulting game on my site while I start focusing on the development of larger scale games that can actually turn Blazing Games into a real company instead of a hobby.
What went right
This was my first Ludum Dare but I had participated in the 7DFPS challenge so I was aware of how quick time goes by in these type of challenges so from the beginning decided that the best way of proceeding was to quickly get a functional game and then iterate on it. The theme of evolution immediately gave me the idea of missing links so the first pass of the game was simply a search of the map for the missing links. I then cleaned up the game to make sure I had something to release before the deadline. Finally I added the combat to the game.
My other wise decision was to take advantage of the photography rule. The challenge allows use of photographs and generated sounds as long as they are created during the 48 hours of the challenge. By quickly taking some photos and using a sound effects generator I was quickly able to come up with good looking game assets in a really short period of time. This gave my game a more polished look without the time burden.
What went wrong
The biggest mistake I made was not having a library of game code ready beforehand. Writing an engine from scratch is not really a good idea when you have time pressures. When you consider that one of the complaints for my game was the sluggishness of the scrolling, Having an optimized map class to start with would have been much nicer and would have given me more time to fine tune the game.
The combat was a bit too last-minute so ended up being a bit more difficult than what I would have liked. I should have listened to the voice in the back of my head telling me to cut the speed of the spiders down and lengthen the whip. I didn't and as a result a lot of people found the game too challenging to finish.
I am thinking that entering game jams will become a bigger part of my life. I really don't care if I win, but do enjoy the challenge and can use the resulting game on my site while I start focusing on the development of larger scale games that can actually turn Blazing Games into a real company instead of a hobby.
Subscribe to:
Posts (Atom)
