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.
Thursday, April 4, 2013
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.
Saturday, March 9, 2013
Plans for 7DRL
I was thinking about participating in the Game in Ten Days challenge. When the theme of "Dungeon" was announced, I was still thinking about it but noticed it is very similar to the plans I had for the 7DRT challenge which I want to participate in. I roughed out a different style of game but quickly realized that my plans were unrealistic for the amount of time I would actually have available so will hold out until a future GiTD challenge to participate.
For the 7DRL, I want to do a new version of my Ultimate Retro Project (episodes 59 and 60) game Dungeon Romp. This game will be created in JavaScript (the original was in Java). I haven't decided if the game will be called Dungeon Romp 2, Dungeon Romp II, or Dungeon Romp Deluxe yet. I want the game to focus much more on the randomness that is traditional in a rogue-type game. There are three areas where this will be done.
Obviously, the random map generation is the key. I know the map generator from the original game is not the greatest, but will use that as the starting point. The re-implementation may also be the ending point as the maps from DR were good-enough so reworking the code will be done near the end of development if time allows. As time will probably not allow, expect just a tweaked version of the Dungeon Romp maps.
Items will be the big thing that I will try to focus randomness on. The types of items available will vary from game to game as well as (within realistic ranges) the properties of those items. One game may have swords being the best weapon to have, while the next one battle-axes may have superior models and stats. Magic will have both beneficial and detrimental variants with a possibility of some spells being a mix of both (think of a spell that causes massive damage on an opponent but at the same time reduces the melee skill of the player for a number of turns).
Finally, I would like to have more varieties of monsters. Both in the type of monsters and how powerful those monsters are. In one game you may face level-1 goblins which are easy to defeat, while the next time the goblins will be generated at level 5 stats so the player has to re-familiarize him/herself with the monsters in every play.
That is my plans for this first-ever 7DRL. If nothing unexpected happens, I should be able to put in 50-60 hours durring the next 168 hours available to me so have a good shot of having a finished game.
For the 7DRL, I want to do a new version of my Ultimate Retro Project (episodes 59 and 60) game Dungeon Romp. This game will be created in JavaScript (the original was in Java). I haven't decided if the game will be called Dungeon Romp 2, Dungeon Romp II, or Dungeon Romp Deluxe yet. I want the game to focus much more on the randomness that is traditional in a rogue-type game. There are three areas where this will be done.
Obviously, the random map generation is the key. I know the map generator from the original game is not the greatest, but will use that as the starting point. The re-implementation may also be the ending point as the maps from DR were good-enough so reworking the code will be done near the end of development if time allows. As time will probably not allow, expect just a tweaked version of the Dungeon Romp maps.
Items will be the big thing that I will try to focus randomness on. The types of items available will vary from game to game as well as (within realistic ranges) the properties of those items. One game may have swords being the best weapon to have, while the next one battle-axes may have superior models and stats. Magic will have both beneficial and detrimental variants with a possibility of some spells being a mix of both (think of a spell that causes massive damage on an opponent but at the same time reduces the melee skill of the player for a number of turns).
Finally, I would like to have more varieties of monsters. Both in the type of monsters and how powerful those monsters are. In one game you may face level-1 goblins which are easy to defeat, while the next time the goblins will be generated at level 5 stats so the player has to re-familiarize him/herself with the monsters in every play.
That is my plans for this first-ever 7DRL. If nothing unexpected happens, I should be able to put in 50-60 hours durring the next 168 hours available to me so have a good shot of having a finished game.
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.
Subscribe to:
Posts (Atom)
