Thaddeus' Dev Blog

I’ve come up with some initial artwork for trolls to have in the troll levels:

Currently, I have four different torsos (all visible above), as well as 12 different hairstyles. In addition to the twelve hairstyles, there are three different standalone skull styles that can be worn for bald trolls, or combined with other hairstyles:

In my previous post, I talked about an alternative method for encoding recolourable images from the one I was using previously, and the pros and cons of doing so.

Both this new method and the previous one did not fully support translucent parts of the source image however, in that the proper colour would not be maintained under certain situations if the source image was partially transparent.

To understand why this is, we need to understand alpha premultiplication:

Alpha premultiplication

Essentially, when an image is rendered onto a background in computer graphics, the resulting rgb of the image is evaluated to this:

output.rgb = image.rgb * image.a + background.rgb * (1-image.a)

In order to make this formula slightly more efficient when rendering images on screen, the rgb values of images can be premultiplied by their alpha values. This means that if a pixel is 50% translucent red, it will be stored in memory as rgba(0.5,0,0,0.5) rather than rgb(1,0,0,0.5).

This allows for the formula to be simplified slightly to this:

output.rgb = image.rgb + background.rgb * (1-image.a)

Because of this, OpenGL premultiplies the alpha values of all images by default.

 In most cases, this leads to slightly more efficient rendering, as one less calculation needs to be performed, however this can cause issues for shaders that read the rgb values of pixels and perform mathematical operations on them other than the standard rendering formula:

Implications of alpha premultiplication on the encoding methods

Considering the previous method for encoding images:

If we think about a pixel in the source image that is 50% translucent red, this pixel will be stored as rgba(0.5, 0, 0, 0.5). When this pixel is evaluated by the fragment shader, this will result in the output pixel colour only being shifted 50% towards the custom red colour, as the red pixel value is only 50%. This is problematic, as the colours will not be correct in translucent regions of the source image.

This shows what fading from each custom colour to transparent will look like for a set of arbitrarily chosen custom colours using this technique:

This is not likely to be particularly noticeable for the previous use cases of recolourable images in xargus, as the only use of translucency was where the black lines surrounding the images would fade outwards, which is a tiny area.

However, going forward, this is an issue that needs to be fixed, as other images are likely to require use of translucent areas without colour distortion:

Fixing this issue for the previous encoding method

In order to fix this for the previous encoding method, we must divide each pixel value that we read by the alpha value, to reverse the effect of the pixel premultiplication (changes shown in bold):

Fixing this issue for the new style encoding method

In order to fix this for the new style encoding method, we only need to divide pixel.r by pixel.a:

The reason we do not need to divide the other values by pixel.a (such as pixel.g) is that we are already dividing them by pixel.r. Both pixel.g and pixel.r are premultiplied by pixel.a, so no further division is required.

I have been experimenting with making adjustments to the algorithms and methods that my game engine uses in order to dynamically recolor images, in the hope of increasing the efficiency of dynamically recolouring images, as well as making it easier to create recolourable images.

Doing this will hopefully allow for recolourable images to be used in Xargus more easily and more efficiently, paving the way for their use in more places throughout Xargus, such as in background detail images, floor detail images, enemies (recolourable skin, hair and clothing), and in the alien (recolourable skin and potentially clothing).

Changing from using Red pixels to encode black areas to using black pixels to encode black areas

Currently, I use the approximate following method for providing dynamically recolourable images where they are used in Xargus (currently they are only used for the hill backgrounds and grass tile background):

This method was used as it was easy to implement and relatively efficient, however the major drawback to it is that it is quite complicated to generate the images used – each colour needs to be layered on top of the previous one additively, which involves recolouring different parts/layers of the original image, and takes quite a bit of time in photoshop; especially recolouring all the black lines and shading to be red and use additive blending.

I have therefore come up with an alternative formula to use that does not suffer from these problems, as it uses black instead of red as the colour for black lines. This is slightly more complex as a formula, due to the fact that black is the final colour that should be added to the image and merged with all previous ones, and it is difficult to measure the amount of black as a single value (i.e. measuring the amount of red can be done with pixel.r, but with black this isn’t as straightforward):

This alternate method allows for a significantly easier way of creating recolourable images, at the expense of a slightly more complex (and therefore slightly more expensive) algorithm. I am hopeful that this additional expense will be minor.

The key way in which this method works is that all of the non-black areas of the image have a red value of 1 (the maximum), and then additional custom colours are made by layering them on top of the red colour in an additive way (i.e. the green custom colour would be green+red = yellow, and the blue custom colour would be blue+red = pink). This way, the amount of black in a pixel can be measured by (1-pixel.red)

This method involves a slightly more complex formula as it is necessitated  to divide by pixel.red when working out how much of each custom color, as pixels will contain less red value when translucent black has been added over the top of them.

This post is going to be about quite a complex overhaul of the level select screen, with it now having previews of the levels in, and parallax scrolling, which I added in ages ago, but never got round to posting.

Essentially, I decided that rather than go with the previous plan of coming up with a custom drawn image for each level, it would be look nicer to provide an automated preview of each level from the level select screen instead. 

This also means I won’t have to create a separate image for each level going forward, which would have been increased the time to add each individual level etc. I generally find that it is a much better option in the long run to expend development time initially developing a more complex system that will allow you to add more features in less time later. 

The new look level select screen looks like this:

Each of the level squares is dynamically rendered based on what the actual level looks like, so no additional setup is required beyond choosing which ground tiles to show. Animated parts of the level (e.g. the corn, foxgloves, etc) are also animated in these squares, which is subtle, but is a really nice touch:

As part of this change, the play buttons are now dynamically recoloured to be the same as the sky colours for the level, rather than them all being blue.

Animated fading

I also added fading into the level select screen, so that when you scroll along, levels fade out slightly as they reach the edge of the viewport. Also, when you enter/exit the level select screen, all the levels fade in/out. 

This seems like a very standard thing to do, but it actually proved to be somewhat complex to implement, as the rendering for each level square was built up of a lot of images rendered on top of each other (i.e. each tree is an individual image) rather than one image. This meant that it wasn’t possible to simply render each level square with standard transparency to get a fade out effect.

One of the ways I could have got around this would be by rendering each level tile to a separate texture and then rendering that texture to screen in a translucent way, in a double buffered setup. My game engine doesn’t currently support this however, and I wanted to put thought into adding support for something like that rather than just adding it in, as I was concerned there may be complications that could arise from having to maintain and best use texture memory that could change in size.

Currently, I therefore implemented this by rendering parts of the background in a semitranslucent way on top of the faded out squares, which adequately achieves the fade out effect in my use case, as the background is mostly a solid colour. Long term, I will need to look at the best way of implementing a double buffering system.

Clip rectangles / not rendering invisible parts

Another feature I implemented alongside this in my game engine is the ability to set a clip rectangle for a part of the screen that should be rendered to only, which was required for having the level squares.

My game engine ensures that all images drawn while a clip rectangle is set will be cut off so that parts outside the clip rectangle won’t be sent to the OpenGL pipeline to be drawn also, which means that clip rectangles can be set in order to prevent certain areas of the screen being rendered to twice, for example preventing the background from being needlessly drawn behind the ground/hills.

With this logic to cull parts of images drawn outside the drawable area, the level select screen runs at 60fps on my device, which I am relieved about, as there are quite a lot of layers being rendered with different shaders.

It’s been a significant amount of time since I last made a blog post (about 7 months I believe!) so another one is most definitely due. This post will discuss how I plan to move forward with this blog in both the medium and the long term, and other stuff like that mostly.

Regarding my 7 month absence from posting, I started working full time as an Android Developer at an engineering company approximately five months ago, and before that I spent about a month or so interviewing with various companies and applying for jobs, and stopped working on games and this blog for all that time.

I plan to start posting to this blog slightly more frequently, and resuming work on my games portfolio by working at the weekend and over holidays on personal projects. This will likely still be quite infrequent however, as it’s quite difficult to balance full time employment while working on personal projects at the same time, but I should hopefully be able to write a post somewhere between once a week and once a month.

Xargus

Essentially, it was becoming very apparent to me that Xargus as a project in its entirety, including creating the custom game engine that I was working on, was effectively a 3 year project that I was only halfway through, and it wasn’t financially sustainable for me to continue working on it for another 1.5 years.

Attempting to cut corners, reduce features, or ship Xargus before it wasn’t ready & polished in order to reduce this timespan wasn’t a very attractive option to me either, as I wanted to do the game justice.

Now that I work full time, I’m not sure that it will be feasible to get Xargus finished in any reasonable timespan; realistically I think it would take three years at least to finish this while working full time, which isn’t something that particularly appeals to me.

I do still plan on making apps in my free time and posting about them here, however I think it would make a lot more sense financially for me to work on much smaller projects that I can get finished in 3-6 months each whilst working full time, in order to build up a suite of apps on the play store. While doing this I could also work on improvements to my game engine which would be ultimately beneficial to Xargus and other complex apps in the future.

I think that an approach such as this, posting a whole load of smaller apps rather than working on one really big, complex one, has a much higher chance of being financially successful, as there is quite a big risk that apps will completely flop and not make any money, especially if you don’t have an advertising budget to launch it, which is a big hit if you have spent a long time working on an app. 

Currently when starting a new level in Xargus, the game pauses/freezes for approximately 2.5 seconds before the level starts. The reason why this happens is that new resources need to be loaded that are required for the level, and this loading is happening in the main game thread.

In this blog post I’m going to explore various ways of reducing asset load time, as well as exploring ways of making load times less annoying for the player, through the use of loading animations, threading, etc.

The Asset Loading Process

Currently in my game engine, whenever a new screen is loaded, all assets required by that screen are also loaded from the apk file assets into memory / ram, and then appropriate assets are then sent to opengl, which handles sending them to video card memory as appropriate.

Image assets are stored as large texture atlases that are created by a software package called TexturePacker. Each of these texture atlases consists of a .json file that requires parsing, and a corresponding large .png image. The .json file contains data about which parts of the larger .png image contain each individual image file.

Sound files are also loaded at this stage, but the process for doing so is handled by an Android SoundPool class, is done so in a different thread, and my game engine isn’t particularly involved in handling the loading of these.

The most expensive part of loading these assets will be reading the files from the apk into memory - file I/O operations are generally quite expensive. My understanding is that transferring these from memory into openGL is likely to incur some expense, but nowhere near as much as reading them from disk to begin with.

Multi-Thread Loading, Loading Animations

The first thing that can be done in order to significantly improve the user experience is to load all images in another thread, and provide some form of visual animation to the user while this loading process is happening.

Creating a really nice looking animated screen transition would be a great way of hiding the loading process, for example filling the screen with images until it is full, then removing all the images one by one, or having big metal bars come down over the screen. A screen transition can easily be 0.5 - 3 seconds long without the user being annoyed that it is taking too long, meaning that so long as all the loading can be done in this time, it is the only thing required to make the game look seamless. Most cartoons, and lots of games, have quite interesting screen transitions to look at for inspiration, for example:

Youtube - Flowers Screen Transition

Youtube - Superfriends Screen Transition

Youtube - Batman Screen Transition

It is worth mentioning that fade transitions (ie fading smoothly from one screen to the next), or most other windows movie maker style transitions, would not work. Most of these type of transition require the second screen to be loaded for the transition to animate, as they display parts of the second screen at an early stage in the transition, whereas cartoon style transitions mostly don’t.

If it is not possible to load all the resources within a 3 second window or thereabouts, it is a good idea to provide a loading screen, as opposed to simply having a really long transition. The following are best practices for loading screens:

It is better to animate into and out of the loading screen, rather than just having a “loading” message appear on screen. Fancier animations/transition-style animations are better than simple ones, for example, in a snow-themed game, it would be better to have the entire screen fill with snow from above for 2 seconds, followed by loading text fading in over the snow for 0.5 seconds, and then having a 0.5 second transition after loading where all the snow melts away, rather than simply having a loading popup fade in and then fade out again.

If the loading bar is on screen for more than 5 seconds, it is better to provide a loading bar that shows progress, so the user can see how long loading is going to take. Seeing a loading bar mitigates user’s impatience to some extent.

Simple ongoing animations should play during loading, such as having a simple particle effect, or having the loading text pulsate in some way. Looking at a simple animation is less boring than looking at a static screen. These also indicate to the user that the game is still loading, and has not crashed.

If the game does crash during loading, or one of the resources could not be loaded from file, etc, a message should be shown to the user explaining this, rather than just force-quitting the app, or perpetually staying on the loading screen. In some cases it may be better to allow the user to play without one of the resources being loaded - for example, if one of the sounds doesnt load, this isn’t a deal breaker - the game is still playable.

Common Sense - Reducing Surplus Assets

The most simple way of reducing load times is firstly to ensure that no unnecessary assets are being loaded. This is quite common sense, but I thought I’d mention it anyway. 

For example, by splitting texture files up into smaller texture files, it is easier to load less info from memory in order to get the images required (although, convesely, it is often better in terms of openGL performance to have larger texture files - there is a balance to be struck)

Reducing the resolution of images is another way of reducing asset load time, among other common sense methods. These will vary for each individual game.

Optimized 256-Colour .PNG Compression

Because the largest impact on asset load time is the time it takes to load the files into RAM, reducing filesize of the images will have a significant impact on load times.

There is a way of significantly reducing the filesize of png images, that has been popularized by sites such as tinypng .

Essentially, in most png images, each pixel’s colour is stored individually, as 4 bytes (alpha, red, green, blue), and then some lossless compression is applied to reduce this filesize.

A more efficient way of doing this is to instead store 256 different colours that the image will use, and then, for each pixel, use only 1 byte to encode which of the 256 colours will be used for that pixel. An algorithm can then determine which 256 colours to use to best recreate the image, and a technique called dithering can also be used to blend colours together better. This results in filesizes that are 70-80% smaller.

This wikipedia article explains how dithering works, and demonstrates this technique in more detail.

It should be mentioned that although the filesizes are much smaller, the images will use the same amount of memory in RAM - my understanding is that images will be stored as full uncompressed bitmap-style images in RAM. This means that although file I/O operations will be much faster using compressed images, communicating these images to openGL and manipulating them in memory will not.

I created versions of my main texture file that were compressed in this way, and I got the following results:

Uncompressed:

Compressed:

Although the images still look good, they are clearly not the same quality as when uncompressed. On the mushrooms and alien faces in particular, the dithering technique that has been used is very clearly visible, and the colours are slightly off for the mushroom.

This effect is particularly pronounced in this texture file due to the fact that there are a lot of different colours in it, as only 256 different pixel colours can be used for the entire image. Potentially, by splitting it up into smaller texture files, compression would produce results that were of better visual quality. If, for example, all the alien images were on a separate texture file, then a greater proportion of those 256 available colours could be allocated to the bluey-purpley shades of the head, and the result would be better.

Demonstrating this, here is what compression of just the head image on its own looks like:

Uncompressed:

Individually compressed:

The two images are pretty much indistinguishable - the noticeable dithering effect seen in the previous compressed image is not present whatsoever.

It should also be noted that this visible dithering effect is likely to be significantly reduced in rendered images due to the fact that it is highly unlikely that images will be being rendered at pixel-perfect 100% scale - they will have some scale factor applied to them, and due to the inherent nature of how bilinear interpolation works, this will result in the graininess of dithering being reduced slightly.

I used the compressed texture file in game to see how it would look when rendered, and the results were as follows:

(Note that many images are on a seperate texture file and therefore were not subject to compression - only the alien, all guns, and all enemies are on the compressed texture file)

Main Menu Screen - Uncompressed:

Main Menu Screen - Compressed:

Main Menu Screen - Uncompressed - Zoomed In:

Main Menu Screen - Compressed - Zoomed In:

In Game - Uncompressed - Zoomed In:

In Game - Compressed - Zoomed In (Note that only the alien has been compressed, background trees have not):

In all the compressed images, the visual graininess artefacts of dithering are visible, and this does damage the crisp, clean aesthetic of the particular art style I am using to a degree. This may not be the case to the same extent in different games with different art styles.

Texture Loading System - Loading Compressed Image at 150% Resolution:

One solution would be to store the image on disk compressed at 150% of its resolution. 

This would take up 1.5*1.5*0.3 = ~68% of the filesize of the original (100% resolution, uncompressed) image.

Then, when it is loaded from disk, it would be loaded into RAM at 150% resolution (as it exists on disk), and then reduced down to 100% resolution before being sent to openGL. This reduction would go some way to removing the visual graininess artefacts left behind by the dithering process, due to, as I mentioned earlier, the way in which bilinear interpolation (image scaling) works.

However, reducing a very large image such as the texture from 150% to 100% in RAM would potentially have a noticeable effect on loading time - each texture image is about 2000x2000 pixels big at 100% size, which would be 3000x3000 at 150% size. This, combined with the fact that the image would still be 68% of the original filesize, means this is not a great idea.

Complex Texture Loading System - Individually Loading Each Image & Programatically Constructing Texture:

Another improvement over simply compressing the whole texture file is to generate the .json file as normal, storing the best fit positions of each image file in the texture file, but then rather than generating the texture image as one file, saving each image seperately.

A script could then be run compressing each image. Visual artefacts would be vastly reduced over compressing the entire texture file, as each image would have its own 256 colours to work with, rather than having to share these 256 colours with all the other images in the texture.

This is demonstrated above with an alien face image, but to redemonstrate it with the alien’s T shirt (which is an image that is quite difficult to reduce to 256 colours, as it involves vibrant colours all across the rainbow spectrum), here is what the T shirt looks like when compressed as an individual image:

Uncompressed:

Individually compressed:

Which isn’t amazing, but is a noticeable improvement over how the T shirt looks when compressed as part of the entire texture (also shown in above compressed screenshots):

(I used imagemagick to count the number of colours in this image and got the result 125 - around half of the colours used in the per-image compression. Also, those 125 colours will not have been optimised for the individual image)

Then, when the assets are being loaded, each image can be loaded separately from file, and the entire texture file can be constructed according to the instructions of the .json file.

This could be done in a two thread setup whereby one thread performs file I/O to load images, and another thread takes images that have been loaded into RAM and places them in the appropriate place in the texture (probably using the Android Canvas/Graphics API to do this). This way, the loading process should not be noticeably slowed down by the fact that texture files are also having to be stitched together from their individual image components as part of loading.

I am also unsure whether loading each image separately from different files would be slower in terms of file I/O operations than loading one big texture file. If it is the case that it is slower, this could hinder this method’s effectiveness.

This looks like a good idea overall, although it would take a bit of time to implement - currently, I use TexturePacker which automatically resizes and packs all my images from their source files (as each image is absolutely massive resolution when created, and then resized down to 35% of that in the texture file). In order to work with individual images rather than TexturePacker texture outputs, I would need to create a compile time script that resized all my images down to 35% size, and compressed each one individually. I would obviously also need to implement the code to load these images from file into memory and stitch them together into a larger texture.

Initially Loading Low-Res/Compressed Images, Then Loading Full-Res Uncompressed Images Afterwards

One way of significantly reducing the initial load time would be to initially load versions of the texture file that were low resolution and/or compressed, and use these. Then, once these have been loaded, the game/level can start, and the higher res versions of the images can be loaded in the background. When the high res versions have been loaded, these can be swapped so that the game uses the high res ones instead.

The following table shows what an image of the cow’s head looks like when reduced to various scales and then rescaled back to 100%. It also shows the filesize required to store each reduced size image:

As is visible, scales of 0.2x to 0.4x leave significant visual artefacts that are very undesirable, leaving these largely unusable. Scales of 0.5x to 0.7x have some visual artefacts, and are a bit blurry/not as crisp as the original, but largely these would be fine to display to the user, and would only require 8%-15% of the filesize (and therefore a similarly reduced percentage of load time) compared to the uncompressed original.

To understand the potential advantage of this fully, consider hypothetically that it takes 10 seconds to load all the images at 100% uncompressed size. This is represented on the following graph:

Now consider that instead, a compressed image of 0.5x scale is loaded first, then the full sized uncompressed image is loaded afterwards:

The game becomes playable at 0.8 seconds (as a compressed image at 0.5x filesize takes 0.5*0.5*0.3=0.08 (8%) of the time to load compared to the original uncompressed). Then, the game starts using the full sized image at around the 10.8 second mark.

By doing this, we have significantly improved the way in which the game loads - now the user can play the game/level from the 0.8 seconds mark, albeit with low res, somewhat blurry images. Playing the game with low res, blurry images for 10 seconds is vastly preferable however to staring at a loading screen.

We can even go one step further than this, by loading 0.5x scale images, then loading 0.7x scale images, and then loading 1.0x uncompressed images:

This way, the game is playable from 0.8 seconds, then at around the 2.4 second mark the image quality gets improved moderately, before the images become full quality at around the 12.4 second mark.

The exact combination of which scales to load would differ for each texture in each game, depending on a whole variety of factors. For example, in Xargus, where the load time is currently approx 2.5 seconds, it might make sense to load the 80% compressed version first, which could load in approx 0.5 seconds, and then have a 0.8 second transition on the screen to cover up this load time and make the loading appear seamless.

Having An Asset Manager That Intelligently Manages *Unloading* Of Unused Textures To Avoid Unnecessarily Unloading & Reloading Textures

Currently, when a new screen is loaded, all the textures required by that screen are loaded into memory and sent to openGL. When the screen is unloaded and a different screen is loaded, all the previous textures are removed from memory, and the new ones are loaded in (with the exception of textures that are used by both).

This is the most simple way of managing assets. There are times however when this approach will make no sense - consider that the user finishes a level, and the game goes back to the level select screen, where the user then has the option to start the next level. OpenGL is told to throw away all of the textures used in gameplay when the game returns to the level select screen. Then, if the user clicks to start the next level, all these same textures, that existed in video memory only moments earlier, have to be reloaded from disk and sent to OpenGL. This is clearly not the best approach.

It is however important to ensure that unused textures are being discarded at some stage - otherwise we risk using up RAM unnecessarily, possibly forcing background apps to have to close, as well as increasing the frequency of garbage collections, etc. We would also risk hitting the limit on the number of textures that could be held by openGL if we did not throw away unused textures.

However, we do not need to be unloading these straight away. We could, for example, have a system that marks them as unused when they are no longer required, and then have some sort of count/timer built into each texture that unloads them at a later stage. This could be used to e.g.:

Unload textures after 3? minutes - this way if the user leaves a screen then returns to the previous one within 3 minutes, no textures will have to be recreated, which would be a common use case.

Unload textures after 2? new screens - ie. if transitioning from the game view to the main menu, this counts as 1 new screen. Don’t unload all the textures not in use at this stage, but instead unload these when the main menu transitions to a different screen, e.g. the credits screen. This way, returning to whichever screen was previous will result in textures still being intact.

Keep a fixed number of unused textures in memory (maybe 5?) - a fixed number of the most recently unused textures will be kept in memory. When another texture becomes unused, it will be added to the list, and the oldest texture currently in the list will be unloaded in its place if the list is at maximum capacity.

Keep a fixed amount of unused resolution in memory (maybe 2048x2048x2?) - similar to previously, but instead of keeping a fixed number of textures, a fixed amount of texture resolution is kept. This way, textures are treated according to the space they use in memory rather than being treated equally - for example, 4 1024x1024 textures use the same amount of memory as one 2048x2048 texture.

Such a system could also combine these methods into one hybrid method for texture management. For example, such a system could, theoretically:

List 1: Maintain a list of the two most recently unloaded textures indefinitely

List 2: Maintain a list of the two next most recently unloaded textures, where all the textures in the list have either been unloaded within the last 4 minutes, OR have been unloaded within the last 2 screens.

List 3: Maintain a list of the six next most recently unloaded textures, where all the textures in the list have both been unloaded within the last 2 minutes, AND have been unloaded within the last 2 screens, AND the total amount of unused resolution in memory (from lists 1 2 and 3 combined) is less than 2048x2048

The exact specifics of such a system would have to be set for each game individually, in order to minimise surplus reloading of textures, whilst also minimising unnecessarily storing unused textures in memory.

Having An Asset Manager That Intelligently Manages/Prioritises *Loading* Of Texture Assets

In addition to make such a texture manager intelligently manage unloading of unused assets, it would be beneficial to make it intelligently manage & prioritise loading.

There are likely to be situations whereby textures are required by a screen that are not required immediately, but instead are required after a period of time. Consider for example a situation whereby a level has a boss at the end of it, and the images for this boss are all on their own texture sheet. Loading this texture at the beginning would be nonsensical - doing so would potentially mean it was loaded in place of another one that was immediately required, slowing the loading process down. Instead, it would be much better to load all textures excluding the boss texture at reduced resolution & compressed, then load all textures excluding the boss texture at full resolution, then load the boss texture at full resolution.

Alternatively, consider Xargus - an animation plays at the beginning of each level for at least 5 seconds before any enemies are on screen. This animation involves the screen being zoomed in on the alien, so it would be desirable for full sized versions of the alien assets and background/hill assets to be used for this animation. Conversely, all the enemy assets, etc, would not be required until at least 10 seconds into the game, and these would be required at a lower resolution. It might make sense therefore to load the alien + hill assets in full resolution first.

In order to be able to do this, a system needs to be set up so that game screens can communicate to the asset manager the approximate time that each asset will be required, so that it can load the highest quality assets required as soon as possible, whilst also ensuring that all assets required later are loaded on time.

Having An Asset Manager That Supports Pre-Loading Of Assets That Are Not Currently Required

Another useful feature in an asset manager would be the ability to pre-load assets for use later. For example, assume the user is on the main menu screen, and level 4 is the highest level that is currently unlocked. Chances are, the user it quite likely to play level 4 next. Therefore, it would make sense for the game to pre-load versions of the assets required in order to play level 4. This way, if the user does go on to play level 4, loading times will be reduced; and if the user does not go on to play level 4, these assets can then be easily discarded.

A downside to this method is that it would involve using excess RAM + video memory loading textures that may never be used.

One potential method I could use to mitigate this downside is to, instead of loading the texture from file into an image in RAM (where it would be represented as a bitmap - i.e. uncompressed, 4 bytes per pixel) I could possibly load the file data into RAM, but keep the data intact in its .png format. If this .png was compressed, I would potentially save a lot of RAM versus storing it as a bitmap:

.png files generally use 50% of the filespace of .bmp files due to lossless compression

256-colour compressed .png files generally use 20-30% of the filespace of uncompressed .png files due to using 1 byte per pixel rather than 4

This means that compressed .png files require approx 10-15% of the space to store them compared to if they were uncompressed bitmap images.

By doing this, I would get all the expensive file I/O out of the way, and then if the images were required, I could convert them into bitmap images and send them to openGL. This would be the best of both worlds to some extent - I wouldn’t be using much excess RAM, and I would be preloading the images to improve seamlessness of loading. I am not entirely sure this is possible/easy to do on Android however.

Complex Texture Loading System - Individually Loading Each Image & Programatically Constructing Texture PART 2 - Double-Loading Textures

Previously in this blog post, I described how building a system that loaded images individually from file and then assembled them into a texture in RAM could benefit from filespace optimizations of a compressed 256 colour image, without a significant reduction in image quality (compared to compressing the entire texture file, which led to a noticeable reduction in image quality).

When using this method, there is potential to also use another trick to speed things up further.

Essentially, in addition than just creating one massive texture file in RAM, another texture file, half the x-size of the first, is created in RAM (i.e. as big as the left half of the texture). So, for example, assuming the entire texture file is 2000x2000 pixels, another image will be created in RAM that is 1000x2000 pixels.

Then, all the images that are on the left hand side of the texture are loaded first. When they have been loaded from file, they will be placed into both texture files in RAM. This will result in the second image in RAM essentially becoming a copy of the left hand side of the first one.

The advantage of doing this is that once the second image has been loaded (with approx 50% of the images), it can be sent to openGL to be used. This means that 50% of the images are available for use in 50% of the time, and then the full 100% are available in the full time:

Complex Texture Loading System - Individually Loading Each Image & Programatically Constructing Texture PART 3 - Using OpenGL To Assemble Texture Files

Extending even further on this technique, it may be possible to, instead of using Android Canvas/Graphics APIs to construct the texture image from component images in RAM, use OpenGL. This would come with a great deal of advantages.

Essentially, instead of using a two-thread setup whereby one thread loads images from file and another thread assembles these images into a texture, each new image can be added to an arraylist when loaded. Then, the openGL rendering thread can, at the beginning of drawing, test for any images in this arraylist, and for each image that exists:

Load the image into OpenGL as a new texture

Render from the newly loaded texture containing just the image into the full-sized texture

Destroy the image loaded into OpenGL as a new texture

This way, images become available for rendering as soon as they have been loaded from file, without having to wait for the entire texture to be loaded before openGL can use images from it:

This also means that loading of full-res versions of individual images can be prioritized, rather than just being able to prioritize textures. In real use cases, this would be very significant - consider Xargus for example. At the beginning of a level, the alien is on screen, the hippie van is on screen, and hills & clouds are on screen. All of these things are contained in different large texture files that contain many more images than just what is on screen, and these large texture files need to be fully loaded before that can be used. By using this method, it would be possible to load all the alien, hippie van and hill images first at full resolution, and use these images immediately without having to wait for unnecesary parts of the large texture images to load.

Having said that though, this is quite a complex thing to implement, and would possibly take about 2 weeks or something similar, so I am unlikely to be implementing it at this stage.

Conclusion / Which Methods I Am Likely To Implement In Xargus

I am likely to implement the following in Xargus / my game engine:

Implementing a way of handling variable-duration screen transitions used to mask loading times in my game engine

Implementing an asset manager in my game engine that can support delayed unloading, prioritised loading, and pre loading of assets

Also having the asset manager support initially loading compressed, low res versions of images

Intro / Recap

Previously, I came up with an algorithmic method for representing a level consisting as a series of alternating values a and b, where every value a represented the amount of enemy bullets fired, and every value b represented the amount of health restored.

I then explored calculating, from these values of a and b, the minimum percentage of bullets that the player would have to successfully dodge in order to pass the level.

However, the calculation of values a and b only worked where there was one simple gun with one shot per charge. In this post I will explore how to calculate values for any combination of guns.

I wrote a blog post a number of months previously that details a number of issues with calculating the difficulty of a gun. In doing so, this post outlined a number of issues and strategies related to complex weapons, that are strongly relevant to this blog post. The previous post is here:

Xargus - Weapons - Theoretically considering the relationship between Shots Per Charge vs Usefulness Of Weapon (controlling for shots per second equivalent)

It should be noted that in this post, it states that there are gaps between waves of enemies. These gaps have been significantly reduced since, and are now only about 0.2 seconds or similar.

Extending The Simulation Algorithm To Account For Multiple Shots Per Charge & Multiple Weapons

This would involve a rewrite of the algorithm, so that instead of looping through every enemy, choosing a target enemy, destroying it and then moving onto the next enemy, the algorithm would instead have to loop through periods of time - e.g. every 0.1 seconds, and adjust for the fact that this period of time had elapsed.

This would allow multiple shots per charge to be factored in to the simulation, as well as paving the way for multiple weapons:

Essentially, every iteration the simulation would have to run, and, simulating that 0.1 seconds had passed:

Simulate spawning new enemies if appropriate

Simulate every enemy on screen firing 0.1 seconds worth of bullets, Simulate both guns regenerating 0.1 seconds worth

Test if the currently selected weapon can fire another shot. If it can, select a target and do 1 damage to that target. If it can’t, and the non-selected weapon can, simulate switching to the other weapon (which involves every enemy on screen and both guns regenerating 0.3 seconds worth). If neither weapon can fire, skip this step

Loop again until no more enemies exist to be spawned

It would then be somewhat simple to build constraints into this simulation that imitate the way in which end users would behave, such as:

Potentially not allowing the player to shoot a bullet more than once every 0.1 seconds - in reality players cannot make decisions & perform actions instantly

Potentially making it so that 15?% of player bullets miss their target and go off screen - in reality not every bullet will successfully hit its target

Potentially making it so that a further 25?% of player bullets hit the wrong enemy - often enemies are very close together and bullets will therefore collide with an enemy which is not the target

Which would make the simulation give more realistic results

This simulation would then be run for every single combination of guns that would be available to the player for every level. This will obviously give multiple values of Z per level - one for every gun combo. All of these values will then be plotted on a graph. This will also give the advantage of allowing me to see if any guns / gun combos are overpowered.

Extending The Simulation To Account For Complex Weapons

Most of the weapons are ‘simple’ - they have two values:

Shots Per Charge - The number of shots the weapon can fire from a full charge

Recharge Time - The time it takes to fully recharge the weapon

Then, every bullet fired by a ‘simple’ weapon does 1 damage to the enemy it hits.

However, a number of weapons are more complex than this - they do not simply do 1 damage to 1 enemy. Currently there are 2 weapons in game which are ‘complex’. These are:

Freeze Gun - Freezes an enemy for a given amount of time. Frozen enemies cannot fire their guns

Poison Gun - Does 1 damage instantly, and then does 1 damage/second ongoing to the poisoned enemy until it dies

In addition to these, further ‘complex’ guns may be added into the game at a later stage.

The effects of these guns would need to be built into the simulation.

Also, these ‘complex’ guns would need to have their own formulas for which enemies to target. ‘Simple’ guns always target the enemy that fires the most bullets per second, which is the best way to minimise enemy bullets fired, but this is not necessarily the case for ‘complex’ guns.

Freeze Gun - Enemy Targeting Formula

Regarding the freeze gun, the following statements are roughly true:

Generally, it does not make sense to target an enemy which is already frozen (potentially unless that enemy is about to be unfrozen) (if an enemy is already frozen, the time it is frozen for goes back up to the time it would be frozen for otherwise, discarding any remaining freeze time)

Generally, it does not make sense to target an enemy which has very low health, because it will die while still frozen and the freeze effect will have been wasted

Generally, it makes sense to target enemies which emit more bullets per second

I think, based on these, it would be best to compute the following formula for every enemy on screen, and then select the enemy to target with the highest result:

Minimum(Enemy Health / Other Gun Bullets Per Second Average, Total Freeze Time) * (Enemy bullets per second) * (Total Freeze Time - Enemy Freeze Time Remaining)

An explanation of this formula is:

Enemy Health / Other Gun Bullets Per Second Average - This evaluates to the amount of time the enemy will be alive for if it is shot at consistently by the other gun

Minimum(Enemy Health / Other Gun Bullets Per Second Average, Total Freeze Time) - This is the previous bullet point (the amount of time the enemy will be alive for), capped at the time the enemy would be frozen for.

Minimum(Enemy Health / Other Gun Bullets Per Second Average, Total Freeze Time) * (Enemy bullets per second) - This evaluates to the amount of bullets the enemy would be able to shoot in the amount of time it would be frozen & alive for

Then, finally, multiplying the previous bullet point by (Total Freeze Time - Enemy Freeze Time Remaining) accounts for the fact that the enemy might already be frozen for a period of time

Essentially, all together, this formula will evaluate to the number of enemy bullets that will be prevented from being fired by freezing the enemy.

Poison Gun - Enemy Targeting Formula

The targeting formula for this gun is significantly more simple:

Enemy Bullets Per Second * Enemy Health

In addition, it should not target any enemies that have already been poisoned. If all on-screen enemies have already been poisoned, it should not make another shot, and instead save its bullets for poisoning the next enemy that comes on screen.

Foresight, And How The Simulation Fails To Account For This

Real life players, when playing the game, will likely perform several attempts at a level before successfully completing it. Because levels are hard-coded/fixed, and do not contain random variation, this will mean that the player will have knowledge of what enemy waves are coming up next, and will potentially plan their strategy accordingly.

Examples of how a player may do this include:

Not attacking any enemies when there is one weak enemy on the screen at the end of a wave, in order to allow both guns to fully recharge so that the guns are at full charge for the next wave, containing more powerful enemies

If a high powered enemy is coming up soon, saving use of the secondary weapon in order to be able to quickly wipe that enemy out

And similar situations. The key point to this strategy is that the player withholds firing shots because they know their shots will be more effective if they save them for use a short while later.

It would likely be somewhat difficult to program all types of foresight into the simulation, because it would involve constantly scanning future enemies and waves to predict what was coming next, and calculating the number of bullets fired in each situation, etc; which would be really complex.

It would be possible, however, to code the most basic type of foresight into the simulation: Not firing at enemies if it the end of a wave and there is only 1 enemy on screen, and the enemies in the next wave are more powerful than the 1 on screen. This wouldn’t involve complex future-prediction algorithms, and would potentially result in the simulation adopting a better playstyle.

Multiple Attack Strategy Simulations

Building this foresight strategy into the simulation raises the key question, however, of whether all players are going to adopt such a strategy in-game. It is quite intuitive to me that such a strategy would exist, but this may not be apparent to the typical player.

Similarly, the simulation assumes that the player always targets the most powerful enemy, and always changes between primary and secondary weapons when appropriate. Typical real life players may not do this however.

It may therefore be a good idea to build multiple versions of the attack strategy, such as mediocre, good and excellent, and simulate, calculate Z, and plot all 3 of these attack strategies for each data point.

Examples of how the strategies would differ could be:

Excellent Simulation - Basic foresight, Small delays between changing guns/attacking, Always targets enemies most effectively

Good Simulation - No foresight, Medium-Small delays between changing guns/attacking, Targets enemies most effectively

Mediocre Simulation - No foresight, Medium delays between changing guns/attacking, Higher percentage of attacks miss, Targets enemies in first-in-first-out order

Bearing in mind I already plan to plot every single combination of weapons for every given level, this will result in potentially (9 Weapons) * (9-1 Weapons) * (3 Simulation Difficulties) = 216 different simulations being run for every single level… which is somewhat ridiculous (although not all 9 weapons will be unlocked for every single level, bringing this number down)

Intro / Recap

Firstly, a brief summary of part 1: In part 1, I described an algorithm that I could use in order to calculate an approximation for the number of enemy bullets fired in any given level, assuming the player adopted a given attack/offense strategy. From this value, I went on to describe how to calculate an approximation for the minimum percentage of bullets that the player would successfully have to dodge in order to pass the level without dying. 

This, however, did not work for levels that include donuts and cola.

In this part, I will discuss how it would be possible to extend this in order to calculate the minimum percentage of bullets that the player would successfully have to dodge in order to pass the level without dying, for levels that include donut and cola machines placed throughout them.

Key Difficulties With Calculating Approximate Relative Difficulty Of Levels Containing Donuts & Cola

Essentially, the simulation method for calculating the total number of enemy shots fired returns a value that is, by definition, a measure of the number of enemy shots fired.

This value needs to be multiplied by (1 - (the percentage of successfully dodged bullets)) in order to determine how much health the player loses.

When this simulation encounters that a donut/cola machine has been spawned, it can target it instead of attacking the strongest enemy. However, when the machine is destroyed, and the alien eats the donut, the player is given a fixed amount of health back, up to the maximum amount of health. 

This value is not in the same units as the value of the enemy shots fired, which is where the difficulty arises.

I have come up with a way to model this mathematically, and it is as follows:

Model For Representing a Level Containing Enemies, Donuts & Cola

Essentially, the simulation can be set to run until it encounters a donut to eat. It can then store the calculated value of the total number of enemy bullets fired in a list, and store the amount of health replenished by the donut(s) in another list.

The simulation would then continue calculating the total number of enemy bullets fired from the last donut consumed. When another donut is ‘eaten’ in the simulation, it will again store this value in a list, store the health replenished in another list, and continue calculating enemy bullets from the last donut consumed, and so on.

After the simulation has run, it will consist of two lists of values:

List a - a set of values for the average amount of enemy bullets fired.

List b - a set of values for the amount of health regained. The size of this list will be 1 less than the size of list a.

We will then let Z equal the percentage of bullets that collide with the player

We can then construct a mathematical problem to determine the value of Z.

H[max] is defined as the maximum/initial health of the player. 

H[n] will represent every calculation step that we will perform in order to calculate the updated value of H, where n is every integer in the range [0 -> a.size - 1]

Then:

We want the value of Z such that the smallest value of H[n] is equal to 0. Because, by definition, every value of a is greater than 0, and every value of b is greater than 0, we can be sure that such a value for Z exists, and that only one such value for Z exists.

Visually, this will look as follows:

In common sense terms, an explanation of this is:

A certain number of bullets are fired, represented by a[0]. This value multiplied by Z (the average percentage of bullets that hit the player) represents the amount of health the player loses. If the player’s health goes below 0 then the player loses the game.

Then, a fixed amount of health is given back to the player, represented by b[0]. If the amount of health the player has after this is greater than H,[max] then the player’s health is capped at H[max].

This is then repeated for all values of a and b.

We are then trying to calculate the value for Z such that the player will be on the verge of losing the game - the player’s health will drop to exactly 0. This will represent the limit for the percentage of bullets that must hit the player for the player to lose, any less than this, and the player will successfully pass the level. This value will then be calculated for every level in order to work out the relative difficulty of the level.

If we had 3 values for a (and therefore 2 values for b), the formula would look like:

H[0] = H[max] - Z*a[0]

H[1] = minimum( H[0] + b[0] , H[max] ) - Z*a[1]

= minimum( H[max] - Z*a[0] + b[0] , H[max] ) - Z*a[1]

H[2] = minimum( H[1] + b[1] , H[max] ) - Z*a[2]

= minimum( minimum( H[max] - Z*a[0] + b[0] , H[max] ) - Z*a[1] + b[1] , H[max] ) - Z*a[2]

and then we would need to find the value of Z such that:

0 = minimum( H[0] , H[1] , H[2] )

Calculating Z Such That The Minimum Value of H[n] Is Equal To 0

I am a programmer, not a pure mathematician, and I have no experience of mathematics beyond single A Level Maths. 

Therefore, I consulted a few mathematician friends of mine regarding this problem, to discuss methods for computing a value for Z. My understanding is that it would be possible to compute this value exactly, however it would be simpler, given the knowledge I have, to programatically use a trial and error method to find a value for Z, especially considering:

I only need this value to 4 or 5 base 10 significant figures 

The code for computing this value would not be production code. Therefore it is preferable to favour ease of implementation heavily over computation speed/efficiency. 

Intro & Background - Difficulty Curves

Designing levels for the game, I wanted to equip myself with as many tools as possible in order to ensure I have a desirable difficulty curve.

I have written a few blog posts related to this before, and to summarise from them: in most games there should be a difficulty curve that matches a particular shape. It should get progressively more difficult over time, but it should not be a straight line - it should fluctuate, getting easy and then hard again, in order to get players engaged, and look somewhat like this:

There is an extra credits episode that goes into the use & effectiveness of this type of curve in more detail at https://youtu.be/5LScL4CWe5E

Visualising the current difficulty curve, as well as manipulating the difficulty curve, becomes a lot easier if it is possible to algorithmically quantify the difficulty of any given level.

Calculating the Difficulty of a Single Given Enemy

Each enemy has a known health, as well as 1 or 2 guns that each fire a number of bullets after a given repeating time period. Each bullet is currently the same, and does 1 damage if it hits the alien. Separating these variables, we have:

Enemy Health

Gun 1 Bullets Per Charge

Gun 1 Recharge Period

Gun 2 Bullets Per Charge

Gun 2 Recharge Period

The best way to calculate the difficulty of the enemy from these values is using the formula:

The resulting value will then have the units Health * Bullets / Second, and will be equal to the average number of bullets being fired by the enemy per second, multiplied by the enemies health.

This intuitively makes sense - to begin with, consider an enemy with 1 health, that fires 1 bullet per second. This would have a calculated relative difficulty of 1*(1/1) = 1 according to the formula.

Next, consider an enemy that has double the health of the first one - 2 health, and still fires 1 bullet per second. This enemy would have a calculated relative difficulty of 2*(1/1) = 2 according to the formula. This makes sense in practical terms - the enemy would take twice as long to kill, and in that time would be able to fire twice as many bullets.

Now, consider an enemy that has half the recharge rate of the first one, meaning it would fire twice as many bullets per second, and has 1 health. This enemy would have a calculated relative difficulty of 1*(1/0.5) = 2 according to the formula. This, again, makes sense in practical terms - the enemy would take the same amount of time to kill, but would be able to fire twice as many bullets in that time.

Issues Calculating the Difficulty of a Stage/Wave of Enemies - Why It Isn’t as Simple as Adding Enemy Difficulties Together

So far, so good. However, when calculating the difficulty of an entire stage, it is not as simple as just adding the difficulties of all of the enemies together however; there are a number of other factors to take into consideration, most notably the number of enemies to have on screen at any time.

The way stages work is that there is a list of the enemies contained in that stage, and there is also a number of enemies that should be spawned at once. When an enemy is killed, another is spawned from that list, until there are no more remaining in the list, and then the game progresses onto the next stage.

To see why it is not as simple as just adding the difficulty of every enemy together, consider if there were a stage consisting of 10 enemies of difficulty 1, whereby 1 enemy was on screen at any given time. The difficulty of that stage could be said to be 10.

Now consider if there were a stage consisting of 10 enemies of difficulty 1, like before, but now 2 enemies are spawned on screen at any given time. The player would be taking roughly twice as much damage, because the player would still have to kill 10 enemies, except there would be 2 enemies shooting at the player at any given time, meaning the difficulty would be roughly twice what the previous stage would be.

A Slightly Better Solution - Multiplying the Sum Total of Enemies’ Difficulties by the Number of Enemies Spawned at Once

Multiplying the number of enemies spawned at once by the sum total of the enemies difficulties for each stage would therefore seem to be the intuitive fix for the problem.

However, this might not always be the case. Consider, for example, if there were 10 enemies of difficulty 1, and all 10 were to be spawned on the screen at once. At the beginning, all 10 would be firing at the player. However, after the first one was killed, there would be only 9 on screen, and after another was killed, there would be 8, etc. 

Also, there might be a mix of different difficulties of enemies in there - some might have relative difficulty of 2, some might have difficulty of 1. The player is likely to destroy the most powerful enemies first (this is the best strategy, and is quite an intuitive/easy to discover strategy), so the more difficult ones are going to be on screen for less time.

Therefore, we need a more complex way of working out the relative difficulty of a Stage/Level:

Simulating Playthrough of a Level, Assuming a Strategy Whereby the Player Destroys the Most Powerful Enemies First

I therefore decided to go with a procedural method for quantifying the estimated relative difficulty of levels/stages, simulating a playthrough of the level.

This simulation will work as follows:

Firstly, enemies will be added to the currently on screen enemies until the number of enemies on screen equals the number to be spawned

Then, the following steps will be applied iteratively until there are no more enemies to be added:

The on screen enemy with the greatest bullets per second average will be selected as the ‘Target Enemy’ (ie the one that the player would be firing at)

Add the health of the target enemy multiplied by the bullets per second of each enemy (including the target enemy) to the total score. (this represents all of the bullets that would be fired while the target is being killed)

Remove the target enemy from the list of on screen enemies. It is dead.

Add another enemy, if one exists, from the list of enemies to be spawned

Repeat

This should result in a value for the relative difficulty of a stage. The units of this value are Enemy Health * Bullets / Seconds

Accounting For Powerfulness Of Guns

There, is however, another important factor in working out relative difficulty - the powerfulness of the gun that the player has for any given level. In higher levels, the gun will be more powerful.

The powerfulness of simple guns is measured in Enemy Health / Seconds - a value representing the amount of damage that can be done to enemies per time (some guns don’t have a linear powerfulness, as how powerful they are is dependent on other factors - e.g. the freeze gun)

Therefore, the relative difficulty of a level should be divided by the total powerfulness value of the two most powerful guns that can be brought into any level to calculate the actual adjusted difficulty.

The units after this calculation will be:

(Enemy Health * Bullets / Seconds) / (Enemy Health / Seconds) = Bullets

This value will represent the approximate total number of enemy bullets that the enemies will be able to fire per game.

Multiplying this value by the percentage of bullets that the player dodges successfully will get the total damage incurred by the alien at game end. If this is greater than the health of the alien, the player will obviously not pass the level.

Therefore, it would be possible to calculate the percentage of bullets the player would successfully dodge in order to pass the level, for any given level. This is likely to be the most accurate measure of difficulty that is possible to calculate.

I’ve done a bunch more work adding functional donuts and cola into the game.

The way these will work is that donut/cola machines will be spawned in a similar way to the way in which enemies will be spawned, and must be shot twice in order to break them. Upon breaking, they will explode, and a donut/cola drink will go flying towards the alien, which the alien will drink, gaining health. Strategic placing of these will be important for effective level design.

I created animations for these ages ago, which I’ve since tidied up a little, and now look as follows (Cola):

(Donut):

I’ve implemented tiles into the game for village and wilderness/grassland. 

Village

The village tiles use the following detail images on a grey background

And the following far/hill detail images, in addition to trees and bushes, on a field/grassy hill

All together, this looks as follows:

I’m reasonably pleased with the way the village tiles ended up looking. They’re not perfect, but it took me quite a while to create all the village assets, especially the huts, so they’ll have to do. 

Wilderness / Grassland

I’ve also added wilderness/grassland tiles in game. These use the same detail images to the grass tiles, but with more rocks and no flowers, and the following far detail images:

In game, this looks like:

Which, again, looks alright. I may play with the colour scheme for this a bit. Creating the wilderness, it was nice to not have to create that many unique assets, as lots of them were reused from previous tiles. Hopefully, the more different environments I add to the game, the more assets I am likely to be able to reuse creating each new environment.

Environment Order Thoughts/Plans

I now plan to have things progress in the following way:

Farm Levels (Farmers + Police)

Village Levels (Police)

Forest Levels (Police + Military)

Wasteland Levels / Military Base (Military)

Swamp Levels (Swamp Trolls)

Mountain Levels / Troll Cave (Mountain Trolls)

City Levels / Airport (Police, Military, Elite Police)

Sea Levels (Police + Military -> Pirates -> Egyptian Military)

Egypt Overground Levels (Egyptian Military)

Pyramid Levels (Mummies, Skeletons, Giant Spiders, Alien Slime)

Wormhole Levels (Debris, Creatures of the Void)

Outer Space Levels (Asteroids, Alien Ships)

Mothership Levels (Alien Slime, Environmental Dangers)

Outer Space Levels (Asteroids, Alien Ships)

Enemy Mothership Levels (Alien Slime, Environmental Dangers)

Which I’ll admit does seem somewhat optimistic and large in scope considering the time it has taken to create what I have currently. 

Implementing most of the above, however, will require assets + animations only, rather than more code, which will make things easier. However, the following will involve code/game mechanic alterations:

I plan to have the objective for the last city level involving stealing an aeroplane from the airport, which will then be piloted by the hippy. The sea levels will therefore involve the alien using a plane-mounted machinegun to attack enemies, and the player will have no control over the planes location in space (as the hippy will be controlling it). This will hopefully mix things up a bit in terms of gameplay, which should be good.

For the last 5 bullet points above (all the ones not on earth), I plan to change things up quite a lot in terms of enemies. I haven’t decided exactly how yet.

For the pyramid levels (and possibly also for the military base levels, and the troll cave levels) I am interested in changing the mechanic of the game completely, and ditching the aliens trolley - possibly bringing in basic platforming/action or platforming/puzzle/stealth elements, or a new vehicle that handles in some fundamentally different way.

Implementing another game mechanic for a subset of the levels in this way would possibly involve a lot of work, but it would be a way of significantly increasing the functional variety of the game

Also, lots of console games seem to have varied mechanics in this sort of way. For example, in Simpsons Hit and Run, the majority of the game missions involve some variation of the driving mechanic, but there are out-of-vehicle platforming levels/elements to it. Similarly, in most of the Jak and Daxter games, the majority of missions involve platforming/fighting, but a number of them involve driving/racing various vehicles.

I haven’t posted in over a week, which has resulted in me having a lot to write about, so I am probably going to be posting quite a few blog posts in succession in order to catch up with stuff I’ve been doing.

Tile Transitions - Intro

The most notable thing I’ve done is finally got round to implementing xml-defined tile transitions; which I’ve managed to implement in a really elegant way such that transitions will automatically be added in when parsing the levels. 

Implementing xml-defined levels, I’ve been very cautious about trying to reduce the amount of unnecessary/superfluous data, so that the levels themselves can be written as elegantly and intuitively/simply as possible in xml. Level design and balancing requires a lot of messing about with adding, reordering and removing enemies, stages and levels, and the more superfluous data that exists mixed in with the important data, the more cumbersome this process will become.

XML Definitions - Recap

Firstly, a quick recap of how xml defined levels work currently:

In the xml file, detail descriptions are defined first. Each detail description consists of a name, and a series of images + corresponding weighted probabilities.

Then, tile descriptions are defined first. Each tile description consists of a name, a type, a series of background colours + corresponding weighted chances, a series of foreground colours + corresponding weighted chances, a series of background images + corresponding weighted chances, and a series of detail descriptions + corresponding weighted chances.

Levels + Stages are then defined, referencing the tiles described earlier by name, and referencing enemies by name. Enemies are defined elsewhere in code/are not defined in the xml file:

Tile Transitions - XML Definitions

As mentioned previously, each tile is defined as having a type. For example, field and forest tiles are both defined as having the type “grass”, village tiles are defined as having the type “stone”.

Tiles of the same type will automatically be transitioned between with a transition tile that takes the background and foreground colours of the previous tile, and gradiates them to the background and foreground colours of the new tile.

Transitions of different tile types are then defined in xml, to be referenced by the two types of tile that the transition is between:

The tiletransition xml element will then contain multiple drawtile xml elements. Each of these specifies that a tile should be drawn of the next tile (if parameter name=“next”), or the previous tile (name=“prev”). Then, if a bgimagefilename is specified, this will be drawn in place of the background image that would otherwise be drawn for that tile. I will explain what detailmask means later.

The tiletransition described above will look as follows when transitioning from village to field:

In order to draw this, the first drawtile child element would be rendered, of the previous type (which is the village tile). 

Then, the next drawtile child element would be rendered, which is the field tile. Because a bgimagefilename has been defined, it will be rendered with that background image rather than the default one. The bgimagefilename specified looks like this:

Because tile transitions are defined in xml using the tile type, as opposed to the tile name, and then use the “prev” and “next” keywords to refer to the names of each tile, unnecessary definitions do not need to be made. For example, this definition will correctly provide transitions for village->forest, village->field, village->cornfield, etc, without additional xml definitions being required.

Detail Bitmask

The detailmask parameter refers to which detail images should be drawn on the tile. It is a binary number, where each binary bit represents whether a certain detail image should be drawn (1) or not (0).

Each tile has 6 detail images arranged in this pattern:

Then, the bits that represent whether each detail image should be drawn are:

When bitmasks are stored this way, it is really easy to perform bitwise operations like AND, OR and XOR to manipulate them with other bitmasks, which needs to be done to a minor extent in my use case.

It is also very easy to test whether a given number contains a certain bit - you just perform a bitwise AND operation using operands of the number to test and the number represented by the bit, and then test if the result is greater than 0.

For example, the following will evaluate to equal whether the variable detailbitmask contains the bit 32:

detailbitmask & 32 > 0

Instance + Class Representation of Tile Transitions

Now to recall, as described in previous blog posts, each type of tile has its own instance of a class called TileDescription, and this instance is referenced in stages as required. This removes the need for any kind of tile-related garbage collection taking place during a game.

In order to implement transition tiles, I needed to be able to store them as a class extending TileDescription, in a way that, similar to the way in which instances of TileDescription are currently handled, prevents TileDescription-related garbage collection in game.

Because each tile transition in xml is defined on a per-type basis instead of a per-name basis, each definition of tile transition could potentially be used for any number of different transitions, e.g. type:grass->type:stone could represent name:field->name:village, name:forest->name:village, name:field->name:mountains. This makes handling tile transitions more complex than tile descriptions.

In order to solve this, first I created a TileTransition class that stores all the info defined in a <tiletransition> xml element. This class does NOT extend TileDescription. An instance of each TileTransition is then created and stored in a map, where the key is both type strings concatenated together with a separator string.

Then, I have two more classes, ComplexTileTransitionTileDescription and SimpleTileTransitionTileDescription, which both extend TileDescription. 

SimpleTileTransitionTileDescription instances are instantiated with inputs of the previous TileDescription and the next TileDescription. Instances of this represent a tile that is a transition between two tiles of the same type (e.g. forest -> field).

ComplexTileTransitionTileDescription instances are instantiated with inputs of the previous+next TileDescriptions, and an instance of TileTransition. Instances of this represent a tile that is a transition between two tiles of different types, as defined by a <tiletransition> xml element.

Then, when stages are being added to the levels during parsing of the xml data, a new instance of either SimpleTileTransitionTileDescription or ComplexTileTransitionTileDescription is created + added in every place where it is required.

I’ve added rendering code + xml properties to support optionally drawing additional images along the top of the tiles that sway backwards and forwards, in order to implement corn.

Every image has a different, randomly varying, sway duration & offset. The resulting effect looks as follows:

As a trial, I also created foxglove images, and added them sparingly into the forest tiles:

I’ve created new graphics for the forest detail images to work with the new-style backgrounds.

The forest tiles will share a lot of the detail images with the field tiles, but without the daisies + buttercups. In addition, the forest tiles will have branches + mushroom detail images to give a more forest-y feel. I also decided, after looking at pictures of various forests on google images, to add in purple flowers.

I’ve also created pine tree detail images for the far background:

Certain detail images seem to stand out much more than others, for example the log detail image in the above screenshot - lots of the detail images are repeated in this screenshot, but only the log image stands out as looking ‘weird’.

I’ve annotated this screenshot to show the repetition of one of the rock detail images in blue, which does not stand out as being noticeable in any way, compared to the log in red:

The fact that the log image stands out like this is mildly problematic, in that it breaks the ‘seamlessness’ of the scene to an extent, and it would be ideal if I could prevent this.

One thing I could do to improve the variety of the detail images is to make them recolourable. By redesigning them + drawing them with a shader that allows their colours to be manually changed, all of their colours could be randomly varied. Combining this with applying a slight random rotation+scale to the image, and the same image could look different every time:

This obviously wouldn’t solve the problem entirely though (and it would involve quite a bit of work). I think the only way to completely solve this issue is to ensure that none of the detail images stand out from all the others in a noticeable way.

I believe the reason that the repetition of the stone image (circled in blue above) is not noticeable because there are 4 other types of stone images, so the user doesn’t notice that some of them are the same, because there is variety in the stones that are on screen. If there was only one type of stone image, I believe this would stand out as looking strange and unvaried.

I’ve made significant progress in rendering dynamic/randomly varying background hills. They now look like this in game, which I am very pleased with:

Tree Detail Images:

I created a set of 5 tree images and 2 bush images to use for drawing on the hills, shown here:

I tried to ensure there was more variation in the tree shapes + sizes than in the previous trees used on the old background.

Shaders + Colours:

All of the rendering of the hills is done with a shader that takes the background colour for each vertex, and the foreground colour for each vertex, and then slight random variation can be applied to these colours in the HSV colour space, in the same way as is done for the ground tiles.

The hill shader also takes a tint colour, which is used to tint the result towards a given colour. This colour is set to white with a given transparency, which gives the impression of the hill being far away/foggy. The trees are also drawn with a tint shader.

Previously, the hill image was simply drawn transparent in order to get the faded out effect. The reason I did not simply use this method is because I am now rendering the trees separately to the hill, so rendering all of this transparent would result in visually undesirable areas where the trees overlap the hills.

Calculating Positions of Trees:

I did not want trees to be randomly scattered all over the hill, I wanted them to be roughly arranged into clusters. I also had to ensure when rendering that all the higher up trees were rendered first, so that the lower down ones would be rendered over them.

My rendering code draws a ‘cluster’ of trees every predetermined amount on the background. Every first cluster drawn is drawn at the top of the hill line, and every second cluster drawn is drawn a bit below the hill line, shown here by the red and blue arrows:

Then, for each cluster, the computer chooses to draw either 1 or 2 rows of trees. If the cluster is below the hill line (ie every second cluster - marked with blue arrows in the above image), it always chooses to draw 1 row of trees; otherwise (red arrows in above image) it randomly chooses 1 or 2.

Then, for each row:

If 1 row of trees is being drawn, the computer draws 1 or 3 trees per row

If 2 rows of trees are being drawn, the computer draws 3 or 5 trees per row (the number of trees per row is recalculated for every row, so for example it is possible to have one row with 3 trees and the next row with 5)

The rows follow the equation of the hill lines, so that the trees curve in similar ways to the hill. All the trees are drawn with slight random variation added to their X, Y positions, and have their images randomly chosen.

Each tree also has a rotation. In order to calculate this rotation, first I calculate the gradient of the hill curve, convert this into an angle, and multiply this angle by 0.25 (so that the tree slightly bends towards the direction of the hill, but remains fairly upright). Some random variation is also added to this angle per tree.

This all results in really nice looking, varied tree/hill backgrounds. One thing I find really cool is that in some places, a few random choices can lead to hardly any trees being drawn per cluster, and really empty fields; and in some places loads of trees per cluster, and really crowded fields.

Parallax

The backgrounds work correctly with parallax in both the x and y directions, as shown in this gif:

(this .gif file has been reduced to 10fps + compressed in order to get it under the tumblr gif limit of 2mb)

Immediate Next Steps

Most of the work I have done has involved setting values manually in code to get the trees to look nice. Ideally these values would be stored as parameters which can be set in the xml, so that they can be changed each level.

It would be ideal to be able to change the following properties in the xml:

The amount of trees on screen

The amount the hill is faded white + The colour the hill is faded (so e.g. in a nighttime level it can be faded towards black instead)

The curve equations of the hills

Adding in more than one set of hills, and having the second set have different parallax properties

I should also add in different types of detail image that aren’t trees - grass and shadows etc - to the hills

I would also like to experiment with having trees animated / swaying slightly in the wind, and similarly, having some flowers on the ground tiles that sway slightly backwards and forwards in the wind

Mid/Long Term Next Step - Game Engine Extensions

My game engine was designed to be able to do simple things easily. For example, there is a method that draws an image, given an image, and a set of coordinates. The game engine then hides all the additional work that needs to be done in order to draw this: Caching the draw commands; Creating vertex buffers, UV buffers + Index buffers; Managing + Communicating with the appropriate shaders; etc.

In order to draw the background tiles with a custom shader, I’ve just added in additional bespoke methods into core parts of the game engine that do specific things - e.g. there is a method that draws a parallelogram using a shader that takes two colour inputs per vertex - which is used to draw the hills.

The reason I’ve just added these methods straight into the game engine is because my game engine abstracts away all the shaders, caches, etc from the game itself, and handles all these things internally. This is bad programming practice however.

Ideally, I would create a way that my game engine could handle custom shaders that games define themselves, as well as handling the drawing of custom quads with custom shaders, etc. 

All of this is quite complicated to implement however, and will require me spending quite a bit of time thinking about the most intuitive way to go about doing all this.

Mid/Long Term Next Step - Profiling + Performance

Currently the game renders at approximately 40fps. This is a perfectly acceptable fps for the game, however there is some worry that the fps will be lower than this on other devices. 

At some stage it would be sensible to run profiling on everything that’s been implemented, make sure it all runs correctly, and time every major method/action, to find out exactly which methods are consuming the most cpu power.

I would also like to spend a few days/weeks performing GPU profiling on a whole set of GLSL shaders, trying out different methods of optimizing the shaders I currently have. There are several different ways of doing a lot of things, such as different ways of storing and transmitting per-vertex colour data, and it would be beneficial to profile all of these different methods to find the most efficient, etc.

I’ve been working on background tiles some more, and have altered them so that they now shift between colours that randomly vary very slightly, so that the grass is not the exact same colours all the way through.

It’s a somewhat subtle effect, which is visible to an extent in the following gif, but it’s more noticeable on the device itself:

In order to create realistic colour variation in the grass, I simply took the default colour, converted it to a HSV (Hue Saturation Value) colour, and then changed the hue and saturation by small amounts, before converting it back to rgb.

The site http://www.w3schools.com/colors/colors_picker.asp shows what colours look like when their HSV values are modified slightly, and the following screenshots, taken from that site, show this for the grass colour:

Hue:

Saturation:

Thus you can understand how modifying the colours slightly in the HSV colour space rather than the RGB one leads to natural-looking, context appropriate colour variations.

When the colours have been chosen, I have a shader that takes per-vertex color data and interpolates between them, and then colourizes the tile images to those colours, which is used to draw the tiles with smoothly changing colours.

Dynamic Far Background / Hill

I would also like to be able to dynamically render the far background (the hills with the trees on them) dynamically/psuedorandomly, and have made progress in implementing this.

The backgrounds I have at the moment are fine, but they took so long to make, and I only have two of them so far - the field one and the forest one. If I remember correctly, making each of these took 6 hours each in photoshop just positioning all the trees so that they looked right, dealing with photoshop acting laggy because the file was so big, etc. I don’t particularly fancy spending another 6 hours every time I want to create a new background.

Another issue with the current hill backgrounds is that they use a whole load of file space - they’re massive. Each one is approximately 1200x400 pixels big, which has the potential to add up to a lot considering I may want to store possibly 10 of these in the finished game. These large images also need to be stored in texture memory on the video card, which isn’t great.

I had planned to reuse the backgrounds between levels - e.g. the grass field hill background could be used for the first few levels, the forest hill background could be used for a few, etc. This sharing of the background asset is fine, but not totally desirable - it would be better if the background asset varied slightly between levels in some noticeable way.

Generating these background dynamically will solve all these problems, and more.

Hill Drawing - Drawing an Image Stretched into a Curve

I wanted to be able to draw the far background from a mathematically defined curve, so that it would be easy to modify the size+shape of it, as well as vary the size and shape of it between levels.

I created code that can do this, that I will use for drawing the backgrounds. - essentially it stretches the image into a given mathematical curve. Here is a demo image of the basic principle working, drawing the grass tile image:

The way it does this is by slicing the tile image up into a number of sections, and then drawing each section as parallelograms, with the coordinates of the parallelograms determined by the mathematical function. Each parallelogram is then rendered in a similar way to how a rectangle would be rendered:

Because the top of the grass image is spikey, it is not visible that the curve has been constructed from a series of parallelograms, it just looks like a smooth curve.

The curves used for the hills can then be constructed by adding a few sine waves together, to create natural looking hills.

For example, by adding the following sin curves together:

The following curve is achieved - natural looking hills of varying sizes:

(equation of shown curve is y= sin(x) + 0.4*sin(0.4*x) ) (image created at graphsketch.com )

Different curves can also be achieved by slightly modifying the values used, maintaining the same principle. For example, I created the following funky looking curve by messing about adding a bunch of sine curves together, which could be used for mountains or similar:

Potentially I could also create multiple hillscapes in the background, with some being more faded out+scrolling less with parallax, to create really layered backgrounds.

Looking at a few other games, and game animation blogs, etc, one thing I noticed was that the vast majority of in game characters/enemies in other games have idle animations that play while not moving; animations such as the creature breathing in and out, rocking backwards and forwards, etc. 

These idle animations in other games seem to go some way towards making the game feel more real and immersive, and so I decided to implement a very basic idle animation on the alien for now:

Most idle animations in games seem to be reasonably similar to this one - most of the bones moving small angles quite slowly, in a way that makes the character feel like a real, living being rather than a static image on a screen. I will probably play around some more with this animation in the future.

Also, as is visible above, I’ve also added buttercups into the grass

Enemy Idle Animations + Required Animation Engine Changes

I may also play around adding basic idle animations to a few enemies in game, such as vehicles etc. 

There are however a few core existing limitations with my animation engine that may require adjustments of changes in order to fully support idle animations in some cases.

Essentially, my animation engine *can* support multiple animations running on the same skeleton at the same time, and this is required for a lot of the existing animations to take place, such as a shooting gun animation to be played at the same time as an eating a burger animation, at the same time as a blink animation, etc.

However, my animation engine *cannot* currently support multiple animations on the same properties of the same bones at the same time, doing so produces visually strange results. The alien shooting gun animation is specifically designed to use different bones to the alien eating burger animation, so that these can run at the same time, for example.

This can lead to problems implemented certain types of idle animation. For example, implementing an idle animation for cows, it would be desirable to have all the legs bending slightly, the torso rotating slightly, the head rotating slightly. Implementing the cow walk animation, a lot of the same bones would need to be animated. 

This would be likely to cause issues when transitioning from the cow being idle to the cow walking or vice versa - one animation would start while another was half way through playing, and this would cause result in an overall movement that was strange and undesirable.

An alternative method would be to stop all existing animations, and then play the new animation, but this would potentially cause issues if, say, the idle animation caused the torso to rotate very slightly, and the walk animation didn’t - stopping the idle animation half way through would leave the torso rotated, and this would remain this way as the walk animation would not be animating this property.

The desirable solution, which I should implement, is having the ability to make all animations currently playing smoothly come to a stop (ie animate from their current position directly to the last data point in the animation) over a small period of time. This can then be done in situations similar to this one, and the new animation can start playing over the top straight away, leaving all old properties to quickly animate to their correct/neutral states.