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

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

Saving and Loading - June 7, 2011

Today I made progress on the ability of the game to save and load data. Previously it could only load data, but now it can save. This has actually created some interesting caveats, as it is questionable as to what data should be saved. Currently the game is only saving basic data about the level and about the entities, though it has the potential to save a lot more data. I also eliminated the .pinfo XML files from the engine. These were files that described additional PhysX data for the game. I combined the important parts of that file into the entity dictionary file format (.edict) because it seemed more fitting for those descriptors to be in those files since they only affected entities.

The groundwork has been laid for saving, but I’m going to have to decide further what I wanted to do with the saving ability. For example, how much PhysX data should be saved. Clearly it would be nice to save velocities and torque since it would be very weird to save a game with an object flying through the air, then load it with the object standing still in the air. I’m also running into problems with the way the player entity is saved, because the player controlled entity is treated differently throughout the game than the other entities. What I’m thinking is to create a special save tag for saving the player entity. Then when a client connects it uses that data to load the player entity. Doing so would also solve some other hard-coded items that are currently in place.

Categories: Development

Lights and Clients and Servers - June 6, 2011

The first thing I did today was actually fix a lighting problem that had been introduced when I changed the way world and view matrixes worked. I found that it was necessary to multiply a light’s direction by the view matrices rotation matrix explicitly. The Emergence Game Engine uses only direction lights even though other light types are available in Direct3D. The engine itself handles computing lighting dynamically and finishes up by feeding a direction light to the device.

The other thing I worked on today was the client-server relationship. When I originally developed the engine my main focus was insuring that entities and other real-time updates occurred correctly. So my main focus had been insuring that the client and server communicated appropriately with those, but now that I am moving into developing an actual game demo it was necessary to improve other facets of communication between the client and server.

One thing that the game had been doing previously, was that it loaded one demo level, and that was it. It was the only level loaded in the game, and loading a different level involved quitting the game, changing a text file, then restarting the game.

I have now introduced the console command server.load(filename) which instructs the server to load a new level. This took a lot more work than simply issuing the order, as it was necessary for the server to notify the client that a new level had been loaded, and in turn the client had to notify the server that it went ahead and loaded the new level. Also, it turned out I had a problem when I was unloading a level on the server side, the server was not properly destroying active entities. It was only adding them to the removal que, but that que was never being processed. It is now.

This whole process of loading a new level required quit a bit of communication between the client and server, although it didn’t require many changes to the in-place structures. I’m pleased that it is working. I need to run some testing to make sure it is working properly, and try to account for any unexpected inputs and so forth, but it seems to be in pretty good shape.

I’m hoping to have a more interesting tech demo up shortly, something much more exciting than the last one.

Categories: Development

Shader Improvements - June 4, 2011

I recently read that in most cases the view transform (D3DTS_VIEW) should not actually be used, as it is faster computationally to combine the view and world transforms into a single matrix, so I implemented that. In doing so, however, it was necessary to work with shaders, and I made some major improvements there.

I’ve mentioned that certain matrixes and other data are shared across all shaders. This is accomplished by using an ID3DXEffectPool interface which is shared by all shaders. But in order to initially define the matrixes it was necessary to load at least one shader with the matrices declared. Previously I had done this by including a file off the disk, but this presented the inherit problem that that file might not be copied over for a given mod, and it required an explicit path.

Now I have changed my implementation of ID3DXInclude to include resource files. Specifically one resource called base.fx. Now any shader may use the preprocessor command #include <base.fx> (using caret brackets as opposed to quotes), and the contents of that internal file will be included in their effect file. The effect will then have access to all of the internally defined structures such as the various transform matrices, and the g_fTime variable that I talked about in the last post. Standard includes using quotes still worked as they did before and will include any other fx file that is within the file system.

On the server side of things I removed an issue where objects that had their physics disabled were still being hit by raycasts.

Categories: Development

It's Looking Like A Game - June 3, 2011

I’m please to say that the Emergence engine is starting to look like a game. Not that it did before, but now there is more to do besides walking around and looking at the sights. I developed an AI for guns, an explosion for where the gun shoots, and I modified several of the AI so that they now react to the gun.

Most of this work required only modding the game, but I did change some of the source code. For example, the explosion that I made for the gunshot is a sprite explosion, but I decided that the best way to animate it would be to put all the frames in one texture, and then use a vertex shader to choose appropriate texture coordinates to make the static texture look like an animation.

Previously HLSL scripts had access to a global variable g_fTime which would always store the current time of the game. This was useful for animating pixel shaders, but the problem I had was that every single pixel shader used the exact same time so they would all animate together. I modified the source code so that the g_fTime value is now the number of seconds since the object being rendered was created. So in the case of my explosion, the explosion will start it’s animation at the first frame, and advance through the frames for the longevity of the explosion. It looks quite cool, and I’m happy to say that it turned out much as I expected it to.

Categories: Development

AI Controller Progress - June 2, 2011

I pretty much exclusively worked on AI Controllers today. AI Controllers are how the plugin-able DLL communicates with the game server, they are what allow the game to be mod-able.

I added three new features to the AI controller. An AI can now cause it’s associated entity to be removed from the game, it can cause another entity to be spawned into the game, and it can change it’s physical properties.

These new features were necessary to begin developing a first person shooter demo. So for example say you want a shooter. That shooter could previously do a raycast, but now it could, for instance create a bullet hole at the location where it hit, then that bullet hole could delete itself after a certain amount of time. Or if an enemy character was hit by the weapon it could change it’s physical properties so that it no longer collided with anything, and essentially becomes a static dead entity.

Most of the actual engine work was simple, but I did have to modify the AIs and create some new AIs to experiment with and test the new features. So I created a shootable AI, that simple adds an impulse whenever it get’s shot so it will bounced around when it get’s shot as seen in many games. I also modified my Hell Trooper AI, so that when it get’s shot it plays a death animation then turns static so that it is no longer affected by the ingame physics.

Finally I can say that the engine is looking like a real game that you can do something besides walk around in.

Categories: Development

1 2 4 ...6 ...7 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