Yesterday, I was able to restart work on coding my Space Fighter Ace game again after a two week absence of not coding. It wasn't related to the roadmap that I have laid out for Space Fighter Ace, but rather for a future version of Space Fighter Ace.
What I done was to write my first network application, building a very simple server and client with no game logic code. It was as far as I got in coding the network code for my game. However, it was important because I finally got back into coding, which is a necessary activity if I want to improve my chance of getting a ransom model funded project going.
Monday, August 25, 2008
Thursday, August 14, 2008
The 30 Days Postmortem
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.
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.
Labels:
experiment,
game development,
postmortem,
productivity
Sunday, August 10, 2008
Day 30: Performance and Tutorial Work
Today, I spent time trying to optimize my game's FPS from a pitiful 15-20 FPS to acceptable 30. Though, it still seems to suffer from having too many objects in the game, which may make large scale battles impractical and possibly limit the game to a few fighters and objects.
For practically 90% of the increase in FPS, I merely eliminate most of the 900 map objects, it would still pose a significant problem if a users were to add lot of map tiles though.
It seem that the engine is improving during this iteration of game development. So much, that I decided to port the engine code back to KRPGE sooner rather than later. See the roadmap for details.
However, I soon hit a roadblock on my optimization problem because I don't know how to optimize further and the lack of available immediate help. So I decided to focus my development effort entirely somewhere. For that, I choose to work on my Rubygame Book.
The development work was especially fruitful because I finished part 3 and started work on part 4.
I still hope to return back to game development work because I got a gloomy feeling about Space Fighter Ace's development cycle. I feel it will be a long slog before I finally complete its development goal. For this, I estimated at least a month.
Well, this is the last post of the 30 days challenge log! A postmortem of the 30 days challenge will be written soon.
For practically 90% of the increase in FPS, I merely eliminate most of the 900 map objects, it would still pose a significant problem if a users were to add lot of map tiles though.
It seem that the engine is improving during this iteration of game development. So much, that I decided to port the engine code back to KRPGE sooner rather than later. See the roadmap for details.
However, I soon hit a roadblock on my optimization problem because I don't know how to optimize further and the lack of available immediate help. So I decided to focus my development effort entirely somewhere. For that, I choose to work on my Rubygame Book.
The development work was especially fruitful because I finished part 3 and started work on part 4.
I still hope to return back to game development work because I got a gloomy feeling about Space Fighter Ace's development cycle. I feel it will be a long slog before I finally complete its development goal. For this, I estimated at least a month.
Well, this is the last post of the 30 days challenge log! A postmortem of the 30 days challenge will be written soon.
Saturday, August 9, 2008
Day 29: Space Fighter Ace is Slowly Being Built
Today is Day 29, so tomorrow is the last day of my programming challenge to code 4 hours a day.
With 4 hours a day, I am slowly crafting Space Fighter Ace game mechanic, with some markup in difficulty in comparison to previous projects.
Today, I finally accomplished the death mechanism of spacecraft and bullets collision, although it have no special effects. I believed it took me two hours to accomplish this task. Another hour is spent on trying to futilely finish the movement code to no avail. The rest is spent on miscellaneous task such as trying to debug the mapeditor program, writing FPS display code for the Hud, and improving the game's FPS.
With 4 hours a day, I am slowly crafting Space Fighter Ace game mechanic, with some markup in difficulty in comparison to previous projects.
Today, I finally accomplished the death mechanism of spacecraft and bullets collision, although it have no special effects. I believed it took me two hours to accomplish this task. Another hour is spent on trying to futilely finish the movement code to no avail. The rest is spent on miscellaneous task such as trying to debug the mapeditor program, writing FPS display code for the Hud, and improving the game's FPS.
Friday, August 8, 2008
Day 28: More Gameplay Work
For today, I mostly focused on writing gameplay features such as the capability to shoot projectiles and then destruction.
Though, I mostly got stuck trying to figure out why the projectile have collision problem. It took me a while that the rect size is too big for that image. I promptly fixed it.
After that, shooting finally work. I then code a feature to allow the projectile to go faster than the player at a given speed.
I also added an enemy object and remove all its unnecessary legacy code.
I cleaned up Characters Law and then started work on a new feature that will ignore certain objects for collision detection purpose. I also did refactoring that allow player, projectiles, and enemies to share common characteristics.
Though, I mostly got stuck trying to figure out why the projectile have collision problem. It took me a while that the rect size is too big for that image. I promptly fixed it.
After that, shooting finally work. I then code a feature to allow the projectile to go faster than the player at a given speed.
I also added an enemy object and remove all its unnecessary legacy code.
I cleaned up Characters Law and then started work on a new feature that will ignore certain objects for collision detection purpose. I also did refactoring that allow player, projectiles, and enemies to share common characteristics.
Thursday, August 7, 2008
Day 27: Learning Trignometry and More
Although, I been practically gone all afternoon and all morning, I was able to start coding by 16:00 and finish the session for 20:00.
I got a little lecture from Beoran on trig so I can figure out what the heck I am doing with the movement code. Thus, I learned enough to figure out the angle for moving left. The lesson and movement code were incomplete though.
Since I probably didn't have much to do for movement code, I worked on other part of the game instead. I worked on the weapon, rewriting and cleaning up. Due to what the weapon system require and how I need the game to work, I extended the engine to allow for adjustable camera movement and then add an easy way to add characters. I also did the usual cleanup such as eliminating obsolete source code and data files.
I got a little lecture from Beoran on trig so I can figure out what the heck I am doing with the movement code. Thus, I learned enough to figure out the angle for moving left. The lesson and movement code were incomplete though.
Since I probably didn't have much to do for movement code, I worked on other part of the game instead. I worked on the weapon, rewriting and cleaning up. Due to what the weapon system require and how I need the game to work, I extended the engine to allow for adjustable camera movement and then add an easy way to add characters. I also did the usual cleanup such as eliminating obsolete source code and data files.
Wednesday, August 6, 2008
Day 26: More Movement Code
Today, I started to delve into an unknown terrority, forcing me to use geometry that I never used before in game programming. Progress is slow as I struggle with the challenge.
Right now, I am trying to implement angle based movement so that my space craft has a more realistic movement. I think I got the up angle movement right.
I also accomplish other task. For example, I decided to expand the resolution to allow for UI. Then, I implement a HUD class to give me information on velocity for debugging purpose.
Right now, I am trying to implement angle based movement so that my space craft has a more realistic movement. I think I got the up angle movement right.
I also accomplish other task. For example, I decided to expand the resolution to allow for UI. Then, I implement a HUD class to give me information on velocity for debugging purpose.
Tuesday, August 5, 2008
Day 25: Cooking up Movement Code
The second day of development is all focused on getting the movement code for the player right.
So I spent much of my morning hours writing movement code and rotation code, although I still have to take care of fixing crash bugs because I forgot to include a few files in the mapeditor program.
The rotation code is pretty much complete. You can rotate counterclockwise and clockwise as well stop. The movement code, is on the other hand, have incomplete physics. Although you will go faster with accelerating and then you will continue to move even after you stop, it doesn't take into account the angle of movement.
This will be rectified the next day, I am sure.
5 more days to go!
Labels:
experiment,
game development,
log,
productivity,
ruby,
space fighter ace
Monday, August 4, 2008
Day 24: KRPGE Finished, SpaceFighterAce Next
KRPGE is finished in two days! That was quick. Then, I started work on the development of SpaceFighterAce.
First, I had to import svn into git before I can push it, which took me about an hour to figure it out. Then I pushed it to github and use the newly released KRPGE for this project.
At last, I spent time coding and finding graphic for the game. I decided to use a NASA picture as terrain.
This game is going to be awesome!
First, I had to import svn into git before I can push it, which took me about an hour to figure it out. Then I pushed it to github and use the newly released KRPGE for this project.
At last, I spent time coding and finding graphic for the game. I decided to use a NASA picture as terrain.
This game is going to be awesome!
Release Log #4
KRPGE-0.0.3 is out!
This release now support terrains. It also got a bit of code cleanup too.
As for the map editor, the README documentation for it was improved. It also got FPS boost.
This release now support terrains. It also got a bit of code cleanup too.
As for the map editor, the README documentation for it was improved. It also got FPS boost.
Sunday, August 3, 2008
Day 23: KRPGE 0.0.3 Works Began
Though I didn't do game development in the morning as I usually do, I still managed to do 4 hours of development.
The main objective for KRPGE 0.0.3 was achieved surprisingly fast and with a few improvement and slight modification over Playground Wars's code. Terrain support, though it suprisngly requires more code than I expected, was completed in the span of two hours. Huzzah!
I also began work on eliminating the redundancy found in EditEngine and GameEngine found in the KRPGE's two program as a neccessary unplanned project along the way to the secondary objective, which is to clean up the Camera's redundant codebase.
Than I began work on the camera itself, writing a method that can be used in all 4 directions and then getting the horzontial movement methods to use the new all purpose method.
Today is fantastic.
7 more days until I achevie my goal!
The main objective for KRPGE 0.0.3 was achieved surprisingly fast and with a few improvement and slight modification over Playground Wars's code. Terrain support, though it suprisngly requires more code than I expected, was completed in the span of two hours. Huzzah!
I also began work on eliminating the redundancy found in EditEngine and GameEngine found in the KRPGE's two program as a neccessary unplanned project along the way to the secondary objective, which is to clean up the Camera's redundant codebase.
Than I began work on the camera itself, writing a method that can be used in all 4 directions and then getting the horzontial movement methods to use the new all purpose method.
Today is fantastic.
7 more days until I achevie my goal!
Saturday, August 2, 2008
Release Log #3
Day 22: Finished MapEditor and Doing Tutorial Work
Well, I finished MapEditor's rendering bug and made it ready to be released. For that, I spent 1 hours getting nowhere and the finishing it relatively quickly the next hour after being confused for 10 minutes.
Since I have nothing to do, I decided to work on my tutorial. I completed part 1 and even managed to start working on part 2.
Tommorow, I will start work on KRPGE 0.0.3. For now, I must release my mapeditor in the form of KRPGE 0.0.2
Since I have nothing to do, I decided to work on my tutorial. I completed part 1 and even managed to start working on part 2.
Tommorow, I will start work on KRPGE 0.0.3. For now, I must release my mapeditor in the form of KRPGE 0.0.2
Friday, August 1, 2008
Day 21: Wrapping up Mapeditor Development
Today, I finished both the map stamping option scroller and the editing system as well. So you can edit maps and cycle through the options that you want to stamp.
The only thing left is writing messages for the logger and fixing typing rendering bug, as well writing the README for the map editor.
It will be released as KRPGE-0.0.2 instead of a standalone application. After that, I'll be working on the next version of KRPGE, incorporating any useful stuff leftover from the playground project.
9 more days left! :D
The only thing left is writing messages for the logger and fixing typing rendering bug, as well writing the README for the map editor.
It will be released as KRPGE-0.0.2 instead of a standalone application. After that, I'll be working on the next version of KRPGE, incorporating any useful stuff leftover from the playground project.
9 more days left! :D
Labels:
experiment,
game development,
krpge,
log,
mapeditor,
productivity
Subscribe to:
Posts (Atom)