Zero-G Combat Design, Decision & Progress Document

As the title would suggest, I've decided to keep a document detailing design decisions whilst I code my first 3D game (a space shooter) in the hope it'll keep me on track as well as calarify and remind me of lessons learnt. Due to not owning a copy of microsoft office for this laptop I have decided to record this in a html file using CSS for formatting and Notepad as my editor, I know, old skool. I'll start by copying out the basic concept ideas I came up with when brainstorming this game and then just list decisions and progress as they occur.

Brain Storming

General:
 > Space-Shooter with 'real' space physics. (i.e. Newton I, no top speed, momentum imparted to projectiles)
 > An arrow on HUD to show current trajectory, as it isn't necessarily the way you're facing!

Controls:
Aimed to allow your average fps player to jump in and find reasonably intuative, as in this demo app the priotiery is for quick easy, yet novel, gaming. However I think a joystick set up would be superior for a fully flegged game (immersion factor, picking up your mouse and repeatedly pedalling if you like low sensitivity is NOT fun).

 > Mouse :: aiming / rotation (this will SC (self correct), unlike linear momentum, or I think everyone would get dizy)
 > WASD :: Accelerate forwards / Strafe Left (SC) / Deccelerate forwards / Strafe Right (SC)
 > Scroll Wheel :: Strafe Up and Down (SC)
 > Q/E :: Roll Left / Right
 > Space :: Afterburner

The Acceleration using W/S will not be like most main-stream space-shooters that treat the ships like jet fighters and use this to set speed, instead it will use a replenishing fuel / energy reserve to increase/decrease speed in the current forward direction regardless of current velocity. Afterburner will provider a faster increase in forward velocity but with a finite about of burn per level.

Story:
 > You are a consciousness stored on a chip, you are 'revived' for your mission (star-fighter doesn't need a cockpick).
 > AI briefs you and gives you your missions. (Fruity Voice synth and displayed text should do).
 > Menu can be like your characters option screen in cyberspace, Enter Hibernation until combat situation, Use Simulator (for training / bonus or fun missions / multiplayer) etc
 > Many options for classic SF stories, e.g. you're in storage on your way to a new home world, your body will be cloned and your consciousness inserted when you get there, for now you defend the fleet!, or/and the AI has seized control of your civilisation, or you could try being on 'the other side' of the synthetic versus organic battle so often waged in SF or convuletedly use the first idea in conjunction with this battle where you are mistaken for synthetic but were not originally! etc etc

Of course for a demo app it hardly needs a plot worthy of a novel, a lot of fully fledged games have less than suggested here! But I think it would add a nice starting touch and the possibilty of some dark humour "You have been selected as your neutral tests demonstrate a low reaction time, above average 3D perception skills and favourable social expendibility"... possibly a mirror to the real world there.

Production

(20/11/08) Decided to use "Beginning Game Programming" code as a base and flesh out with code learnt from UGP along the way as I don't fully know the UGP code.

(21/11/08) After attempting to impliment the basic windows / DirectX Graphics code from "Beginning Game Programming" decided that the both the structure and set up was too simplistic and would make the code developed in this game next to usless for future projects. So the style from UGP of using a static library engine project will be used, however I will code this myself from stratch, whilst this is more work, it will allow me to solidify what I've learnt already, besides the UGP engine is broken (can't load models, levels or use sound). I should be able to use this code in future projects. For this reason I will try to keep the physics and math coding in the engine as general as possible.

(24/11/08) Coded Basic D3D Renderer using UGP template but removing the render interface parent class as it is superfluous to my needs. Also created the basic windows & game code (however this needs to be restructured once engine coding is complete and game coding proper begins) and got it working with the static library engine.

(25/11/08) Added Basic Lighting and Texturing Support to the Apollo engine, this was mostly direct porting of the UGP code. Note that Offscreen Rendering is not supported at the moment. Working on HUD and Menu design and simple place holder Bitmaps.

(28/11/08) Added GUI System, tried to create new sub-class - dynamic text - as texture rendering of images seems to mute colours. Unfortunately stumped by a pair of compiler errors for static text sub-class, "error C2017: illegal escape sequence", which is supposedly to do with line breaks outside the string, have been unable to identify the cause. Will investigate what options on texture rendering might be causing colour muting and fuzziness. Would like to create my own GUI class, rather than modifying an existing class, however the objective for now is to create a working game as quickly as possible. Also created a simple placeholder main menu. Noticed that the area for mouse over and area on which the texture is rendered is not identical in windowed mode (texture seems higher than mouse over would suggest) but fine in fullscreen, unable to indentify cause as yet, another reason to create a class from scratch perhaps! Hoping that this will disappear when I impliment Direct Input.


Screenshot taken with SaveScreenShot function!

Fixed the problem with the static text, the problem for some reason was with the custom colour format, simply used D3DCOLOR instead and it worked fine. It does make me wonder why the UGP programmer decided a custom colour format was necessary at all. I've removed it from my project as it seems superfluous as well as broken. May try creating a dynamic text sub-class again tomorrow, or possibly just solider on with the HUD creation so I can actually start game coding soon.

(01/12/08) Added ability to change text properties in real-time, it does however require a int variable listing the Control Array Index for the specific GUI control (obtainable by the new GetLastArrayIndex() member function). Tried to hand code a simple spaceship model, however I unable to turn it into a valid .x file, I could create a function to load the vertices inside the program, I think I'll use simple cube models as placeholders instead for now.

(04/12/08) Direct Input Class created from scratch, Source code still being written out. Not as flexible as UGP classes but still reusable and simplier, as stated earlier in this document the current objective of this project is to make a working game as quickly as possible with the obvious consession of not wanting to waste the DirectX code written and so writing it in a reusable form. Adding extra code for reacquiring of lost inputs in the case of alt tabbing as experienced previously.

(05/12/08) The Direct Input System, causes the game to crash. I have no idea why, it occurs to me that all of the UGP game projects beyond a certain point crash in this manner too. So obviously something to do with their implimentation of direct input (at the least, possibly more) is causing the game to crash. Seeing as I wrote my own direct input class it is possible that the Direct Input system "doesn't like" being put into an external library much the same was as the mp3 class I tried to port to a static library didn't like it either. At this point I'm unsure of if I should simply include the Direct Input system in the game project, rather than the engine project, or if perhaps I should scrap the static library all together and start from scratch coding by jumping in and writing whatever needs doing in the simplest manner possible. Whilst planning ahead and building a (re)usable project from the off is going to be required for large company projects, I'm not at all experienced at this and I am perhaps biting off more than I can chew trying to do intelligent project management, a 3D game engine and the game itself all in my first real project. Perhaps 'doing it the hard way' a few times (or at least once more) would be give me a better idea of how to set out a good system rather than waving around in the dark like it feels at the moment. Also I'm sure just jumping in and coding it out how it comes to me will both be more fun and give me a greater familiarity with the DirectX API / SDK. Using part static library, part filters within one solution would be rather inconsistent.

After getting the direct input system to work by shoving it straight into the code, and all attempts to fix any class / static library implimention failed, I discovered that the direct input for the mouse is frankly appalling (as it was in my very early attempts at game programming some 4 months ago), and so I am simply going to use the windows call back function to take my input as it works quite well. I researched the msdn and found various cursor functions allowing me to hide/unhide and change the cursor, so this should make the implementation of an input system in some ways simplier. I don't know what most games companies use to detect input but I get a feeling that it's not direct input (what with the current version still being marked direct input 8, although it's possible that there are new more effective implimentations but as with much of the rest of microsoft's new DirectX SDK horrifically complex and hardly something you want to teach in beginners books and so they teach the legacy system, much like 2D games still often use DirectDraw).

Update: This was typed after several hours of frustating programming. I decided not to alter my approach to the game, and decided that implimenting the sound system in the Game Solution rather than the Engine Solution was acceptable for my first game project, dispite the inconsistancy, and hope that I'll be able to move it to the static library at a later date, after I'd had the opportunity to work on some Game Code.

(06/12/08) Created New GUI Type - Health Bar, required adding support to alter the vertex information in game loop (surprisingly complex).

(07/12/08) Added X model loading and rendering to CD3DRenderer.

(11/12/08) Created my own free rotating camera system, as a simple polar coord rotation method isn't going to cut it for a space simulator. Started breaking up the D3DRenderer code with comments to make it more managable. Will need to do the same for the main windows function .cpp file and start moving game code to a new .cpp. Hoping test and refine the camera system but I need to code in world transform and more lighting functions to the engine.

Tested Camera function - the function that rotated in 2 directions at once didn't preserve the orthogonality of the local basis vectors, so I switched to a Yaw / Roll / Pitch system which rotated around one axis as the Roll function I had already made worked great. Technically this 'camera' system is doubling as a first person movement system, if I decide to later impliment a 3rd person veiw I'll have to separate the movement code and do some simple alterations to the SetCamera function, but it won't be much work and for now I'm only going to be using 1st person view.

The test also revealed that whilst the windows callback function is fine for the GUI, it is not suitable for the game controls in that it is far too 'jary' and does not like taking multiple inputs at once which is obviously an absolute requriement. Trying to take mouse input from windows was even less effective than direct input, so I shall have to implement direct input again however I may use only the keyboard if I can not fix the extremely jumpy input from using the mouse in conjunction with direct input.

(12/12/08) Mused on the possible weapons and gameplay implications / possibilities for this space shooter which is trying to make things 'realistic' in so far as they physically possible and plausable (no 'lasers' which shoot bolts of energy here). 3 types occured to me, projectile which would take your current velocity and add a significant local z component and damage would be based on Kenitic Energy (i.e. speed), these would have to move very fast to be useful given the high speed variences likely in the game. Plasma weapons, the classic bolt of energy weapon, these would have a slightly slower rate of fire and slower speed (but trying to avoid the annoyance factor of projectiles that move too slowly) and again would have the current velocity of your ship added to them but the damage would be unaffected by their speed. Thirdly real lasers, so instant to anything in the way, whilst in reality you'd not be able to see the light beam, I think it I owe it to Sci-Fi to show a glowing beam of energy. The damage would be altered if your ship were travelling at relativistic speeds in reality but I think we'll stick to the Newtonian realm for now. The lasers may need to be balanced with the other types with some kind of energy bar that regenerates. I think projectile ammo will be infinite for initial implimentation but if I decide to introduce an RP or character / ship development aspect to the game in a later version I would have to introduce limited resources, such as ammo, reactor energy, etc, an nice upgrade for projectile weapon users in this system might be the ability to convert reactor energy into bullets.

(13/12/08) Added Multisampling to the engine, at the moment it simply detects the highest setting supported by your graphics card and uses that. I'll make it set-able when I work on other options such as choosing resolution. Fortunately I kept a copy of the working implimentation of directX input 8 I made earlier and simply added the files back into the Game Project and changed the input detection function. I am still using the windows event messaging system for the mouse control in the menus, mysteriously the mouse input seems to be working fine in the game state now, maybe it needed nice camera rotation functions, or perhaps the frustation I was experiencing with trying to integrate the directinput system into the engine library prevented me from giving it enough time last time. As with the current sound system, it is in the Game Project and is using simple functions rather than classes, as I was getting strange errors when I tried to implement them in class form and I don't feel like tackling that right now, and would like to do something that feels more like progress. So I am now working on the material / lighting system as it currently is rendering the red car model I have as white, confusingly, then I shall probably do my best to create a space ship model, it's that or have space-fareing Hummers.

Turns out the LoadX Function has no problem loading textures (as long as the relative path from the .exe and the relative path from the model is the same, which is a little odd, but livable with for now), but it still doesn't like Rendering block colours from the Material function. Here's a picture of a free space ship model I downloaded being rendered in game.



Added Sounds to the main menu on button roll over and button down, and introduced some 'novel' code to allow the click sound to play when clicking the quit button rather than it being cut off as the program closed.

	button_down->Play();
	while(button_down->Playing())
	{
		// La la la
	}
	PostQuitMessage(0);

(15/12/08) For the last couple of days have been working on World Rotation & Translation functions for objects / models which are to be rendered, such as other ships. Started with a system which specificed Yaw, Pitch then Roll in global coordinates and x, y, z position also in globals. This however made it very hard to Roll / Pitch / Yaw in local coordinate systems. So instead will have a set of local coordinates to specific rotation which is copied to a single matrix and multiplied by a translation Matrix to determine the World Transform for each object. Technically only 3 variables are needed to specify a rotation, but by having a local coordinate system (9 variables) allows much easier manipulation of the rotation. Euler's Angles would probably be suitable for a fps game, and have heard that quaterions are superior for 3rd person games (allow for smooth interpolation between two different angles), however for this game which uses all 3 axises and has no prefered up direction I think keeping track of the local coordinate system is probably sensible. Noticed during testing that when reaching higher speeds the models movement became a little jerky. It may turn out that I need to keep the camera stationary in the global coordinate system and alter the movement of everything else in order to allow for this game set up that relies heavily on the idea of relative motion. It maybe that when the observer movement is based on velocities (rather than simple altering of position with input) that this effect dissapears, something to keep an eye on.

(16/12/08) Added Sprite Rendering Functions and FVFs as well as a Projectile Managment System that renders sprites flying all over the place! However it would seem that alpha blending does not work on rendered models, even though it works on other sprites as demonstrated by the screenshot below. It also seems that if a model is being rendered the ability to set colour of specific vertices in the same rendering scence fails, and when the DrawSubset of a mesh is called, the point at which the sprites spawn is myteriously slightly altered. So it would seem that my model rendering function could do with work / being created again from scratch.



(18/12/08) After playing around with the Model Rendering Function and tracking the problems as far as something to do with the method the DirectX API uses to draw .x files, I decided that considering that no one uses this format I might as well make my own. However this is a rather large amount of work, so for now I'm simply writing triangle lists in the code. I tracked down a few things wrong with my sprite renderer, the most obvious (although not the only) is they must be drawn last in the scene (doh!), and as long as I don't load X models it now works fine (and seems to work when rendering x files as long as there is something else being rendered in the same manner, quite odd!). Whilst working with D3DX Vectors and Matrices was fine in the engine code, it seems a little perverse in the game code and also I would like to add methods, such as normalising, so I created a 'CVector3' class and replaced the code that had been using D3DX objects. I also implimented a velocity for the camera and a 3D arrow that points in that direction, the rotation of which in the world transform I came on by a combination of planning and trial and 'improvement', I'm not entirely sure why it now works, but it does. I think I may have to do some code tidying at some point because at the moment camera functions and game movement functions are intertwined and it also seems a little perverse to have to go through the Renderer to get to the Camera! (Also going deep into the engine inside the game code seems to defy the point of separating them a little). The next items vital to game-play are a collision system (so ships can actually shoot each other) and a targetting system (both to inform the player where to shoot given your respective velocities and to allow you to track off screen objects without getting terribly lost).

(12/01/09) I took the Christmas week off working, and then that extended into most of the next week as well. I did however keep thinking about the project in my head and various tasks that needed doing, as well as what the purpose of this app and when it needed to be done by. The answer to the last two questions is simply to provide something for my portfolio for graduate application, the deadlines for which are Feburary / March time. So simply put I need to create something that resembles a finished app and within the next month so I can get applications sent off. With this in mind I've decided to put the original concept on hold, as a project I can work on later in my own time, and develop the current app into something simple that I can finish in the period I have. Given a lack of modelling experience, and lack of friends who know how to model I think that bad models with no animation are hardly an improvement on very bad models with no animations so I'm going to be using cubes as enemies, and give them plain textures which represent difficulty. This means I can also quickly generate simple AI system, one where the enemies are balantly computerised, rather than micking human behavoir, which is still fun for a video game, but not apt for anything pretending to be more than a video game (i.e. trying to set out it's own little universe in which the player resides when playing). I've added another arrow which currently points to the only enemy I've spawned but I hope to tie it into the ship managment class I wrote, with a function to itterate through currently spawned enemies. First however I am attempting to add Offscreen surface rendering to the engine as currently having had to make everything smaller, so I could have a skybox that was far enough away, I can no longer render these speed and target arrows just in front of the camera and instead need to render them to a flat surface which I can render at untransformed z = 0.

Some gameplay observations, having altered the strafing functions to alter your velocity instead of your position, inline with the forward and back controls, the movement is far more intuative and fun. However the projectile system of having the speed of your ship added to the projectile is very hard to get used to at the speed at which the projectiles currently travel and likely to become annoying in a full game. There are two solutions I can see, make the projectiles component in the local-Z greater so that the momentum impartion has less effect, or drop it all together. With regards to the last I could use the Lasers weapon type suggested earlier in this document and still be in keeping with the original concept, however given that this particular app is now pretty much ignoring the original concept for practical reasons perhaps it's not worth the extra work. One thing to definately to be learnt from this project for all future projects is define exactly what needs to be done and when it needs to be done by, rather than what you would like to do without a deadline!

Final Entry:

As mentioned before this particular project has taken a turn away from it's original purpose, now it's pretty much a "hey look I built something resembling an engine for my first ever game project and slammed the very basics of a game on top", rather than what I hoped it would be, which is a fun experiment with both engine and game design. It would seem that for a first project, especially when you've got a limited time to work on it, a game engine and a game is a little bit too much. I've learnt a lot about both engine design and implementation and game design from a programming point of view, and hope for my next project to develop a slightly more consistant and powerful game engine then once I'm happy with that then to try my hand at implementing a game for it. Of course I'll have to choose what type of game before I create the engine (most probably a FPS). As an update to this project, I've added a basic AI system, so the enemy cubes and can move and shoot, all be it not that intelligently, although quite accurately, just yet. Am just wrestling with getting the exe to work without being launched from within Visual Studio, sometimes it works, sometimes it doesn't and I don't seem to be able to disern the reason, although I suspect it maybe something to do with creating the DirectX device objects in the static library and returning a pointer to the main program because if I put in a "return false" in my engine initialize just before that, the program doesn't crash when launching it from outside Visual Studio. Then it's simply a matter of fleshing out a few waves of enemies, improving the AI slightly and allowing you to choose your resolution before I can add the program to my portfolio (in which it'll be the first item).