Thanks sinbad for featuring this project!
JeDi wrote:Look great! I really like the visual style you used. Your image hosting bandwidth seems to be exceeded though. Maybe edit the post so the images link to Ogre's image gallery?
Could you maybe elaborate a bit about the development work flow? I think a lot of people would be interested in that. So what modeling applications did you use, how did you setup the materials, what external libraries did you use, etc.
Greetz,
JeDi
Thanks JeDi. We actually didn't use a single external library besides, of course, Ogre. Our goal was just to build a game from the ground up. For example, I built the 2D physics and collisions using things I read from David Eberly and Christer Ericson's physics/collisions books "Game Physics" and "Real-Time Collision Detection" as well as what I followed on the Bullet forums and physics examples by Olivier Renault and Erin Catto. This enabled me to simulate convex polygon rigid bodies. For the ropes I used a simple algorithm Eric Jordan proposed which is to use Verlet integration with position constraints with a fixed time-step and state interpolation.
The water uses a highly modified version of the fresnel demo, with a fairly efficient depth implementation and faked specular reflections for the wisp particles ( both features I completely designed myself ). The background water sources actually use a technique I concocted myself to warp static depth-reflection maps into the current camera frame. This greatly sped up multiple planar reflections. Unfortunately, there are significant artifacts at the moment because of my inability to finish the algorithm due to time-constraints and because of the immense complexity of it. It would work really well if I could finish it, however. Overall it was just for fun and is too bothersome to implement for general use.
The shadows were really easy to do. We have static lighting that we baked in with Maya and read in as a separate map. And then we have a dynamic light component that I implemented with additive integrated shadow maps and a simple custom camera class that is optimized for the 2D nature of the game.
The shaders took a bit of time. We designed a few generic shaders and "inherited" from those for all the objects in the game. We have a multi-texture shader for the terrain, a prop shader, a water prop shader, and a character shader as well as the water shader mentioned above. This saved a lot of time when applying shaders to certain materials. The major time sink was just learning all the ins and outs of shader programming, such as material definitions, and learning to use CG, and binding shader parameters at run-time.
I also made a curve-fit algorithm to smooth out the weapon trail using a lagrange interpolating polynomial equation. This guarantees that the trail is smooth at low frames or if the weapon is moving quickly. The implementation can be found in CWeaponTrail.cpp in UpdateSegmentCount( ... ). There is still a glitch with it due to the fact that the polynomial expression needs to be a 1-to-1 function and that isn't always satisfied in the current implementation.
As far as work-flow, I started work on the engine a couple months before any artwork was done. My brother couldn't start because at this point we didn't have the actual format of art assets figured out yet. While I was working on the game engine, it was a good time for my brother to design the assets: i.e. the overarching style/color scheme/characters/props... etc. We both put our heads together on this one. We really wanted to do a lot more elaborate things at first but we cut back all of our plans as we went due to the lack of manpower. This was only to be expected, though.
If you are going to work on a project with multiple people, use version control. You'll waste way too much time if you don't. And making games takes a ridiculous amount of time anyway. Some weeks I never saw the light of day. This really made working on things at the same time a breeze, which is often necessary.
When I was done with the game engine, I made the level tools by expanding/customizing LFA to fit the needs of the game. We use Maya so this was done in MEL and Maya API. My brother was then able to model assets in Maya - paint textures in photoshop with a Wacom tablet. Painting the textures took countless hours. There's not really an easy way to do it from what I could see. It just takes a lot of love.
![Smile :)](./images/smilies/icon_smile.gif)
When those assets were done we were able to just export and play the game and I would tweak and add features as we saw fit.
You can view the textures and other assets @
http://www.justinkenneallyart.com
The whole project took an incredible amount of time and commitment - mainly because a lot of the aspects of the game were new territory for both of us. From custom collision, physics, effects, shaders, AI, factory management/custom object scripts, to designing and optimizing game assets. We set out to make this game as a means of studying the process of making games, not really as something that would be overly impressive to look at. Of course we wanted it to look good, but that wasn't our major focus. I'm glad we got a really well-rounded project out of all of this, that was both a major learning experience as well as a semi-successful "proof-of-concept" game.
Ogre was a great foundation for us to learn on and had a great community to help us when we ran into road-blocks.