.plan

Whew - Finally, progress on game for articles

Jason Olson — Mon, 31 Jan 2005 20:29:00 GMT

[Update: With some help from some friends, I have decided that the source will be released under the CPL, instead of the GPL. Thanks to all of you! ]

Wow. I can't believe it took me this long to find the time to make some serious progress on the game articles that everyone is waiting for. So, I figure I'll use this post as a brain dump of what is done and what is not done.

The overall plan for the entire series of “2d Sidescroller Engine” articles over at Managed World (which are the replacement/continuation of what are currently here on my blog) is that every time a milestone is reached in the engine's architecture, there will be an extra article or two implementing a simple game with the current build of the engine at that time. For instance, the first game will be a simple game of “Guess My Number” which is actually good example to get a handle of the State Manager, messaging, and command systems.

As for progress, the core of the engine is basically done. I have the rendering system almost complete. The only step left with the rendering system is my own font engine. Once the font engine is finished, I'm ready to close the lid on the rendering system for now. The command and messaging systems are complete. The keyboard input system is finished and hooked into the messaging system of the engine. The mouse input system as well as the sound system will be for later articles.

The other change I'm making is since I'm hosting this over at GameDev, I will be posting zip files of the code after each article where it is applicable. All the source on Managed World will be released under the GPL. So, feel free to do whatever you want with it (within the GPL of course) when it is posted. I'm hoping that I will be able to wrap up the font engine by the end of the week or weekend so I can crank out a bunch of articles after that. Why not just use DrawText() you might ask. Well, there's two reasons. The first reason is speed. I want to be able to output a lot of text if need be (mostly for debugging purposes (like AI debugging (think of outputting the state that an AI's State Manager is in for instance))). The second reason is that I want the text to be put into the depth buffer and have it be able to be in front as well as behind game objects. Or, for partially transparent textures to pass over text, for instance. I believe these goals will be easier to achieve with my own font engine using color-keyed textures (the font files) and textured quads. The rendering should be able to handle this without a single hiccup.

So, the font engine is the last hurdle in the way before I write the next bunch of articles. Once that point comes, we will be further along in the game. I'm realizing that this series of articles is going to be *LONG*, mostly because there are so many aspects to discuss when it comes to architecting software for a game. I also want to take the opportunity to discuss issues dealing with best practices for coding and development (stuff you might pick up if you've read Code Complete, or similar books).

Remember, the articles aren't only about how to write a game. The articles are mostly about software architecture and things you can do to make yourself a better developer. There are not a lot of resources in game development that discuss software architecture and how it applies to game development. I'm hoping that's an area that these articles can help in. These articles are meant to be thought out architecturally. There are quite a few resources out there for game development in general but I find that the architecture of the code most of the time is atrocious. So, the ultimate goal (as much as you might not believe it), is similar to the XGameStation. I'm not necessarily trying to teach game development. The overall goal is actually trying to teach software architecture and development best practices in the context of game development. Game development is simply a “compass“ that is used to keep your attention focused on what's actually more important. That is, making ourselves better craftsman for the sake of the craft.

Until next time, I'm outtie :).

Dynamo

Jason Olson — Thu, 04 Nov 2004 18:49:00 GMT

You know, I really suck at coming up with cool code names for projects. So, I'm going to adopt my own style. All I can say is that a thesaurus is the best friend of a person like me. Well, to make a long story short (o.k., it's not really that long anyways, like you care...), I decided to use the thesaurus this time around. Since I will be making two engines for Managed World, the first one being a simple 2d engine, the next one being a 3d engine, I decided to do a trusty thesaurus lookup for “engine”. So, I would like to present to the world the first two projects for Managed World, “Dynamo” and “Turbine”. Yay!

Dynamo is making good progress. Dynamo is the revamped “Harvest” engine. I have thrown away a lot of the abstractions that were diluting the design simply to accommodate for being able to plug different technologies into the engine (like DirectX vs. OpenGL). Well, that crap is gone now. The designs definitely already seem much more pure and better and conveying the aspect of game engine design.

Now, I just need to go back and revamp the first couple articles up at Managed World to reflect the changes I have made. Perhaps at the same time I can crank out the next article. It's been way too long. Well, a lot of work ahead. I fear I must now get back to it :).

Managed World - Update

Jason Olson — Tue, 02 Nov 2004 22:03:00 GMT

This is just a quick update on my approach to the engine for the articles on Managed World. For those of you that don't care, feel free to skip.

I did some more work on the 2d engine for Managed World. I've decided to step back and revise my plans. I was taking a pretty abstract approach to the engine, to the point where I could plug in an OpenGL renderer if I wished to. Well, in order to be able to abstract the renderer, you need to abstract almost any feature of DirectX or OpenGL that you wish to use so that the end-user (the actual game code) can use the abstractions and not care how they operate under the hood.

All in all, this isn't the real problem. Really, there is no problem. I've been doing find abstracting the details when I need to. It's definitely a fun exercise in software design. However, I stepped back and asked myself what the true audience is for the articles that I will be writing, and for Managed World in general.

Well, the audience I'm targeting is Managed DirectX developers. So, in that case, I don't think it is a problem if I expect the users to be using DirectX. I don't want to make it too complicated, unnecessarily. So, time to pull out the abstractions tonight and get a straight forward, DirectX-specific, engine running

.plan - 10/24/2004

Jason Olson — Mon, 25 Oct 2004 07:29:00 GMT

Well, I was finally able to get around and make more progress with the Harvest engine. It's still in the ridiculously early stages, but it feels good to actually make some more progress. I wired up (again (and got it working properly this time)) a C++ Makefile project in order to build the solution (the engine + the sample application) using the NAnt build project from within Visual Studio. Last time I tried it I couldn't get intellisense to work on an ongoing basis. It turns out that it was an easy fix. I'm not exactly comfortable with it, but at this time building a solution builds both with devenv.exe (aka Visual Studio (this helps Intellisense continue to function properly)) into a temp directory, and then builds it again with the C++ makefile project (e.g. the nant build script).

Outside of the build and development environment, I was able to get the Vertex Manager and Vertex Cache working. The sample is ridiculous right now. It just shows two animated triangles and an animated square, but the manager and caches are working nonetheless :D. The next step is to wire up texturing. Once texturing is wired into the Vertex Cache, the bulk of the rendering engine is complete. All that would be left after that is to implement lighting. All in all, good progress.

Sooner rather than later, it looks like I'll finally be able to get around to implementing my own sprites and maps. Yee haw!

Harvest Progress

Jason Olson — Wed, 20 Oct 2004 18:29:00 GMT

Well, I was finally able to get some time last night to do some more coding up on my engine. I got the Vertex Manager and Vertex Cache wired up. It's not quite hooked into DirectX yet, but the whole rendering pipeline of the engine (from Renderer -> Vertex Manager -> Vertex Cache) is finally working properly.

I'm hoping that I can continue to make progress on it tonight. I'm a lot further behind on this engine than I wanted to be at this point. To tell you the truth, it's not nearly as far as I've seen a lot of other people make more progress on their projects in the same amount of time. Arg, sometimes it's quite intimidating being surrounded by Type-A people when you are not a Type-A person yourself. Oh well, that's the way of the world I suppose (and yes, I have been listening to a lot of Earth, Wind, & Fire lately).

If all goes well, I should be able to hook the Vertex Cache into DirectX this evening and at least have an actual rendering pipeline in the engine by this evening. Then I can start making true progress on the meat of the project. All I have to say is this: I LOVE software architecture! There's just something exciting about designing a solution with known and tested software architecture memes that makes me giddy like a schoolgirl.

Until then, my friends....

.plan - 9/18/2004

Jason Olson — Sun, 19 Sep 2004 07:52:00 GMT

Man, it's been a while since I've been able to put some time into the Harvest Engine. Lots o' deadlines with my music publisher, don't cha know. Anyways, I was finally able to spend at least a little time tonight trying to make some progress with the engine (albeit it very *small* progress).

I whipped up a quick reasonably high-resolution timer for the engine that uses QueryPerformanceCounter in the Windows API. Along with that, I added in pausing/resuming functionality into the engine. That is just a simple matter of pausing/resuming the counter though.

I added the ability to my renderer to output debugging text to the screen. This will allow me to output text with different colors to the screen to help view game object state information. For instance, for any game object I can whip out the state the AI is in, as well as many other uses. Currently, the engine is using the OnPaint() and Invalidate() method for the pseudo-game loop. Next coding session I will probably change that to use the good ol' Message Proc API that is used in the sample framework.

I also fleshed out more details about the architecture of the engine.

One of the next steps is to build a Math library independant of DirectX so that it can be used with the OpenGL renderer also. Once I make the math library, I can work on some classes for Sprites, Textures, and the accompanying Managers. Once that is all done, I can finally start delving into the good stuff, like actually putting together the tiling engine (since the Harvest Engine is a simple 2D engine).

I'm still working out the details in my head of when I want to start on the audio module and other modules. I don't want to leave them out until the last minute. But I also want at least a workable framework up and running first. Anyways, until next time (hopefully it won't be as long as this)....

.plan - 9/5/2004

Jason Olson — Mon, 06 Sep 2004 06:53:00 GMT

Well, I didn't get nearly as much done as I was hoping for today. A lot of the time was spent wrestling with NAnt and getting my build scripts to properly reference the Managed DirectX assemblies. I still don't really like the solution I came up so maybe I can find some time soon to see if I can wrangle up a better solution. However, with all that said, I have my projects all setup for the Harvest Engine (it's just a code name (I wouldn't go with a name that cheesy, I swear (well, I probably would (but that's not really the point is it?)))). I have the NAnt build scripts running and compiling the application properly.

I also got the Direct3D device up and running in windowed mode. I know, not that big of a step, but I'm trying to do some cool stuff to really make this engine cross-API possible. That involves a lot of coding up my own enumerations among other things so that display modes and card capabilities can be read in structures specific to my game engine so that the Direct3D renderer and the OpenGL renderer can read the same values. No sense for striving for cross-API capabilities if you aren't going to go the whole way, eh?

The next step is to get the enumerations and renderer config file working so that I can implement the fullscreen as well as the windowed mode and allow the user to switch between the two. Before I go there and while I am still working on the bare-bones windowed mode, I am going to implement some swap chains so that you can render into as many as eight windows controls. We will see how that goes. I think the money number of swap chains is four to be able to implement the level editor. That way, I can do some level editor development while I am developing the engine side-by-side.

Perhaps before I go on with other .plans, I should outline exactly what I am shooting for for this engine. I am *not* shooting for cross-platform development. However, I am shooting for cross-API development. I am also not shooting for native code development. This engine will be entirely managed code (probably all in C#), and is meant to be used only in a managed environment. You *could* use it from native code I suppose by implementing a COM wrapper, but that seems pretty pointless to me. To recap: the engine will be a Windows-specific, cross-API, managed engine. The architecture for the engine is that the actual game will be in an EXE and the engine itself will be in a statically-linked assembly (although the renderer will be dynamically loaded in order to allow changing between the different graphics APIs). I am aware that this is not “the” approach that companies like id use. id uses an architecture where the game is in the dll and the engine is in the EXE (I believe). We are not developing this engine to easily support mods. The engine will be a simple 2d (via Direct3D) tile-based engine.

After much wrestling with myself, I am going to be using few of the “helper” classes in Direct3DX. This is not because they aren't useful. They are, and they are implemented better and faster than I could probably do at this point in time. However, the key to this engine is to *teach*. I want all of you to understand exactly *how* the helper functions work by implementing them yourself. Yes, this is re-inventing the wheel. I am usually strong opposed to re-inventing the wheel. However, when dealing with a performance-oriented application like game development, I think it is important to understand exactly what is happening under the hood rather than taking it for granted. This is also the main reason that I won't use the sample framework that the DirectX Template from the 2004 Summer Update installs.

At this point, you might notice that comments are not enabled on these .plan updates. That is on purpose. I am really gearing these updates as a one-way communication. If you do have questions/suggestions about things I bring up, please feel free to contact me through the contact form on my homepage here or email at jolson88 AT yahoo NOSPAM DOT com.

I think that's all for this brain dump (at least I hope so since I can't remember anything else at this point).

Until next time.....

.plan - 9/4/2004

Jason Olson — Sun, 05 Sep 2004 08:08:00 GMT

Well, I've been reading 3d Game Engine Programming lately and I love what I've read so far. I have decided that I am going to be adopting a similar engine architecture for my game. The architecture is largely based around late-binding modules (aka assemblies) into the game to accomodate a plugin architecture. This allows any in the future to plug in modules based on different APIs that I will use. For the game, I will be using Managed DirectX. However, if someone wanted to implemented a Managed OpenGL renderer for the engine, it is entirely possible and not that difficult (if you know OpenGL that is).

I've now got a prototype architecture up and running as of this evening. The architecture (in its infant state) is based around one statically linked assembly (for now it is a simple project reference in the solution), and one dynamically linked assembly that contains the actual renderer and is loaded at runtime via reflection. The abstract base class for the renderer is implemented in the statically linked assembly so that the game can use the renderer via this base class. This is possible because the actual renderer in the late-bound assembly derives from this base class. Pretty slick. I'm fairly proud of myself. To this point, it is almost a direction translation of the renderer implemented in the book mentioned above. However, the book above is in native C++, so I have had to translate the intent of the architecture into the .NET way of doing things (was quite fun since I've never written or programmed against a runtime “plug-in” architecture before).

I have also implemented all the functionality for logging in the application. The initial plan is to have all modules log to their own log file. Logging will be able to be turned on and off at the flick of a switch. Currently, I have it implemented where logging always occurs if in debug mode. I currently have logging calls placed throughout some of the loading routines. The actual determination of whether to log or not is in the Logger class itself, so the modules aren't having to check whether they should log or not for every call. This may need to be optimized out in the future. But until it is proven that the overhead of the potentially useless method calls is too high, I am sticking to my guns and doing it this way.

Now that I have the bugs worked out in general plugin architecture, the plan is to move the code from my research directory into the final game engine directory and to start game engine development. Before I do that though, I plan on writing up an NAnt build script so that the build order and the moving around of assemblies is handled properly. Because of its flexability, I prefer this way as opposed to pre and post build steps in Visual Studio.

Until next time....