Avinders

Avinders is a game that I have spent a lot of time on. Originally it was a project developed in a team of 5 at a HEADSTART course run at Aston University.

On the course I was introduced to the three.js library and the ability to run plug-in free 3D graphics on the computer. From that I had the idea for a project we could present that should be doable in the time we had.
The idea was that you could take space invaders and make it 3D so that the user could get a different perspective on the aliens attacking.

Although we didn't win the competition, we did get a notable mention for the project has been “out of this world”, which resulted in us winning the equivalent prize of first place in the competition anyway. Quite the achievement.

Over time and with a functioning version I decided to continue to implement elements that I wanted to add. The direction I was going for, although I didn't know it at the time, was something akin to the elite game from the 80s.
The original game was purely client-side JavaScript which I was running off a mongoose server, something that we were introduced to by the headstart course. The reason for requiring a local server despite all the code being run client-side is to get across browser restrictions on sites accessing local files through JavaScript.

I slowly added elements to the game, adding a full sphere backdrop in which the game could be played. Originally you were contained within a cylinder.
This was later upgraded to a bounding box, developed in a graphics package by someone for a separate tutorial. The bounding box was a large improvement in the repeated Hubble image initially used.
The next thing to be added was a simple planet. This was first implemented as a sphere with a planet texture-mapped atop.

Taking the game to the next level

Throughout university I worked on the game in my spare time. The first thing I wanted to do when I started working on it again was to build in some kind of system that would facilitate some kind of storage, allowing for the page to reload and the game to continue where you left off.
To do this I implemented a PHP backend which would be called using ajax requests from the game. I created a MySQL backend that integrated with class representations of concepts in the game. I hadn’t yet discovered the problems with not extracting the implementation of the database code from the object structure as is so often mentioned to be best practice.
As a result of this the classes representing concepts such as a ship and its cargo bay were embedded with SQL scripts themselves. Along with the separation of the database from business logic (if you will) I hadn’t understood the use of an ORM to allow for the much higher-level implementation of handling the database. As a result the SQL queries were simply sanitized using the default PHP sanitizer of the time. (I think 5.4 was the only version I could run for free on the server)

In hindsight it would have been better to use node.js over PHP for this project as I would have only had to have the concepts implemented as objects in a single language. Instead I had both a PHP object implementation and javascript implementation.
(In fairness to my previous self, this also ran into the constraints of that free server, in which I could only run PHP 5.4)

At this stage, I had the cargo screen as a separate web page to the main game, and separate again to the navigation pane.

One of the other early changes was to go from the spaceship you can see in the introductory picture to my first iteration of the liberator. Which was inspired by the 80s hit sci-fi Blake's 7. Soon after I manage to build a better model in blender.

My original model of Blake's 7 Liberator, this one is built using only the shapes in the game, hence the cylinders, cones, and sphere used.

An improved model made using Blender

The actual ship from the show

Being able to click on a planet to enter navigation to that planet.

Originally the navigation was simply a list of places with hyperlinks passing the location in the encoding of the URL. I wanted to make it instead of a solar system view where each planet could be seen orbiting the sun and each moon could be seen orbiting its host.
I ended up with a view that was not too dissimilar to what I imagined.

Moving to a single page

One of the large changes that I made as the game went on was to move to a system where elements of the game outside of the combat went from being pages in their own right to things that would be loaded dynamically and displayed.
This made the whole game far more immersive. It made it feel like a proper game. Instead of separate menus on their own pages the content was generated and loaded up in front of the canvas the scene was drawn in.
To do this I implemented a structure that would allow the pages to be changed dynamically with possible transitions between them. These page objects could then be loaded and unloaded in the main codebase.
To achieve this I had to do a lot of work to understand javascript closures, which would have been a lot harder were we not doing a module on them at University at the same time I was making these changes.

The change to a single page for a long time and required a lot of rework on the javascript code. This was made more time consuming by the fact that I neglected to implement a test suit. Not through lack of trying, or knowing that testing was important. Instead the graphical focus of the project meant I struggled to isolate the mechanical logic from the graphical logic.

I tried, unsuccessfully, to implement the jasmine javascript testing framework.

The main game screen, after being made into a single page.

Trying to add Facebook user integration

If I could have given myself one piece of advice at the beginning of this project, beyond any coding advice, I would have said "Please, don't try and integrate with Facebook just focus on the game". I spent a large fraction of the total time I spent on this game trying to integrate login with a Facebook user system that would link players of the game with their profile. I still don't really understand what it was that caused me so much trouble trying to get this game integrated with Facebook and I feel I did get elements of it working in demos outside of the game.
One of the reasons I wanted to originally get the game linked up with Facebook is because the actual specification on that original headstart course was to use the other new technology we had been introduced to, javascript integration with Facebook. We did have a plan in our original design for space invaders to have your profile picture on the spaceship, however, we never then managed to get the Facebook API working.

Terminal

One idea that I really liked to think about was that the ships in the game could have their own console where players could write code that would enable them to remove the grinding elements of the game as they arose.
Looking back on the structure of the game I am really pleasantly surprised at how well I managed to abstract the code that carried out the sort of state changes that could be done in the terminal so that the in-game events which enacted them could be reused.
An element I wanted in the code that could be written in the ship's terminal was that it wouldn't be Turing complete. It would only have loops of a fixed size. That would mean that the code could be run and guaranteed to halt.

The console view

Particles

A visual element of the game that I found very gratifying to implement was the monopropellant spray that would be ejected from the space ship when the user was dodging left and right avoiding the fire from the aliens.

The other implementation of particles which I think was visually the thing I am most proud of in the game is the explosions of the alien spaceship when hit by the player's fire.
The spaceship would disappear into a fireball which would have smoke spreading out afterward, I even added a lighting effect causing the other ships to light up as if eliminated by the explosion. From memory I might have had to remove the lighting effect because, in the simple implementation I had, it caused the frame rate to drop significantly when more than one alien ship was causing the extra lighting at any one time.

Showing the ship moving to the right, with monopropellant spilling out left.
An alien ship explodes.

Trying to add user management and the fall of the game

I haven't worked on the game now for a number of years and I think the reason for that is the last thing I tried to add. As I’ve already mentioned in this post, I wasn’t well versed in the separation of concerns principles for the architecture of software projects. In fact the only architectural / design pattern I had heard of was MVC. Incidentally as a result that is the architecture, I went for, at least within the javascript side of the code.
The last thing I tried to implement in the game was adding user management. Thus far, although the design of the database allowed for multiple users with their own spaceships and cargo, when loading the game the user would always be the same. There was no login screen for example.
One of my desires for getting the login working was the ability to share my work with other people in a larger way than just posting screenshots to my Facebook album. It would have been nice to have a live demo of my work. I felt it would be a nice addition to any applications I made. Up until this point every job I had got, I had shown some element of the game in a stage of the interview process.
Unfortunately DevOps caught up with me.
As a result of not having used any separate management system for the database setup I had to run a startup script of my own making.
This never worked well and the database had to be deleted every time I wanted to run the script to make sure it ran in a stable manner. It didn’t always run, and the way it has been written made debugging the SQL scripts slow.

Ideas I wanted to implement

Lumigraph

There were a lot of ideas that I never managed to implement that I had planned out. One idea was based on the idea of a lumigraph.
A lumigraph is an idea in computer graphics where the object in question is pre-rendered from many angles and then added to the scene as a hologram. The advantage of this technique is that large amounts of computational power can be thrown at the rendering of the object in exquisite detail while when using the object the only computation required is reading from memory.
Given that the idea for the game was always to be playable in the browser and preferably on a Chromebook implementing something akin to this lumigraph might have been a good way to create super-realistic graphics cheaply.
Not much has been written about lumigraphs there is this paper. One of the reasons I believe they have not caught on in the way the payoff for rendering invested against rendering saved works.
The amount of rendering required to produce a lumigraph of any quality would be prohibitive. In its raw for the lumigraph would require a full rendering for every angle required. Obviously if the resolution of these angles is not high enough (One for each degree would probably be insufficient) then the image will flicker, resulting in a poor outcome for so much pre-rendering.
The angles also have to be in both planes meaning if you were to produce just one rendering for each degree you would need to render the view of the object 360^2 times. If instead, you went for a higher resolution, a tenth of a degree, the number of renderings would be 100x more. That is over 12 million renderings. Each of those is a picture. That is a huge amount of pre-computation.
If on top of that the object has some internal changes over time, you would want to render each of those 12 million images 30 - 120 times per second.
That could be close to half a billion render frames for 1 second of lumigraph.
Separate from the initial cost of the render is the storage of half a billion images.
I had an idea for reducing the size of these renderings and it is based on how movies are encoded. Although when rendering an animation each frame has to be rendered separately, when they are stored in a movie file these frames are compressed. The technique of compression used relies on an assumption about movies. That is the one frame is very similar to the next. Not much happens between frames, what does happen is normally movement.
This means that movie files can store far fewer frames and generate the frames in between by storing information about how blocks of pixels move from one frame to the next.
I believe a similar technique could be used for the lumigraph. The change in the angle for the lumigraph will be incredibly slight. As a result a similar style of compression could be used to go from one frame to the next.
I imagine, although I have never run an experiment, that because the lumigraph has these similar frames in more than a single direction. The reduction in the storage required would be immense.
There are 4 frames one degree (If the resolution is a single degree, there are still 4 closest regardless) away from any frame. If a changing lumigraph is required then there are 6. This is in contrast to a movie file where there are only 2 adjacent.
The number of frames which are within a distance of 2 from a given frame would be 4 in a movie file. In a changing lumigraph there would be 20. To me at least this shows the potential of this style of compression to make the lumigraph’s file size tractable.

Realistic wormholes.

I wanted it to be possible to travel the solar system in the game either by using jumps between planets or if someone felt the desire under the slower in orbit controls.
The way wormholes are portrayed in science fiction annoys me because they are shown as two-dimensional gates. This is fine for portals but wormholes have a well-defined geometry and I wanted to simulate at least a little of that in the game.
Since my plans to include this in the game, Scott Manly has made a brilliant youtube video showing what wormholes would realistically look like, using accurate simulation of the way spacetime would bend.
The style that I wanted to go for would be a wormhole with no neck. This is the simplest to simulate as it would appear as a sphere in space, where the surface of the sphere would look like it was looking out the other side.
This would have been relatively simple to produce in the game as a camera could be used at the destination of the wormhole which would then make up the texture on the originating hole.

A still from Scott Manly's video, where the neck size is zero

Asteroid belt

Although I managed to create a cool representation of asteroids where the model was made in blender based on this tutorial, I always wanted to implement an asteroid belt. My idea for it would be that it was the wild west of the solar system. Around the planets you were under the jurisdiction of the planet governments and so would be reprimanded for failing to abide by their laws. I wanted to include random customs checks much like there was in the original elite (as well as a chance of encountering pirates).
The asteroid belt would have been filled with mysterious objects. I did have a plan to try and have these generated by the game itself by creating a category of object where the description of the object would then come from all the kinds of that object that could be found in Wikipedia. This way somewhat loosely based on the objects that could be found on various planets in the spore galaxy. The idea is to try and produce as much game as possible while still only being one developer myself.

Economics

I have always been interested in economics, something which drew me to fintech. I wanted the economies of the game to feel real. For them to be breathing, having different products become more or less valuable. Have food shortages and economic collapse through speculation. I wanted differences in regulation between the governments to create arbitrage opportunities for the player. Where if the player got large enough they themselves could affect the price.
I had a design for cargo ships that were based around lots of containers between a shield and a booster. I wanted the number of container ships you could see in orbit to mirror the way the economy of the planet was going.
I realise now the ambition of my goals with respect to the realism of the economics in the game. I still find it fun to imagine.

This post

So although I wanted to post every Sunday this, the third post, is late. This is somewhat due to its size, it is far bigger than the previous two. It is also because I was undecided on if this, or another one of the partially written blogs I have should be posted.
I found this piece harder to write partially because of its size, but also because this game was developed over such a long period of time, the amount of ideas is far greater than I could recall in the time I have given myself to do so.
The other thing I have found more challenging is the style of the post. Rather than trying to explain something like last week's post I am without much direction posting the ideas I had for a project I no longer work on.
Next week I am hoping to post on time, and post something shorter.