Would you believe it...

So for those of you who have been keeping tabs on me, you may have noticed that I have not been absent from my blog for a few weeks. For those select few, I apologize. My Structure of Game Design class decided to drag me out to a field and literally beat my to a bloody pulp with a hammer. The class was the first time we actually had to put together a full blown game. A large amount of the technology was provided for us but I took the challenge and wrote my own systems (however I did not make my own DX interface code). The class overall was extremely challenging and forced me to generate designs at a rapid pace and implement them just as fast. While I've been building a small code base for a while, I had to implement tons of new features in order to get the game logic working. I consider this project a good experiment in what I will need to make a more stable game "engine." I am proud that the collision code, despite spatial partitioning, worked awesome. I was able to get collision-game logic code connected in an extremely short time. I regrettably had to pull all the physics out and use a much simpler "game physics" with some light weight response code but this is proving to be much simpler to work with.

I did find a weakness in myself while working on this project. I am horrible at design. When people gave me suggestions on what I should implement, I was able to solve them and allow for potential new ideas. If anything, my code base provides backbones for lots of game ideas, I just stink at coming up with any! My game demo came out as more of a tech demo showing what could be done or at least proof that the core game play could be created with the code base. I'll need to work on this and try to merge my love of problem solving with an ability to study games "designs." Oy, my engineer side is really taking over.

I am currently taking a break from coding. After turning the project in, I took a day or two off then came back to solve 2 major bugs that were driving me nuts. Now that those are hammered down, I am going to start working on some Memory management research. I want to get to know how new and delete work and find better ways to track one pre-allocated block of memory rather then let it all go hog wild :). This is going to be my "side project" over our Full Sail Summer break which is only a week. I am going with Laura up to her Grandparents for the week. It is going to be a relaxing time and hopefully in those down moments, it will be productive. That reminds me..I need a new notebook!

Now I am wondering if a few of you want to play my "tech demo". Well feel free to download it here.
The game itself is a simply top-down shooter with zombie coming at you from all angles. There is an extra enemy type that chases you and uses the same weapons you have ( a rifle and grenade launcher).

Please drop me a line with what you think.

Awesome

Yes damn hell yes!

The bridge is working swimmingly well. I've just implemented rendering for my bounding volumes (well honestly the dx rendering commands were done by the SGD wrapper, I just provied the routine).

Basic camera control is now up. I had this working with allegro and now it is working with the DX wrapper. Oh this is a good feeling!

Bridge Jobs

While I'm not working on a bridge..well not literally..I did recieve some good news today: I am becoming a peer tutor for Software Architecture! My teacher Nick Penney sent me an email earlier today and asked me to join up. While the pay is decent but the hours are very flimsy, being tutor is worth its weight in gold by helping reinforce concepts and being on my resume. So I'll post more on that as it develops.

As for the Bridge...while being a rather complicated design pattern, I think I just built my first incarnation of it for my side project. In our Structure of Game Design (SGD) class, we recieved a nice set of wrappers for DirectX for basic sprite operations. Its pretty solid and will make our project in class go much faster. On my side of things, I have been working on a Collision/Physics system which I dubbed the Simple Game Engine (SGE). A while back, I read that it was a good idea that your game code is as API independent as possible. I went back and redid the SGE to be that way and so far it has served me well going between Allegro, Win32, and DX. However, the wrappers presented a problem that I ran into when I moved the SGE between different APIs...the code developed for the API inevitably became linked in some fashion with API so the code written (that is code developed outside of the SGE) was not usable in another project.

If your still following, I found a solution to the problem. I developed a series of interfaces that are fairly generic that cover Rendering, Resources, Sound, and Input. These interfaces are very basic and are the only things that SGE objects will use. However, a new class in the SGE (CEngine) now maintains ptrs to the implementations which are specified at runtime. I created a few implementations that are derived from the interfaces. Each one is specific to using the SGD code provided.

So now I have broken my game code into three parts: The SGE dll, the Game dll, and the DX exe.

The DX exe brings the other dlls and create an instance of the game from the Game dll. The DX exe also intializes the CEngine with the specific implementations. The Game dll then uses those implementations to render/get input/ etc. So now I have three projects that can be modified independently and the game code built for this project will not be linked to the DX code.

I initially did not intend to create the middle layer of the Game dll but it evolved naturally and I now thrilled that it worked! When I started the SGE, I began to use it as an excuse to try out different programming techniques and with this recent development, I am extremely thrilled. This is going to be a good month.

The Everlasting Whiteboard

So the title of this post has two distinct parts:

After seeing Knocked Up with Laura today (which by the way was pretty good), we did some shopping and I finally picked up a decent sized whiteboard. I became obsessed with whiteboards while at Purdue and found them to essentially be my pensieve. Problems become so much easier to solve in front of a white board then endless meaningless scribbles in a notebook. This is also coming at a great time of need, since I need to push my engine efforts faster to meet up with this class's project. So thats the whiteboard part.

When I was in college, I got knee-deep into Warhammer. The game consumed an incredible amount of my time. I got so into it I would often stop doing homework to break open excel and start making army lists. My love for Warhammer was two-fold. I loved the numbers and I loved the lore. The guys and gals who put together the fiction of Warhammer do an awesome job and Army Books are incredible sources to keep around. My favorite army (after being through a few different ones) became the Dwarves. The art design and the story direction for them captivated me (and the heavy use of the world "ale"). The reason I bring up Warhammer is that as I get more components to my system created, I've been allowing myself moments to let my mind run wild with potential game designs. I've been fairly religiously keeping my thoughts to the ground where they lined up with what I knew how to do. I guess this is a side effect of getting so into the technical aspects of game creation. So I've been trying to indulge myself (as I used to do long before I wanted to be a programmer) with ideas of grandeur.

Part of the Dwarf lore in Warhammer is the huge Underground Kingdom they created that, for the most part, has been taken over by enemies or destroyed by nature. The premise is that the dwarves created several gigantic holds that were connected by a huge underground highway called the Underway. As nature caused several cave-ins, the enemies of the dwarves found new ways to infiltrate and eventually stormed and captured several holds. There are references in the Army books that other terrible creatures came out of the darkness after the quakes and are now roaming in parts of the Underway. Like many of the settings in Warhammer, the location of the Underway and the abadoned holds would make a great place for a game...and that is exactly what I would like to do.

My inital ideas were to have the game be a 2d action-rpg set in this enviroment. The player would create a dwarf explorer who would venture into the underway and explore different enviroments. I thought originally of a large adventure where the player would keep exploring one "metroid" style map but I decided (in my head) to keep the idea scaled back to a series of seperated levels. The idea behind each level is that the player is entering a different section of the Underway and will try to get some kind of key item that is located somewhere in the level while avoiding traps, monsters, and all other kinds of hazards. A key element to the game would be a grappling hook that the player could use in really anyway they chose. They could scale walls or make a quick escape. I guess a "dwarf spider-man" would be the best way to pitch it.

As for the rpg aspects, it would be nice to allow for use of a pool of skills. Off the top of my head, I am thinking a pyro set of skills where explosives are the name of the day or a melee set. These are just some example ideas.

So I think I will keep this idea in my head as I build the next couple of features for my system. I would like my demo to reflect some the navigation aspects of this idea.

Bounding Volume Hiearchies

After some initial research..I'm liking the sound of an AABB tree to sort my static objects. I do some early notes on the subject after going through my Ericsson book on collision detection. Its seems simple enough. I am not sure if there are too many nodes to test in that will cause problems down the road. I do knowI need to implement a circle bounding volume to my other bodies so that even an OBB test can be avoided if possible.

Take a break and call me in the morning

Allright the plan to step away from bsp raycasting worked. I was able to tackle the problem in a new way and succeded. This time, every time I found errors, I quickly went to my notebook and analyzed the problem with drawings and realized elements were missing. If I could not get it, I forced myself to close the computer and sit somewhere else and analyze some more. All of this paid off. While it may seem trivial to intersect a ray into a BSP, I needed certain data from the intersection test that would allow smooth movement of my axis aligned bounding volume across the BSP's surface. This data proved difficult to get at first so that is why it took a lot more analysis then first thought.

Anyhoos, it works and I throughly documented it to understand why (for the most part) it works. There are a few places I had to fudge a bit but I made some notes on those.

So now we have a new problem, the BSP will not support rotating bounding volumes. So I will need to invest in other Spatial partioning structures for static world geometry. This will be used to perform more accurate SAT tests for contact pts, etc. However, the BSP will have it use for fast world-object collision tests.

Classes finished up here and I feel pretty confident on my results. On tuesday I start "Structure of Game Design" where we will make our first real game demo. My plan is to have my collision/physics system intergrated for use in the game we make. So I will need to double my efforts to get it up to snuff. So far the system has a few things I like about it, including a simple memory manager for individual systems. I want to get the Spatial Partioning for static structures and then one for dynamic objects. Paralell to developing that, I am going to start putting together a renderer for my system for DirectX. I am planning on making it 2d/3d so there will be plenty of hot billboarding action. It will be relatively simple, but hopefully it will come together in the end.

As for the demo I keep promising, I've decided to wait on that until the basic DX renderer is working and I have my spatial partionioning structures. Those two elements will be essential for the demo to run properly and be able to flex its muscle.

Now...time to research NON bsp THINGS! YEAAAH!