Plan for Timothy C. Pelham

Nitrous Butterfly -- Moving forward after Alien Defense

This has also been posted on our forums, but I figured I would post this here as well to let more people now what we're working on. This is my longest .plan to date, but I wanted to get the community more involved in our productions.

As a foreword we are currently not using the Torque engine. We are building our own internal technologies. There are screencaps for those that like to see pretty pictures...


Carnage .plan
Nitrous Butterfly
July 22, 2005
==============================================================

Off Topic
We have received a lot of feedback on Alien Defense. Some good and some bad, but response of any kind is good in my book. Alien Defense is understandably a simple game and we are currently working on a patch to resolve some of the bugs in the game. We hope to have this out soon.

Carnage
While we were prepping for the release of Alien Defense I started going back over our internal technologies and basically ripping and shredding it and adding all sorts of new functionality to it. Alien Defense was my first attempt at writing a game from scratch in C++ and I learned an extreme amount from it. Looking back on the existing code I found a lot of things I could have done differently. After looking through what we had and analyzing our design process I realized that what we really needed were some better, more integrated tools for designing our environments. Alien Defense didn't require quite a lot so everything level wise was really quite simple.

My first real push for our engine was to have a much more powerful and robust GUI system. I spent quite a bit of time researching and looking into different GUI APIs to see if there was something I could integrate into our current engine. After looking around and not finding anything that quite matched my expectations I decided to write my own. I did some study and some planning and that hit the ground running with some coding. I decided on some things that I wanted from this GUI system:

1. Absolutely has to be skinnable!
2. Once written it needs to be easy to use...get the hard part out of way with the core design so adding on and creating GUIs would be a snap.
3. It needs to be fast and responsive (seen too many that felt like I was dragging a window through mud)

OK...I'm sure I had more, but that's all I can think of at the moment. So because I'm a visual person I started writing the look and feel and basic functionality first. I started with scalable windows that I could drag around the screen and I felt I was getting somewhere. I started building some other controls and then hit a hard wall with buttons. I sat back and realized that I needed some sort callback functionality for my buttons. Of course I wanted something that lived up to expectation #2. It needed to be easy to use when I started implementing GUIs into the game. Well around the same time I was working on a console system for the engine and decided to merge the two projects. I decided to use the console parser as a callback system for my buttons. This way I could use plain text commands for my button callbacks. This worked for regular functions as well as member functions. So this way I could just put together the console commands (which were done through macros) and then call those console functions from the button callbacks. So onclick could run "TileMgr.addTile;" which would find the object called TileMgr and then get a function callback for that object called addTile which was a console function that had already been registered. All was finally looking well. I implemented the whole thing and was good to go. Now onward to all the other controls which went relatively painless.

Early image of GUI System

My main reason for creating the GUI system was so that I could setup an in-game level editor. Carnage (yes the title of this post and the name of our new game) was conceptualized as a top down scrolling shooter. We wanted to get out of these games set in space so this would be an actual character fighting enemies with some decent AI. The game was to remain 2D so I wanted to implement a tiled level area. The screenshot above shows the original tile setup. Using the new GUI system I was able to setup a nice little tile editor for painting tiles with different textures. All looked and felt great. I was happy, but I realized I wanted and could do....more!

The next step was to implement a 3D tiling system. The game itself would still play like a 2D game but the environment could have 3D tiles...so walls would come up towards the camera and give a nice depth effect verses everything just 2D. So the characters and props would remain 2D, but the environment would be 3D. The idea, of course, came from one of the greatest games of all time... GTA2. So I then implemented 3D tiles and a selection method for selecting and adding additional tiles to the game level. I added in a full 3D camera to rotate around the scene for painting the sides of tiles. This was really starting to look cool...


3D Tiles

So as I sat there spinning around my creations I realized that there was one more thing I needed. I needed lighting! Again I wanted something simple and fast, but something that was going to look nice. So I opted for vertex color lighting. I didn't want to use OGLs lighting scheme so I built my own that just painted light values as vertex colors. After a few failed attempts I had something working...


Lights

And then I added in the color element and a light editor....

Colored Lighting

So now I was all set, but I needed to add some more control over the tiles. All I could do was add cubes and paint them in the grid. This was all well and good, but I needed a way of scaling them so that I could create more interesting areas. The next step was creating a tile editor GUI window. Something a bit more detailed the tile painter window. I gave control for scaling on the 3 different axis and then aligning the tile to different sides of it's tile block.


Tile Scaling
Putting it all together

Now during all of this I realized I needed a better way of handling textures than I had in the past. So I went ahead and wrote a resource manager that could package multiple images into one file. I also wrote a package editor for quickly adding textures to a resource file. The engine now used only resource files.

Resource files are also used for animations so that the frames of an animation can be stored in a single resource file. When an texture animation object is created you can tell it to load a resource file for it's animation. The animation object creates a linked list that references that texture information for the animation and plays them back in sequence. Simple and sweet or sweet and simple...either one works. So that is basically where we are at the moment on our next production. There is no current scheduled time for release, but after Alien Defense we wanted something more intense and start showing what we are working on early to get feedback during development.

Alright well that will do it for me folks...until next time.

-Tim Pelham
Creative Director/CEO
Nitrous Butterfly