30867 Lines of Code coded.
01/24/10 - 10:40:53 PM
Now it's time to get the real work started.
For those of you just joining us, let me give you a brief history of Lazy Wars. I started preparing for the project by reading the OpenGL superbible in spring 2008 and I announced the project at the start of my summer vacation. I started releasing pieces of the high level design document and collision demos. Winter 2008 I planned on starting the real coding in the project. I started by coding the GUIs and about 2 weeks in I remembered hand rolling GUIs is like pulling teeth so I started working on the collision detection.
Due to an inherently flawed design, the collision detection work had to be thrown out, and very little got finished by the end of winter vacation. Due to a heavy spring semester, I couldn't get any real work done until the beginning of summer. The summer came and of course my new approach to collision detection didn't work either.
I was about put the project on indefinite hiatus, but I stumbled on a painfully simple solution to my problems while constructing a Circle/AABB sweep test. The problem was that collision detection and collision handling are two separate things. Every approach used before involved detecting a collision and immediately correcting position and motion. By properly modularizing the collision detection, position correction, and velocity/force calculation, everything is now running smoothly.
So over this winter break the collision detection engine was finished. This was no small feat. Even with only 3 types of objects (AABBs, Circles, OBBs), it's time consuming to construct collision tests, sweep tests, and normal calculation routines. Not only do the tests have to work, they have to be optimized and this is where a BSP Tree comes in. At first, I didn't really feel like constructing one, but it managed to more than double my performance when it was finished.
Along with finishing and (half) documenting the collision engine, I also had to tweak the rendering engine to support split screen. Now I just finished the weapon's class and I'm ready to start designing and coding the 16 weapons used in this game.
Looks like this game is actually going to get finished now =)
The game is currently in it's ugly place holder art stage so there isn't really much to show off. However, it looks like there's a very good chance I'll have something playable by April 2nd (the end of spring break).
Wish me luck.
Dev Blog Archive
For those of you just joining us, let me give you a brief history of Lazy Wars. I started preparing for the project by reading the OpenGL superbible in spring 2008 and I announced the project at the start of my summer vacation. I started releasing pieces of the high level design document and collision demos. Winter 2008 I planned on starting the real coding in the project. I started by coding the GUIs and about 2 weeks in I remembered hand rolling GUIs is like pulling teeth so I started working on the collision detection.
Due to an inherently flawed design, the collision detection work had to be thrown out, and very little got finished by the end of winter vacation. Due to a heavy spring semester, I couldn't get any real work done until the beginning of summer. The summer came and of course my new approach to collision detection didn't work either.
I was about put the project on indefinite hiatus, but I stumbled on a painfully simple solution to my problems while constructing a Circle/AABB sweep test. The problem was that collision detection and collision handling are two separate things. Every approach used before involved detecting a collision and immediately correcting position and motion. By properly modularizing the collision detection, position correction, and velocity/force calculation, everything is now running smoothly.
So over this winter break the collision detection engine was finished. This was no small feat. Even with only 3 types of objects (AABBs, Circles, OBBs), it's time consuming to construct collision tests, sweep tests, and normal calculation routines. Not only do the tests have to work, they have to be optimized and this is where a BSP Tree comes in. At first, I didn't really feel like constructing one, but it managed to more than double my performance when it was finished.
Along with finishing and (half) documenting the collision engine, I also had to tweak the rendering engine to support split screen. Now I just finished the weapon's class and I'm ready to start designing and coding the 16 weapons used in this game.
Looks like this game is actually going to get finished now =)
The game is currently in it's ugly place holder art stage so there isn't really much to show off. However, it looks like there's a very good chance I'll have something playable by April 2nd (the end of spring break).
Wish me luck.
Dev Blog Archive