Lucky's Puzzle Carnival is a pack of 3 puzzle games developed by Orbital Cows Entertainment.
While developing this game, I developed a gui framework that works within a Swing JFrame. It uses one JFrame, one JPanel, and a few AWT classes (e.g. Color, Font, and Graphics2D). This framework allows games to look much better when displayed in different sizes, though it lacks much of Swing's feature set.
I also developed a small group of utility classes. For the most part, they're similar to a subset of the existing java.util classes, but they sacrifice certain features for some small performance gains. For instance, there are a couple of Bag classes that function similarly to the ArrayList class but don't maintain the ordering of the elements. This allows the remove method to be O(1) rather than O(N).
My code library generally documents what is thread-safe and what isn't. I attempted to make it thread-safe where it was possible to do without making the code too slow.
Lucky's Puzzle Carnival works on both Mac OS X 10.4+ and Windows XP/Vista. This is the first Mac-compatible game I've developed.
The main problem with Lucky's Puzzle Carnival was that it took way too long to develop. All the library code developed above took a long time to program. The gui framework and the utility classes are both nice to have. However, the time spent coding them was time I should have been finishing the actual game. Had I done that, the game would have been done in the middle of 2008. When I finally got to finishing up the odds and ends, I generated alot of need for new artwork. Had I done some of this earlier, Eduardo could have been working on all that artwork all year. As it was, I created a bottleneck, and there was too much for him to do all at once.
Also, the game performs terribly on computers with integrated graphics. The performance is so bad that even Eduardo doesn't want to play the game. Performance must be improved for future games, especially since these games target casual gamers.
I don't know why LPC's performance is so much worse than Nanotron's, but using JOgl is the likely solution for future games.
The Mac version is inadequate. The demo can't open the website, so that functionality was removed. If the game required Mac OS X 10.5, the functionality could be included. Also, the game is packaged as a .zip file, when it should be packaged as a .app within a .dmg file. I can't figure out how to package the game correctly, but could do so with the Install4J program. However, Install4J is expensive enough to make this not be worthwhile.
There was practically no testing phase. The testing phase occurred, but we were unable to attract many testers.
Version 1.01 was released a month after version 1.00. The new version exists primarily to improve performance on computers with integrated graphics. This was probably a good move and should have been done earlier.
Much the same thing happened with Nanotron. It's just another symptom of our poor planning.
I've noticed that LPC now has almost as many builds as Nanotron. This suggests the number of builds is relatively constant for each project, even though LPC took 50% longer. It should be possible to reduce both the number of builds and the time required to finish the projects.
To reduce the length of the development cycle, we must make sure that all developers are working simultaneously, not me working at one time and then Eduardo working later. Eduardo drew the main art for the game early on, but he didn't draw most of the interface art until later. The reason for this is because there was no way for him to put it into the game until I had written the code for it. In the future, I must make sure that Eduardo can work on the artwork regardless of what other things need to be done.
I should also concentrate more on the program being developed than upon increasing the size of my code library. Even though I don't use extreme programming, it would be wise for me to adopt the tenet of programming only what I need.
Also, we need to develop a strategy for attracting more testers.
Copyright (C) 2009 Steven Fletcher. All rights reserved.
