Deepest Blue: The Seiddab are back

The story so far. 

 I was newly retired, had a great deal of time on my hands and decided to write a game on my laptop the old way. That meant rather than using a team of artists designers developers audio specialists, it would would just be me and my laptop. This was just like 35 years ago when I begun developing my first game on the Spectrum. Except that technology has moved on, games are generally well over 500 times as big as a Spectrum game, far more complex and usually need tens if not hundreds of man years to develop. On the plus side development technology has moved on. On the Spectrum I was hand assembling Z80 code, a time consuming and error prone process. Now I program in C (yes C not C++) and use the Microsoft Visual Studio development system. It was a huge undertaking. I knew it would be like running a marathon rather than a sprint but it has taken years longer than expected. Covid lockdown has come and gone and two laptops have been worn out. I even went back to work for a period to earn some money to build a studio, a project still on hold. Many times I felt like giving up but I have kept at it.

Why Deepest Blue?

Deepest Blue is the name of the sub space computer network that is used to control the ships remotely from the bases, named after the first computer to beat a human chess master.

 Back to My Roots

I chose to return to my roots and develop a 3d  space game called Deepest Blue. It would be an up to date version of my first successful game 3d Space Wars. It was meant to be a simple shoot em up but early on I wanted the action to take place in a world that was alive, with space stations being built which in turn built space craft. I wanted the AI ships in the game to act like players,. To create a link with the first game the Seiddab are the enemy. In this game they are the result of an  Earth expedition using AI ships programmed to seek out and collect resource and build a space infrastructure.  Many years later with their purpose corrupted they see a new wave of Terran space pioneers as competition for their resource and this means war.

Game Design

My aim was to create a game that would run well on a general modern laptop rather than a games machine that used 3d but had the gameplay and feel of a retro 3d first person shooter.  This is a well understood pattern, fairly simple in design terms and great fun and strictly no movie sequences and orchestrated game paths.  However I wanted an edge so the game did not appear shallow. I did not want Deepest Blue to be a strategy game but I wanted the players actions to influence the way the game develops. The player chooses missions or helps AI pilots on their missions  or can just fly about looking for valuable resource, or the enemy or other opportunities to get credits. Credits buy ships. The player can have several ships. The player can group ships or send them on individual missions. Each ship comes with its own pilot but the player can take control of any of their own ships as long as they are not warping which prevents any communication.

The scenario spans several star systems each with multiple sectors joined by warp paths. A scenario generator is included. It can generate scenarios at different levels of built infrastructure and sizes. This means the player can choose from a smaller battle space leading to closer contact with the Seiddab to a huge scenario across many systems with several factions. Setting a low build level gives a longer term game where each side is trying to build up its infrastructure.

Home sector map

How realistic should it be?

 I like to create a believable experience but game play comes first. I experimented with true frictionless space with unlimited speed and found this just does not work in a game. You have to have hi tech long range weapons and would hardly see another ship. As with all game decisions it has to be a compromise. I adjusted the speeds to have a maximum limit but kept the friction to nil. I gave the ships the facility to automatically adjust their velocity when they turn so they maintain the current speed as far as the engine allow. I decided that the physics must be generally true as I wanted ships with different engines and masses. When ships carry things they should be more sluggish. Small ships needed to be more manouverable than larger ships.  The background has the 250000 most visible stars of the galaxy in their correct places viewed form the visible sector so you can recognise the constellations from  local sectors. Planets are beyond the scope of this game, it is set on the high frontier of deep space. Early on I did code a planetary orbit system creator but decided his was scope creep and removed it for now.

Dock with space station, final approach

Touchdown

Missions.

Missions range from fairly safe mining, deployment or delivery missions to scouting new territories or attack or defence military missions. Missions may involve single ships or require the assembly of  man ships. The player can select their own missions but occasionally may be asked to join an existing mission by another ship.

Squads.

  I used to play an online game called BattleStar Galactica and the most fun was when you formed an ad hoc squad with several players and then attacked the enemy. My idea was that the player should be able to form squads with other ships whether they were AI or player ships. The squad AI was perhaps the most complicated or all the routines I developed.  Its one thing to get a single ship to perform properly, getting a squad to act sensibly is a different order of problem.   A squad can contain ships that have to do a mission stage and ships that have to support the action. They have to be in the right place at the right time and be able to deal with being attacked or members being destroyed.

Game Engine.

I had already developed a 3d game engine using Direct X. It uses XML to define the various forms in a game using a set of custom controls I developed. These include standard controls such as windows, buttons, textboxes, grids, dropdowns as well as 3d scenes.  It allows for each control to be positioned, assigned a graphic sound tooltip etc  and provides standard processing which I can override o just respond to events such as button pressed. It is a bit like Visual Basic in its structure. It makes writing the ancillary forms of a game really easy. You can also adjust them quickly.  I use the same stuff to develop  the supporting tools for the game. I did not have the time to learn 3d modelling for all the spaceships I wanted. So I created a spaceship part generator where I can rapidly create and texture a part. The modeller also add joins so the in game spaceship builder knows what can join to what.

I do not recommend people write their own game engines. Not only does t take years but then you have to maintain that code as well as develop the game code. It does have the advantage that it can be optimised for the game style you want to write. 

The carousel control overlays thumbnails of the in game forms in 3d for dynamic selection

How to build a game without a team

Many of the design decisions had to bear in mind I was on my own. Rather than have loads of spaceship models I opted for an in game designer so the player can design their own. Instead of a predefined game world I included a procedural environment that designs and populates then runs itself according to rules. This creates dynamic sectors that are living and constantly developing. Bases are built by players or AI ships on special missions. It is a whole living world in space trying to expand and develop, but it is in a deadly struggle with the Seiddab.  Rather than invent carefully contrived sub plots and scenarios the action just unfolds and creates its own story.

Ship designer

Progress

So what has been happening in the last few months?  I keep an actual diary of what I do each day for the game. There is quite a pile of these now showing it has taken far too long. Looking back over the last 6 months most pages are a list of issues found while playtesting and their solutions. Most of the issues arise from the AI. Once you have got rid of the plain errors due to miscoding or bad design you start coming across a subtle class of error I call behavioural. For example I can find a ship just going nowhere rather than completing its mission.  I then have to work out what it is doing, which is fairly easy using a breakpoint to stop when the target ship is being processed. Its harder to figure out how it came to be doing the current action. It may have been interrupted by a near collision or the enemy or something changed that affected its decisions, such as someone got the thing it was after first. It may be waiting for another ship that has its own problem. Every contingency has to be catered for. It makes me wonder what will happen of AI cars ever get on the road. I just read that someone is planning to use game code style algorithms rather than genuine smart AI. Algorithms are always limited by their design scope. Something out of scope can happen, and chaos could ensue. I know a huge roundabout where you go round a corner and have a red light directly in front of you on the left intended for traffic already on the roundabout. How would an ai car deal with that? 

I very often just leave the game running playing by itself and come back later to see how it has got on.  That is the level of debugging I am now at which is gradually tuning up how scenarios develop. I added things like resource price history just so I could see what is happening to the space economy. It tells me how many of each thing has been produced and should be a gradual exponential increase until the enemy is encountered or the scenario limits met. 

Scenario.

One fine summers day it was just too hot to code. I sat out in the garden with an A4 pad out wrote a little background story to introduce the scenario and also work in details of how the HUD works and interacts with The Deepest Blue sub space computer network that the game is named after.  That reminds me, need to write some kind of user manual to support the game although once the keys are known it should all be pretty intuitive. I have tried to include lots of computer messages to guide a player through mission stages and navigate across systems. There are a lot of little things that can be done such as setting destinations  on the map screen, or overriding the self balancing energy display to supercharge a particular system 

Sound.

I wrote the sound engine years ago and added a few test sounds. In the last month I have been using my Reaper DAW to record loads of sound snippets. I had to spend some time relearning how to do all the things I needed to do in Reaper. These DAWs can be complicated  and have so many controls. It is hard remembering where you go to do an action. This is nearly complete. I have made good use of a couple of old style synthesisers that can produce sounds like early Doctor Who or 60s sci fi films. These are fed into a utility that merges them into a loadable file for the game. I have a few to do but they are almost complete. Many of the in game calls to activate the sounds are in place. Things like buttons have their own specified sound effect. It is juts a matter of getting them fixed up to to correct sound in the XML definitions. There are a couple of new sounds that have been added as I was playing around with them. In space you cannot hear anything of course but games need sound to make the action exciting. For things like non player ships engines I decided to do the sound as if it is heard by a sub space sonar that assists the pilot to locate and distinguish objects. 

Graphics.

Rather like I used to in my early programming days I used to leave the final graphics to almost the end of the development.  I would use placeholder graphics for ages so I could get on with the coding. I can remember in Avalon only having a wizard graphic that fired wizards at other wizards. There are two main types of graphics each that requires its own approach. Firstly the static sprite graphics for things like the HUD icons or form controls. Some of these a=have to be craftily constructed. A textbox for example is made up of  four corners, 4 sides and a middle. That way the middle and sides can be stretched to make any size textbox. Window/panel  frames and buttons are also like this.  The method of pixel bashing these graphics has not changed much. In the early days we started on squared paper and hand converted that to hex code. Andrew Braybrook wrote our first graphic editor but this was soon replaced with commercial editors. I use Ulead Photo Impact which I obtained when I bought a graphics tablet.  It is much like Photoshop and deals with loads of graphic formats. I do miss the use object as brush facility of Dpaint though. 

Ship selection form

The other  graphics that I am working on are the textures for the various models. Rather than use specific textures for each model I use generic texture sheets with lots of features on them and map these onto the parts with my modeller. This allows me to select an area of the texture that suits the look of the part. The skill comes in anticipating all the sorts of textures you need and laying them out on a single texture page so they can be used in all sorts of combinations. For each ship texture sheet I also need a damaged texture sheet that gets overlaid on damaged parts. I also need standard things such as steroid textures. I use a combination of photos, drawings, texture generators and hand made textures. I have got this far on my own so am adamant not to use another artists work. 

Statistics

Laptops worn out.   2

Diaries:  at least 6

Game code modules: 28

Game Engine Modules: 44

Man hours so far : estimated > 7000 for the game code

Visual Studio versions 4

Direct X versions  4 

No rulers were broken or cats harmed during the development of this game. (see Paradroid Diary of a Game part1).

What's next?

Its getting to the time where I need to decide what I am going to do with my creation.  I have started some time looking at various marketing platforms. The prerequisite is to get the look of the game up to production quality so I can create finished looking photos and videos. I also need to be sure that the code is at least Beta quality so it is ready on time as publicity ramps up. Being on my own this is perhaps the most difficult bit. Until I have finished it is hard to estimate exactly how long it will take. Most issues only take an hour or so to fix but occasionally a flaw is exposed hat leads to some shuffling of code and inevitably creates more issues.  I suppose its the old project managers question of when it will be complete, and the answer , when its done.  I know I am close but on your own all timescales are horribly extended. I can remember the pressure in the 80's as publishing time approaches, and working through the night to hit a deadline.  Occasionally I work a late night if want to knock a problem on the head. I like to finish at a good point. It is so annoying if a crash happens just as you are ready to pack it in for the night  and requires you to at least get enough data so you can reproduce the bug the next morning.

Close Encounter