Finally Have DirectX 9 Working

So, after struggling with Visual Studio 2008 on a bug that is generated when doing a batch build of the engine and its subsidiary libraries, I have finally gotten a basic library built for encapsulating DirectX 9.0 in the engine. I am looking into fixing the build error (I may need to disable incremental builds and instead make it an all or nothing thing... That could be the source of the error, as it seems to malfunction with the libraries whenever it is recompiled after a previous failure).

I am now working on a proof of concept application, a simple game, that uses the current state of the library. It will do basic content loading and management. The entities in game will utilize state and action objects during play. The basic game will be a 2D vertical rail shooter. The following actors will be made:

"PlayerShip" - Using the generic actor, this will have the following states and actions.

• PlayerControllerState - This state acts as the controller for the player. This will be in charge of determining the actions the player's ship performs, based on input information, provided as an action from the system.
• HealthState - This state is the amount of health the player's ship has.
• WeaponState - This state is the currently equipped weapon of the player.
• FireAction - This is the action which the PlayerShip performs on its parent. This action calls the ship to fire, telling the game world to generate the current weapon effect on screen.
• CollisionAction - This is the action the PlayerShip performs on anything it collides with. It damages the target by a certain amount.

This is the basic idea. Enemy ships will have similar controllers, controlled through simple AI and the like. Likewise, they will have their own actions and effects.

I will update once the prototype game is out.

Engine Updates, DirectX 9, and Mods

So, after doing a lot of research for several days, I have had to redesign several key aspects of the bindings I use for the ILEngine for DirectX 9. Much of this comes from memory and content management, done through DirectX 9, due to the inherit connection between content information (textures, etc) and device context, which is horribly efficient for speed and drawing, but a pain for keeping references tidy when allowing switches between fullscreen, windowed, and resizing. Hence, some work on the engine has come to a crawl until I find a creative way around this. So, until then, I may just stick to creating the application framework for DirectX 9, allow for full modification of the window, and then worry about the rest later.

So, as for the mod, I have been swaying back and forther whether to continue using Neverwinter Nights 2 and its toolset, or to use Neverwinter Nights and its toolset. This is mainly because, for Neverwinter Nights 2, there is not a lot of community content and tools available while for Neverwinter Nights, there is a huge amount of custom content and tools available for creating your own mods. Still trying to weigh this decision more thoroughly on the scripting applications as well.

IL Framework Generics

So, right now I've been working on the ILGenerics namespace for the framework /What this namespace aims to do is to create a generic implementation of several entities, graphics, resources, states, and actions that are used by various possible entities and actors within a game. These generics can then either be used directly or used as the base classes for other values.

These generics are meant to be the first show of power that the framework has, in that the generics will be some of the most basic types of states, actions, and the like that a system could possibly need. What the namespace will add in general will also be very powerful, giving access to a variety of resources that can aid with making development flow much faster and more fluidly.

I will eventually post the most recent diagrams and documents, which will further explain my reasoning. I need to move the documents to a new host (eventually, probably to a web server I'll rent), which will allow for better configuration management and also allow for all of my work to be hosted from a central repository, rather than on my desktop and backed up on a separate hard drive.

Until later. After these generics are finished, I will finish up the DirectX 9 wrapper classes that allow for the easy creation and extension of DirectX applications, and then will begin on creating my first game with the engine, a proof of concept of how powerful and flexible it can be.

That's it for now.

Oh, also of good note is that I got my personal website up. It can currently be found either at http://www.se.rit.edu/~brb6127 or http://people.rit.edu/brb6127. Feel free to look and investigate my previous work.

IL Framework Progress

Well, yesterday I finished working on the basic IL framework for C++, getting it to compile into both DLLs and Libs for both Debug and Release mode. My next challenge with it is to wrap several of DirectX's files and formats into the framework. This includes but is not limited to:

* Textures (DirectX supported textures)

* Models (.X files for now... may expand later)

* Shaders (HLSL/CG files using ID3DXEffect files and the like)

By then wrapping the actual D3D device inside of the application part of the framework, it should be possible to setup and initialize a D3D application that will run and continue working until the system calls it to quit. From there, I will think about abstracting out the ID3DXSprite interface for drawing sprites to a scene. This will then be applied to a first short game, modeled after one of my Computer Graphics I projects, which will be fully 3D, use DirectX and HLSL for rendering, and finally utilize the interactions system of the framework for game play mechanics.

Working Architecture

So, finally now that classes have died down and I'm on the last stretch of my BS degree in Software Engineering, I am going to cover future plans and the system I have been devoting some of my spare time to, the Inferno Game Engine.

I will be finishing my BS this fall, in November 2009. Following, I have decided to enter into the MS in Game Design and Development, with a focus on Game Engine Architecture and Design and Creative Narrative / World Creation. Instead of going straight into industry, I decided that I really needed more projects under my belt, which RIT's GDD master's program offers. However, I'm still skeptical to a degree about the prowess of such a program, as often academic programs for games do not produce the best game designers, programmers, architects, and the like. For that, I will rely on my SE background.

Now, to get to the meat of this post, I have been working for the past 3 years on a game engine primer, as I like to call it. What the primer does is specify the core classes and interfaces for making a game system which revolves around having in game entities communicate with one another, how they store and track their arbitrary state information, and how they act on one another. While I could have slapped something like this together easily without much forethought, I've decided that I really need to design it out and weigh all design decisions properly before just allowing the system to be programmed. For that, I've gotten quite a bit.

Below is the basic flow of the primer (If the diagrams don't appear right, try clicking on them to get a better view of the diagrams):



The above image gives an overview of the idea of the primer, and how it can be used to create bindings which are then used for making game or simulations, ideally.



The above image here represents the basic class structure of the primer. The movement from left to right moves upwards in the chain of complexity of the different class elements, as it is in short, a large class hierarchy of increasing complexity, to allow for the most dynamic and flexible interactions and storage of entities possible.



The above image here was playing around with how the concept of updating would work for the system. It appears like a standard update loop. The design here is not final.

My reasons for posting these diagrams is because, eventually, I am planning on making the primer and the related bindings open source. Currently planned are Irrlicht Engine bindings and XNA bindings, though more can be added later. The reason for this, as specified, is to create the means by which entities can interact and control themselves. I feel, personally, that there are not enough powerful open source tools for the game community and that powerful, great tools should not be limited to the powerful or those with millions of dollars of funding. While this may not control the quality of games directly by limiting only to those groups, what it does do is provide better tools that will support burgeoning game developers.

And with that, I will leave it for now. I have more work to do, but these should help others to get a better idea of what the engine does, and what I am engaging myself with. Until the next time.