E.X.P.L.O.R. in development now! Cool Developer Stuff

Pages: 1 2 ...3 ...4 6 8

A Rant - May 11, 2011

Alright, today I went ahead and posted the entire contents of my private developer log, so most of the posts in this blog will make little to no sense. That is to say, most of the blog posts before today were written for my own use as opposed to making it very clear how exactly the game engine was developed. The log entries will provide some kind of insight as to what I was thinking, but most of the posts make references to parts of the game engine that have never been explained elsewhere on this website.

The truth is, that I don’t even know where to begin on explaining the development of this project. The game engine is so complex that I don’t even really know how to explain it. Quite frankly, it boggles my mind that it even works.

In 2006 I started a game engine called the Legacy Game Engine. This was supposed to be a 3D game engine intended for development of a point and click adventure game similar in design to Gabriel Knight 3. I always intended to develop a robust game engine that would be easily mod-able in the way that the ID Software game engines are mod-able. In doing so I ended up creating a game engine that was so badly designed that I didn’t even know what to do with it, but I did get a few ideas from my failures in developing the Legacy Game Engine.

When I started developing a game engine, I knew very little about game engine design. I had a few reference books on Direct3D, all with titles like Direct3D Game Programming. None of them, however, really covered anything about game development. They were all about how to draw a triangle on the screen. That was all well and good, except I wanted to make a game, not just draw some graphics. Interestingly enough, the best help I had in actually developing a game engine was a book by Ian Parberry called Introduction to Computer Game Programming With DirectX 8.0. This book was a tutorial on creating a game engine in 2D using DirectDraw, but more important than that, it was a guide to the architecture of a game engine, and most of it’s techniques were applicable to 3D. There are so many books on advanced graphic techniques, but before advanced graphic techniques even matter, I needed to develop a game engine that actually had objects in it. This book helped me with that process. I actually first read Parberry’s book back in 2001, and I developed a 2D side-scroller game engine called ScrollGIN.

In 2009 I realized how bad the Legacy Engine was in terms of unreadable code, and inefficiency, and I scrapped the entire project, and nearly started from scratch. I had learned a lot of important skills, and realized a lot of places where I went wrong, but almost four years of work was thrown down the drain. Granted, when I say four years of work, I mean four years of spare time work. I’d been working and going to school the whole time, so I was putting in maybe an average of one or two hours a week (that is about 0 hours per week when I was in school, and more during summer vacation), so it wasn’t exactly four years worth of eight hour days of work. Still, I had thrown out all that work and started fresh.

The Emergence Engine has been a difficult project to work on. It is so massive in scope, that my biggest regret is that I did the whole thing by myself. I now understand why teams work on games. They are too big a project for one person to take on. There is way too much involved. Even if I could have had just two developers, one for the client side of the game engine, and one for the server side, it would have been a lot easier to develop this project. Not to mention the fact that all the art and other assets in the game engine were also developed by me. Let me give an example of how much work that is. I recently developed doors for the game engine. To even begin developing a door I had to create a mesh for the door. Then I had to skin the mesh. 3D modelling is one job by itself. Skinning could possibly be a second job. Then I had to create the entity definition file for the door. This is a programming job, but it is a simple programming job that could easily be done by someone more comfortable with the word scripting than programming. (An entity definition file is an XML file, so event the scripting isn’t that complex.) That, again, is another job right there. After that I had to write the AI for the door, but before I could do that I needed to modify the AI implementation in the game engine to meet the requirements necessary for one AI to activate another AI. That is another job. Meanwhile, the game engine still needs a lot of work with the implementation of audio, another job. And I want to implement some advanced graphic techniques such as a particle effect system, and dynamic shadows. Again, those are more jobs.

The point I’m trying to make, is that developing a 3D engine by one’s self is torture. A modern game is a group project. I wish I would have had computer scientist friends that were serious about game development, then maybe I could have worked with them, but I didn’t have any friends with the kind of talent that I needed. I mean most of the people I know don’t really understand the concept polymorphism, let alone what a pure virtual function is. Techniques which are used extensively in the Emergence Engine.

I mentioned in some of my posts that the Emergence Engine is trying to be too robust. I was really trying to develop something to put on a resume, but I was obsessed with adding all the features of a mod-able game engine. If I had just come up with a simple game design, and made it, it may have been a lot easier, but instead I wanted to develop a generic game engine that could be used for any type of game that I wanted. I mentioned that my original plans were to create a Gabriel Knight 3 type adventure game. The engine in it’s present state could be used for that, but it could also become a 3D side-scroller, or a Deus Ex clone. It wouldn’t be good for an RTS game, or an open world game like Grand Theft Auto, but other than that it could be almost anything.

Well I’ve done enough ranting. I really just wanted to explain why most of the posts in this blog are so confusing to read. This game engine is still in development. It works, but it still needs a lot of work.

Categories: Development

Log - May 11, 2011

Major changes were made to how AI works. It used to be that there was a list of
simple entities which didn’t process AI at all, and a list of AI controlled entities. Now there are
three different lists, inactive AIs (which replaces simple AIs), active AIs, and
semi-active AIs. Each entity’s AI script controls which list it will appear in
and the list can change at any time the AI decides it wants to. This makes
managing AI more efficient, because now an AI can be active when it needs to be
then go inactive when it is no longer doing anything. For example, a door is
usually inactive, but if it get’s activated the AI goes live, moves the door
open, when the door is fully open the AI goes inactive until it is activated again. That way
an AI isn’t constantly being updated if it isn’t doing anything. Semi-active
AIs are similar to active ones, but they are updated less frequently. Many
NPC objects can be controlled in this semi-active way because they really only need to set
a velocity or animation, and update it only occasionally not necessarily every frame.

The main thing though, is that an AI can go inactive, so processing power isn’t
wasted on an entity if it isn’t needed. Most of this work was done solely for the
purpose of putting doors in the game engine, and happily it seems to be working
quite well. Doors involve one entity interacting with another. To do this, one entity can send a notification to another entity. It was necessary to implement this functionality. Currently this functionality needs a little more work, as when one entity notifies another one
the entity notified may not know exactly where the entity that notified it was
it might be a good idea to implement a mechanism to do so, that way, for example
the door would swing in the right direction when notified. Or if the player
wanted to initiate a dialog with an NPC the NPC would know which direction to
face or look. I’m thinking the best way to do this, would be to created an
additional AI controller method which lets an AI get a handle for another
entity’s controller interface, that way it could either issue commands to the
entity, or it could get information about that entities position and so forth.

Doing things this way could offer a lot of potential. For example, you could
define a power up, but rather than the entity obtaining the power up deciding
what to do with the power up, the power-up itself could direct the entity that
obtained it as to what to do. Yes, indeed, this seems like a good way to go.

On an interesting note it is two years to the day that the Emergence Engine

Categories: Development

Another Log Entry - May 9, 2011

I finally did something with doors, that is there is now a door in the game that
opens and closes. It is currently not controlled by the player, but runs on a
timer, but it is a step in the correct direction. Also, it confirmed my
suspicions that the AI needs to be updated every frame for a smooth animation
as opposed to the every 5 frames that it was updating for usual AI updates. This means I
will need some kind of mechanism for transferring AI updates around.

Also, I changed the mtree file type, it no longer exists, but was merged with
the edef file type. This was to make defining new entities easier, since
realistically every mtree would belong to only one edef anyway. I also want to
create a tool that will generate an edef based upon a mesh, and I want to get
default mesh textures working so that skins and materials don’t necessarily need
to be defined. That way at a minimum all that would be needed for a simple
object would be a mesh, texture, and definition file.

Categories: Development

Progress Update: Decorative Entities - April 2, 2011

To give a little background on what this post is about, let me explain what entities are. An entity in a game is basically anything that is not part of the map. Entities include player and AI controlled characters, objects sitting on the ground, torches hanging on a wall, pretty much anything you see that wouldn’t be classified as a wall, the floor, or the ceiling. Some games refer to these as actors, in the Emergence Engine they are referred to as entities.

In the Emergence Engine, entities are declared using an entity definition file (with the extension .edef). These are XML files that describe how an entity is to work within the game. Click this link for an example. Until today, entities were all physics objects, meaning that they all reacted to gravity, collisions, and so forth. They all moved around in the world.

However, it was necessary to have decorative entities, that is, entities that don’t react to the physical world, they are merely in it, and they are visible. In PhysX these are called static actors. Typically static actors occupy space, and other actors will collide into them, but they themselves will not move. Actors can also be set up to ignore all collisions.

The Emergence Engine now employs these possibilities. In the physics tag of the XML file, the property type may now be set to three possible values: normal, static, or disabled. Here is an example: <physics type=disabled/>. With this setting the entity is merely in the world, and it does not react to any collisions, or gravity. With the type static, the entity occupies space, but does not move if bumped into. With the normal type (or if no type is specified) the entity reacts to collisions.

This was important because in a game world there are many entities that are decorative only, and they are best served when their physics is either static or disabled. One reason I wanted to get this implemented was to show off the pixel shader technology in the game engine. I had developed a water pixel shader, but previously the only way to show it off was to create an entity of water. This had an interesting effect though, in that if something bumped into the water, the water would slide around the room. Now the water entity can be defined as having no physics, and bumping into it will do nothing. (Actual water that you can swim around in is not implemented, and will not be handled by entities. The water entity is only the visuals of the water surface.)

Check out the water.

he water pixel shader.

Along with this new feature for entities, quite a bit of code was rewritten as well. I renamed a few classes with names that make more sense. For example, entity definitions were referred to as entity templates, and their associated class was CEntT, which is a class name that didn’t make much sense. I renamed that class CEntDef, which makes quite a bit more sense.

To give you an idea of how entity definitions work, the .edef file defines and entity. It is loaded by the CEntDef class. Then, each save game references an entity dictionary. An entity dictionary is a list of entity definitions. This is also an XML file. So what the game does when a new save game is loaded (or a new level) is that it loads the entity dictionary, the dictionary in turn loads all the definitions. Then when an entity is to be spawned, the game refers to the dictionary file to get the definition, which is then used to create the entity. Admittedly, it is somewhat complicated, and it is actually more complicated than what I just described, because there are other physics properties to be concerned about, which are declared in another XML file altogether, but it has to be complicated in order to allow the most functionality.

Categories: Development

Design Decision: PhysX - March 26, 2011

The physics engine employed in the Emergence Game Engine is NVIDIA's PhysX (formerly Ageia PhysX). This actually wasn't an immediate decision, and didin't come until later in the deployment process. Employing physics into a game engine doesn't come right away, before you can worry about physics you need to worry about the actual architecture of your game. If physics are to do anything you need some kind of entity with an associated 3D mesh, that way you can actually render the behavior of the physics. You also need a map format, with a rasterizer for the map. And you need to have some sort of "physical" geometry defined for each of these shapes.

I originally began developing an engine called the Legacy Game Engine, which was similar in concept to the current design, but I began developing it with little knowledge of 3D game architecture. When developing this engine I began by developing my own physics engine. The original physics were based on axis-aligned bounding boxes for entities, and convex polyhedrons for world geometry. This is a common design for game engines all the way up until about 2003. I started out developing the engine like this because it was a simple solution to get physics up and running quickly. You really don't have much of a game, until there is some kind of physics. My own physics engine had the typical features you need in a game engine: Collision detection, a model of Newtonian Mechanics, including gravity and surface to surface friction, and so forth. But it felt stiff. It felt old school. I realized that it would literally take years if I was going to develop my own physics engine.

I knew that some of the major games on the market like Half Life 2 and Oblivion were using a technology called Havok for their physics, but Havok isn't exactly cheap, and Beem Software is currently running on a very tight budget. I was quickly introduced to a free solution called Newton Game Dynamics, this was a fully implemented game physics SDK with all the features necessary for some good looking physics. I began implementing that engine the day I was introduced to it. I had spectacular results right away. The SDK was well documented, and I was able to get much more functionality out of Newton Game Dynamics in a few hours, than from days of working on my own physics engine.

This was well and fine for a few months of development, then I started running into problems. Not major problems, mind you, but the physics engine was behaving strangely at times. Granted, this is because I was still working on my older Legacy engine, which had some problems to begin with. I'd heard of PhysX, of course. As a gamer, it had been mentioned in a few articles. So I started to look into it. When I found out that Unreal technology was using PhysX I was interested right away. PhysX was still under Ageia at the time, so I signed up for their developer website, downloaded the SDK, and began implementing it into the Legacy engine.

At the time, I actually designed the physics portion of my game engine to be modular, so that I could use any of the three physics engines (my own, Newton Game Dynamics, and PhysX) just by changing a variable.

Soo after, the Legacy engine was to be scrapped. I had taken a course in software engineering, which led me to believe that a lot of the code design in the Legacy engine was confusing to read, and overall had a bad design. There were also a lot of features in the game, where the current design was too difficult to enhance in the ways I needed. I began the Emergence Engine. The new engine didn't completely discount the old one, some of the old code was still good, it was just the big picture that was a mess, so it didn't take long to get Emergence into a working game engine. In my experience with the original engine, though, I found PhysX to be the most robust solution for physics, and it was my intent to build the engine to take full advantage of PhysX. So unlike the original Legacy Engine, no other physics solutions are available, it is strictly PhysX.

Entities are defined using an XML file, and the specifications for the entity are stored in that file. The PhysX portion of the game engine is still in development, and there are quite a few more features to implement, but it has proven to be a good foundation for the game engine.

Ultimately I decided on PhysX for a few reasons. First, that it is free, and second, it is used in some high profile games, so that's a good sign that it doesn't have any major problems, and lastly, it has a well documented SDK with example applications, so it is very easy to implement in a short amount of time.

Categories: Development

1 2 ...3 ...4 6 8


This blog chronicles the development of the Emergence Game engine. The Emergence Game Engine will be a fully functional 3D game engine with support for the latest technologies in video game development. This blog features the remarks of the lead programmer, Blaine Myers, as he comments on the struggles and joys of developing a 3D game engine.


Recent Posts

  XML Feeds

CMS + user community

Rough Concept Skin by Beem SoftwareMultiple blogs solution