Game Design


Back to Main Page

I have designed a few games over the years, but now with my new Windows 10 install it's time to design something a little more involved. I have always liked the 2D space shooters and my Gravitron effort a few years back still holds interest. It's time for a new challenge, perhaps something with real world physics.

Blog

25/09/2015
I have spent the last month or so working on a new game. My initial idea was to do it as as if the game was taking place on an Engineers drawing board with all the ships drawn in pencil and moving in a sort of flip book animated style. Here was my first sketch and gave me the working title of "Paper Trek".



As you can see it's very similar to the Gravitron game I did back in 2006. First I tried a few simple animations and the game just didn't feel right. I seemed to be treading over old well trod on ground. I have also tried using more conventional graphics and backdrops that you see everywhere with 2D shooters and this is what I am working with at the moment whilst developing the game, however I have recently been looking at infographics. Infographics are all over the net at the moment and generally all use a limited colour palette and relatively easy to draw graphics, which I may be able to do with my limited artistic ability. I am a regular follower of what SpaceX is doing and one infographic they published caught my eye. It was used to convey what went on during their recent pad abort test. I like both the colours and graphic style, so I will try to incorporate some of this style this into my design for a game.


As you can see the backdrop still has the graph paper / Engineers look about it and the spacecraft and text are fairly simple in structure. I belive there is a colur palette of no more than 16 colours and most of them are shades of the same basic set. I think there are about 5 base colours used.
  
   Ok this is all well and good for the fancy graphics, but what about the mechanics of the game. As is said, it will be a 2D shooter, but I thought maybe it could take place in an asteroid field and all the objects on screen would obey the laws of physics, with mass, momentum and accurate collisions. I may even add in a few nasties who come looking for a fight and some type of "Elite" style trading or gathering of objects.
 
   With this basic real physics approach in mind the search was on for a means to do accomplish this. There are several physics engines already developed. Probably the most common engine is "Box2D" which many of the other engines are developed from. There is even a C# conversion, which is nice. Another one of interest is the "Duality Engine" which I believe is an branch from Box2D. This includes a drag and drop interface for setting up the game and little pre written macros and drop down menus to help you rapidly develop any features. This is fantastic, it looks real easy.....but you know it's all a bit of a cheat isn't it. Part of the fun of this for me is learning how it all works and as I have said before I never seem to do things the easy way.

   It's been many years since I finished my Engineering degree but applied mechanics / physics is still of interest and perhaps a recap was in order. In fact it has proved a real eye opener as I actually learned quite a few things that I failed to learn the first time around. I was always a little vague on vector geometry, but now after about 25 years I think I have cracked it!

Above is a quick sample of the many pages from my "Book of Dreams" which I always carry with me to jot down things I have learned and any ideas I have.

  First off I tried to implement per pixel collision for the objects on the screen. This is where after a simple Axis Aligned Bounding Box (AABB) overlap check, you scan within the intersecting square the same pixel coordinate from  each object. If they both are not transparent, there is a collision between the two objects. I got this to work quite well, but the frame rate was around 30 FPS. This was Ok, but with all the other features I want to add was a bit slow. My framerate is capped at 60FPS anyhow as Windows C# matches the monitor rate. Next I tries using polygon collision, which is what most games use. This has proved more successful. I have the game running currently at the maximum of 60FPS .
  Polygon collision is quite interesting and I am using the Separating Axis Theorem (SAT). Basically you write code to look for any line (axis) between the two objects. If any exist, there is no collision. I found some good information here and some useful C# code which I have adapted for my use. I don't mind this as using small code snippets like is the best way to learn what is going on.
 
  One further interesting thing I have learned is the beauty of Object Orientated Programming. I studied all about this on my C# course about a year back and it is only now that I have realised the potential. As usual I thought myself how I wanted to do the game programming and then found out that this is how everyone else does it and has been doing so for years! The basic principle is you set up a class structure which contains all the "Attributes" of an object such as  positon, mass, velocity etc. and also include in this class all its functionality called "Methods". These are such things as "rotate the object" and "draw the object". To add many objects to the game we simply create multiple "Instances" of  the object class just with different data in each. So over the last few weeks I have been developing this class and it is now at the stage where I can create objects such as asteroids, the player ship and also bullets etc. quite easily and they all move as they should. Collision also works quite well, but I still need to finish this off by incorporating change in rotation speed. Collision and reaction is all quite complex and it is taking a lot of work to sort it all out. I don't mind if its not completely accurate mathematically, but it should have the main equations correct otherwise mr Issac Newton might turn over in his grave before I am done!

  Another facet of game program is how to deliver all this data to the screen in a timely manner and at a good frame rate. I have used DirectX in the past, but this is restricted to Microsoft Windows based machines (OK Wine on Linux does lift this restriction somewhat) so I wanted to use OpenGL instead which is a cross platform graphics suite. Many days of research and I found that the OpenTK library has been developed as an easy way to use OpenGL in C#. It was quite a steep learning curve and very technical for me, but I now seem to have it under control. OpenTK gives me direct access to textures and sprites stored directly on the graphics card which means much faster performance. This is the way all 3D games seem to work, so should be more than adequate for my simple 2D effort. Suffice to say it uses 3D transform matrices etc. which is yet another lecture that I must have been asleep in or slightly hung over to rememember what was going on.
   Wow this is a long post! lots more work to do yet and lots of more thinking to get a nice idea for a game. Here is the latest screen grab. I actually have lots of diagnostic data printing on the screen including velocity vectors, polygon borders etc., but I haven't yet figured a way to get these to show up on a screen grab. Also the displayed FPS doesn't show correctly in any grabs I do.

   As you can see it is very generic looking at the moment, but it a least gives me some objects to work with during development. It seems it may even be possible to add in different "skins" so it is would be quite easy to change the look and feel of the game.
 
25/09/2015
   I spent all day today working on the game and I made some quite big improvements. First there was an annoying glitch where some of the asteroids fix themselves to the edges of the game screen. It took about 2 hours to trace the fault. Usually a divide by zero error is flagged up, but changes to Microsoft Visual C# now report this as a NaN value (Not a Number) and the program just keeps going! I finally found this problem to be in the collsion vector routine and so placed a  quick check to catch this error locally should it ever occur.
   Next job was to add in some sort of Radar for the player. I initially worked on a circular design, but in the end settled for using the edge of the screen and printed some small dots to show where the player has to head to find the asteroids. This all worked really well and again made use of some maths I had learned a long time ago. I want to have a game world where there are some familiar land marks similar to how you would navigate around town. I call these "Specials" and they are added using exact coordinates in world space. All other asteroids will be generated randomly and I have this working well. I added two together and called them "The Twins". This gave me an idea that maybe a mission could be to fly between these and others in a set time. A sort of "Kessel Run" from the Star Wars Universe! It would be nice as you approach these familiar landmarks if the game posted where you were on the screen somewhere.
   As I have been unable to get a decent screen shot from using the usual print screen functions I also added a screen grab facility. Now when you press the "G" key the screen is saved to a folder on the desktop.
   Final job of the day was to have a go at an Infographic style interface. I had great success here and learned a lot about how to use Gimp image software. Here is what the game now looks like. Click the image for a better look.


Here is the game as captured by the new screenshot facility and includes all the text in the game. I am really pleased with the look so far. The red line coming from the ship is the velocity vector which shows direction and speed of travel. The edge radar gives direction to the nearest objects in the world. Any special objects of interest will show up here in red. I took the colour palette from the SpaceX Infographic and also found some other colours that complement them. I am no artist, but apparently these colours come from an "Autumn Pallete" similar to what is shown below.



The change in graphics has inspired me to continue a little more on developing the game and to think of a few more ideas to enhance playability.

29/09/2015
   I have spent the last few days working on rotational velocities. One slight quirk that I didn't realise initially was that you have to reverse one of the velocities when calculating. For example when two objects which both rotate clockwise hit each other, at the point of contact they are going in opposite directions. It sounds obvious now, but this caused me a bit of head scratching at first. The Separate Axix Theorem that I am using for collision detection doesn't give you the point of contact directly, so I decided to calculate the rotational velocities more simply. I calculated the average radius from centre of all points on the polygon and then assumed the object was circular. This way I could more easily calculate the Mass Moment of Inertia (I) which is effectively rotational mass and use the equations I had before for linear collision. The velocity at the circumference is simply related to the RPM and radius. It actually works really well. One proble I did have was that small mass object when hitting a larger object can spin up to incredible rates of RPM. This is accurate, but doesn't look very good in the game. I added a maximum RPM in the game settings to limit this. I will probaly add in a maximum linear velocity also at a later date as I don't wan objects flying in to the screen and hitting the player without him having time to avoid the object.
   Next up was to add in some bullets. I used the same class structure as I am using for the rest of the objects, so effectively the player ship just gives birth to very small bullet shaped object on its nose! Again this took a bit of work as I needed to control reload speed and also combine the bullet speed with that of a moving ship. This ensures a fast moving ship does not collide with its own bullets! It all works really now well and because they are instances of the same class type they automatically bounce off all other objects. I had to add in a little caveat in the collision routine that ensures the bullets move back if overlapping another object. The bullets move fast, so the operlap might be a lot. If I didn't do this large objects could jump back from the bullets which looks a bit odd. I can adjust the mass of the bullets, so If I set them to about 20Kg it does move asteroids slightly, which actually looks really realistic in the game. The bullet also richocet around which is again quite realistic looking. I haven't yet implemented a finite life for the bullets, so space quickly fills up with shrapnel bouncing all over the place. This is indeed realistic, but not really good for gameplay and frame rate!

02/10/2015
   Coding continues. I am beginning to get the bare bones of a game together now. Essentially the player shuttle pod has to collect various items from within the asteroid cloud and return them safely to the mother ship. Over the last few days I have been adding in the means to get the objects and the place to put them!
   Firstly I have coded a "Tractor Beam" as used in many Sci Fi films. When the beam is operated it drags objects with the shuttle pod. I tried various physics solutions including modelling a spring effect whereby the tractor beam has a natural length and any extension either way from this causes an ever increasing force to pull it back to its natural length obeying Hookes Law. This spring worked well, but was very difficult to control in the game. I tried methods of providing decay damping but non seemed satisfactory. In the end I settled on a kinetic rope type. These are used by off roaders to pull their cars from out of mud etc. The rope does not provide any force when the distance between objects is less than the length of the rope (The rope is slack). When the objects move apart the rope goes tight and then stretches like a spring. This works well in the game and is quite difficult to control. Clever use of the tractor beam is required to get the object under control. By switching the beam on and off at the correct moment also helps, and so I think this a slightly unique feature for this type of game. Towing objects like this was I remember similar to a game called Thrust 2 back in the days of the ZX Spectrum and Amstrad CPC so any slight variation will help make the game a bit different.
   Next I needed to provide somewhere to take the objects, so I have added a mothership. Click the image below for a better look.

I haven't quite finished the graphics yet for the mothership as it still looks very flat, but it seems about the right scale and the graphic style fits in with the overall look. The radar at the outer edge of the screen shows the direction to the mothership witha white square. I want to add in a tractor beam on the mothership to dock the crates automatically. I am hoping the various crates will have different masses and other characteristics such as sensitivity to bumping and some individual graphics on the side.

04/10/2015
   I have spent the last few days adding more into the game and refining the code. I was originally going to have the docking ports on the side of the mothership receive the crates, but this gave me a couple of issues. Firstly there are only 8 docking ports and this could restrict the game unless I can somehow eliminate the crates back off the ship. I had a rethink and came up with using the rear area between the engines for the docking. I moved the extra shuttle pod on top and shortened the deck area.

As you can see in the above image I have also worked on the mothership graphics a little more. I added in a "Greeble" texture and worked with a little shading to give it a 3d effect. In addition I dirtied up the look a bit and I like it much better. I suppose I like my games as I like my cars...rat look! It seemed to work well and it was very good practice for learning Gimp. I am getting more confident each day with the software.
   Further work which took most of one day was to get the tractor beam working and also the docking. I had to do the mothership in two textures, so as the crate is docked into the bay it disappears under the upper texture to give the appearance that it is entering the ship. I must say it looks quite convincing! I am still not happy with the way the tractor beam works and I may add some sort of damping to the whole world as things really do get out of hand if you make a mistake. This is just as it is in real space, but maybe a bit too hard for a game.
   Late tonight I spotted a really nice image of a spaceman on the net, so i have added them in to the game. Maybe these astronauts get stranded in space and need to be rescued......Another idea for the game!


07/10/2015
   As I mentioned above I found some neat astronaut graphics so I have added these into the game. Each astronaut has a unique name and his oxygen depletes as he floats in space. When the oxygen is used up he dies and is removed from the game. Whilst coding this I am still refining the code and now have methods within the instances to handle any special features I want to add. I am using both Interitance and Polymorphism to achiebe this which is considered some of the more challenging things to do with C#. I am really pleased that I have managed to apply all I learned on my C# course which I took so long ago.

As you can see I have also begun to implement explosions. Again I used some free sprite sheets downloaded from the net. The explosion I chose scales really well and looks particularly good when at small scale. I implemented each frame of the explosion as a separate texture. This was much easier than indexing the sprite sheet during the game loop and I guess much faster. The only thing that does trigger the explosions in the game at the moment is if you murder the astronauts with your cannons! It's rather cruel I know, but it is actually quite good fun!
    One further thing I did was change the way the radar displays humans. These are now shown as a little person shaped icon in red.

28/10/2015
Steady progress on the game. I now have added in two types of drone ship. Firstly there is a large cargo transporter which follows a series of waypoints. I intend this to be part of an escort mission or similar. These are slow moving. Second is a small ship which does line following in a similar way, but I will also implement collision avoidance and hopefully seek, search, flee and attack modes. I am hoping this block of code can be used as the basis for the enemy that will lurk in the game ready to attack the unwary! The game so far is downloadable from the link at the top of the page. I have also now added explosions for much of the objects in the game and these are sized relative to the size of the parent object. In addition the drone ships now have shields and will take multiple hits before the explosion occurs. I feel I am now reaching the end of the complex maths coding, so from now on it will be just a case of defining the structure of the game.

11/11/2015
I have been doing many other projects at the moment (My new VW camper is taking up a lot of time) but there has been some progress on the game. There are now quite a few other types of drone ships in the game and  have implemented a datatable so the characteristics of each ship type can be different and more importantly tuned easily. The image below is an example of one of the enemy. The sprite is a bit rough, but looks OK when scaled down. I have called this race of villains the "Antonyms". Which actually means a word of opposite meaning. I am now designing the basic shape of my sprite objects in Catia V5 and then taking them into Gimp to add textures. This is faster for me as I am still not yet used to Gimp line and vector drawing.

  The drone ships now steer around objects. They struggle a little with moving objects, but this works reasonably well and will probably do for now. Tonight I gave some ship types the ability to fire bullets. At the moment they are dumb and just continuously fire, but I will soon add in some more intelligent behaviour and the ability to hunt the player ship. I also divided the bullets into two types, namely "Bullets" and "Player Bullets". I was finding that the drone ships often damaged themselves when near each other, so the two bullet types mean that they are only damaged by bullets generated by the player (And Vice Versa). I must now complete player ship damage and explosionsand amybe a bit of scoring and new drone ship generation and then I will have the basics of a playable game.