My 30 days 4 hours a day programming challenge is officially a success. It has propel me to new heights in such rapid pace not seen in the 2 years I been programming. I also learned what it meant to be a disciplined programmer and learned a few new tricks as well.
During the 30 days challenge, I worked on the game engine and the map editor for the KRPGE project, Playground Wars, Space Fighter Ace and the Rubygame Tutorial project.
What I Learn:
I have learned through the 28 hours workweek why my game development projects has been so slow to progress in the past. They just took a lot of work. Even with the 28 hours work week, I still felt that progress is very slow. Nonetheless, I managed to finish the KRPGE's engine proportion in about 14 days. The Map Editor is finished in about the same timeframe.
What went right:
Of course, I was able to keep the schedule despite interruption by parents and outside events. Best of all, I was able to progress phenomenally fast in comparsion to my usual pace of development.
What went wrong:
If there is any wrongdoing, it is that I was undisciplined when it come to designing my game engine's codebase. Although it was easy for me to use, for others, with no documentation, cannot use it. There are several releases of KRPGE but nobody use it except me.
What I would do differently:
I would learn unit testing and set up a bugtracker for each projects. I would also package all my games as gem. Also, it would be nice if I know more about optimization technqiues as my games tend to fall below 30.
What I gained from this challenge:
The most improtance gain is productivity, above all. I finally broke the cycle of procrastination and no game development. I tried many schemes but none work as well as the enforced work hours, in which I was driven to develop under pressure. This build upon my experience from the first RubyWeekend contest. I will continue to use this concept to help keep game development going.
I also gained a newfound apperciation of the difficulty of writing games evidenced by the slow development cycle.
Still, all of these sucess would mean nothing if I don't keep on the pressure on myself to continue game development at this kind of level. That's the next challenge.
Showing posts with label postmortem. Show all posts
Showing posts with label postmortem. Show all posts
Thursday, August 14, 2008
Tuesday, July 29, 2008
RubyWeekend #2 Postmortem
Here is my postmortem for Playground Wars for the RubyWeekend #2 contest. I hope it will be useful for future RubyWeekend newbies and veterans alike as well present day RubyWeekend pioneers.
What went right:
1. Getting an art partner is a very smart choice, especially if he/she is good. Qubodup is good and he free up my time so I can program. Division of labors kick butt!
2. Prior to the contest, I spent at least 30 hours on the KRPGE engine for the purpose of writing RPG games. Nonetheless, it was quite adaptable to RTS format. Plus, most of the map stuff has been done for me. I had to modify it so it can support terrain images. This free up my time to work on gameplay features. Code reuse ROCK!
What went wrong:
1. Choosing the wrong ideas can be fatal, even if the idea is a good idea. It need to be implementable in a short period of time. I think the lesson is clear here: DO NOT! I REPEAT! DO NOT attempt RTS games in a 48 hours contest. There is no way you're going to implement all the units, the tech tree, the whole 9 yards of features and test, blanace them all, let alone a stripped down RTS game.
2. Do not jeapodrize your contest entry with a bad sleep schelude. 4 hours of sleep each is not enough. Please make sure you get plenty of sleep before the contest start. It might not hurt(Actually it probably does) but you need every bit of energy and focus you can get. I was very tired so I stop coding several hours before the contest end.
3. Communication is hard. Time and time again, I learned that the communication of ideas is rather faulty. For example, Qubodup told me about a bug and I didn't realize what the bug is about after the contest. Qubodup and I had to explain our ideas to each other repeatly or correct misinformation each other have. For example, I didn't realize that Qubodup was asking about the whole map resolution, not the indiviual resolution of map terrain images.
What I Would Do Differently:
1. Write more engine code. Having more code that you can use to create games is a good thing, as well let you focus on writing games instead of writing an engine.
2. Complete the map editor or any other tools that you will need first. It does you no good to have a very difficult map to edit when you got better things to do.
3. Try to choose a less amibitious game so you can actually complete it and have a better chance of rocking everyone's boat.
General Thought About the Compos:
We need a RubyWeekend site, seriously. And advertising. Lot more advertising. We advertise quite a bit more this time around, but apparently that is not enough. We got the same amount of entries as last time(7 of them).
That is all.
I am out!
What went right:
1. Getting an art partner is a very smart choice, especially if he/she is good. Qubodup is good and he free up my time so I can program. Division of labors kick butt!
2. Prior to the contest, I spent at least 30 hours on the KRPGE engine for the purpose of writing RPG games. Nonetheless, it was quite adaptable to RTS format. Plus, most of the map stuff has been done for me. I had to modify it so it can support terrain images. This free up my time to work on gameplay features. Code reuse ROCK!
What went wrong:
1. Choosing the wrong ideas can be fatal, even if the idea is a good idea. It need to be implementable in a short period of time. I think the lesson is clear here: DO NOT! I REPEAT! DO NOT attempt RTS games in a 48 hours contest. There is no way you're going to implement all the units, the tech tree, the whole 9 yards of features and test, blanace them all, let alone a stripped down RTS game.
2. Do not jeapodrize your contest entry with a bad sleep schelude. 4 hours of sleep each is not enough. Please make sure you get plenty of sleep before the contest start. It might not hurt(Actually it probably does) but you need every bit of energy and focus you can get. I was very tired so I stop coding several hours before the contest end.
3. Communication is hard. Time and time again, I learned that the communication of ideas is rather faulty. For example, Qubodup told me about a bug and I didn't realize what the bug is about after the contest. Qubodup and I had to explain our ideas to each other repeatly or correct misinformation each other have. For example, I didn't realize that Qubodup was asking about the whole map resolution, not the indiviual resolution of map terrain images.
What I Would Do Differently:
1. Write more engine code. Having more code that you can use to create games is a good thing, as well let you focus on writing games instead of writing an engine.
2. Complete the map editor or any other tools that you will need first. It does you no good to have a very difficult map to edit when you got better things to do.
3. Try to choose a less amibitious game so you can actually complete it and have a better chance of rocking everyone's boat.
General Thought About the Compos:
We need a RubyWeekend site, seriously. And advertising. Lot more advertising. We advertise quite a bit more this time around, but apparently that is not enough. We got the same amount of entries as last time(7 of them).
That is all.
I am out!
Wednesday, June 18, 2008
RubyWeekend Postmortem
This postmortem is about my first game entry for the first ever Ruby game programming competition. This game is called The CopyPirate.
What went right?
1. I finished my game before everyone else. This is probably because I was motivated by my previous failure to submit my game in time for PyWeek, the first contest that I participate in. The shorter time also don't give me breathing room so I forged ahead of everybody.
2. Merging and reusing my code was a snap. I was able to use most of the code from Twisted Shootout and SpaceFighterAce and merge them together. Very little time is spent on coding new gameplay elements. I was probably the laziest programmer in the entire contest.
3. There are little downtime. I did not have to waste 3 hours in tracking down bugs. Because the codebase was essentially finished even before there was even a codebase, the code I used were proven to work and are generally free of bugs.
What went wrong?
1. Readme's instruction manual were difficult to get it right. Because I did not use virtual machines, I have to relies on others to check my work. It took me several try to get it right. Even as I finished the instruction, I lack information on how to install rubygem, a package manager essential to the installing process.
2. My codebase have magic number syndrome. Even though my codebase was known to work, it was also entirely undocumented. This make future modification of the codebase in delicate and complicated areas risky operations.
3. The game have uncompelling gameplay. Due to my lack of knowledge about gamepplay design, my game wasn't able to compell anybody to vote for my game. Thus I probably rank dead last or near dead last in the contest.
What I learned.
1. People like to read programming journals. It also draws traffics, which boost ads revenues as a bonus.
2. Extreme but reasonable deadline and blogging are useful productivity tools. I look forward to using it outside of this contest.
3. I learned that what I see in my text editor isn't actually what I will actually see in my git repoistory. I was also advised not to use tab space, but instead, actual spaces. Tabs ruins formatting I believed I was told.
What I would do differently.
1. I would clean up, document, and port my map engine so I haave more time to work on the gameplay during the contest.
2. I would try a rush hour every 8 hours or so. The rush hour is when I just simply focus all my energy on coding rather than spending part of my time chatting on IRC.
3. I would try to find a teammate to do the artwork for me so I can focus purely on coding and gameplay design.
What went right?
1. I finished my game before everyone else. This is probably because I was motivated by my previous failure to submit my game in time for PyWeek, the first contest that I participate in. The shorter time also don't give me breathing room so I forged ahead of everybody.
2. Merging and reusing my code was a snap. I was able to use most of the code from Twisted Shootout and SpaceFighterAce and merge them together. Very little time is spent on coding new gameplay elements. I was probably the laziest programmer in the entire contest.
3. There are little downtime. I did not have to waste 3 hours in tracking down bugs. Because the codebase was essentially finished even before there was even a codebase, the code I used were proven to work and are generally free of bugs.
What went wrong?
1. Readme's instruction manual were difficult to get it right. Because I did not use virtual machines, I have to relies on others to check my work. It took me several try to get it right. Even as I finished the instruction, I lack information on how to install rubygem, a package manager essential to the installing process.
2. My codebase have magic number syndrome. Even though my codebase was known to work, it was also entirely undocumented. This make future modification of the codebase in delicate and complicated areas risky operations.
3. The game have uncompelling gameplay. Due to my lack of knowledge about gamepplay design, my game wasn't able to compell anybody to vote for my game. Thus I probably rank dead last or near dead last in the contest.
What I learned.
1. People like to read programming journals. It also draws traffics, which boost ads revenues as a bonus.
2. Extreme but reasonable deadline and blogging are useful productivity tools. I look forward to using it outside of this contest.
3. I learned that what I see in my text editor isn't actually what I will actually see in my git repoistory. I was also advised not to use tab space, but instead, actual spaces. Tabs ruins formatting I believed I was told.
What I would do differently.
1. I would clean up, document, and port my map engine so I haave more time to work on the gameplay during the contest.
2. I would try a rush hour every 8 hours or so. The rush hour is when I just simply focus all my energy on coding rather than spending part of my time chatting on IRC.
3. I would try to find a teammate to do the artwork for me so I can focus purely on coding and gameplay design.
Subscribe to:
Posts (Atom)
