#xargus

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. 

I’ve been making a number of changes, tidying up code to remove redundancies and simplify repetitive tasks, etc.

Animation Engine - Multiple Bone Names per BoneAnimation

The first change I’ve made is that I’ve allowed multiple bone names to be passed in a single string when creating a BoneAnimation. For example, setting the angle of bones called “arm” and “arm2″ could be done by simply passing the string “arm arm2″ when creating the BoneAnimation.

Also, these don’t have to be existing bones - if a bone is passed that doesn’t exist, the animation engine will now not crash, but simply will ignore that bone. For example, if “arm arm2″ was passed, and arm2 didn’t exist, it would simply run the animation on arm only.

Applications of this Change

This has enabled me to simplify the code for poisoning and freezing enemies significantly.

Previously, freezing an enemy would work as follows: Freeze() would be called on the enemy. The vehicle class would then run the freeze animation (tinting the  human blue), and then check if a second human existed, and if it did, create and run an animation tinting that human blue. 

Every different enemy type would have had to have run code similar to this to apply a freeze animation to the relevant bones.

Now, however, each enemy has a string containing a space seperated list of bone names to tint in the event of a freeze. For the vehicle class, this is “torso torso2″ (it doesnt matter if torso2 doesnt exist because this is tested in the animation engine now). The super freeze() method for all enemies then runs an animation using this string.

This reduces the amount of code required significantly, and simplifies things a lot.

Animation Engine - BoneScripts + Application

I’ve also added in BoneScripts, which are pieces of code that can be run at given intervals. When adding a boneScript to the animation engine, the boneNames for it to be run with are specified, and then it gets run with each bone at the appropriate times.

These are used to add the freeze particles every 0.5 seconds, without requiring all the complex code that was previously required in the update method of every enemy - a script is created that emits a freeze particle at a given bone, and then this script is set to run every 0.5 seconds, with the list of bones specified previously.

Preliminarily playtesting the (limited number of unfinished) new guns I’ve implemented in the game recently, I came to a realisation that makes sense, but that I hadn’t properly considered before:

Weapons with more shots per charge, but the same shots per second equivalent, are much more useful in-game.

E.g. a weapon with a 1 second recharge time and 1 shot per charge is less useful than a weapon with a 2 second recharge time and 2 shots per charge.

There are a number of reasons why this is the case, and the main ones are as follows:

There are gaps in the game where there are no enemies on screen

Between waves, and when enemies have just died and new ones are coming in, there are gaps of a few seconds.

Comparing two theoretical guns: one with a 3 second recharge time and 3 shots per charge, and another with a 1 second recharge time and 1 shot per charge, both are going to have an opportunity to completely recharge every wave/when an enemy dies.

However, the weapon with 3 shots per charge will then be bringing in 2 additional shots that can be used up in that wave, and these will be replenished by the time difference later. This is a massive advantage.

Strategy: Attack - Dodge Cycles

With 3 shot per charge weapons, there is the opportunity to adopt an Attack-Dodge cycle strategy, which essentially involves staying as far away from the enemy as possible while the gun is recharging (so as to have more time to get out of the way of bullets), and then moving close to the enemies (to increase the chances of the alien’s bullets successfully hitting), shooting as many shots as the gun allows, and then quickly moving back away from them in order to be able to dodge their bullets.

This way, all the alien’s bullets have a high chance of hitting, having been shot close to the enemies, and yet the alien spends the majority of its time far away from the enemies, therefore being able to dodge their bullets.

This strategy would not be possible with a 1 shot per charge weapon - instead, the alien would have to adopt a middle ground, staying marginally away from the enemies so as to have time to dodge their bullets, whilst staying close enough that the alien’s bullets hit.

Essentially, this means that with a 1 shot per charge weapon, the player is likely to incur more damage, and less of their attacks are likely to hit the enemy, compared to a weapon with more shots per charge.

Time Wasted Switching Between Primary + Secondary Weapons

Switching between the primary weapon and the secondary weapon currently takes 0.5 seconds, during which time neither gun can be fired, but both guns will still recharge at their usual rate. I may reduce this to 0.3 seconds however.

Scenario 1 - Primary+Secondary - 1 Shot Per Charge:

Theoretically, if the player had two guns equipped that both had 1 shot per charge + 1 second recharge time, it would be very difficult - impossible even - to utilise the maximum potential of both guns. The player would have to shoot Gun 1, instantly switch to Gun 2 (taking 0.5 seconds), shoot Gun 2, and then instantly switch back to Gun 1 (taking 0.5 seconds again) in order to get back to Gun 1 by the time it had finished recharging.

In practice, this is ridiculous. The player is not going to bother with this. Instead, they are likely to just use one gun in this situation and not bother using the second one whatsoever. One gun will go entirely unused.

Scenario 2 - Primary 1 Shot Per Charge, Secondary 4 Shots Per Charge:

In this situation, the player is likely to use up all 4 shots of the secondary weapon, and then switch to the primary weapon, and continue using the primary weapon until they feel the secondary has charged sufficiently, etc. 

They are likely to use the secondary weapon to its full potential, and their primary will experience some wastage (due to the fact that it will likely reach full charge and not be being used while the player is using the secondary weapon)

Scenario 3 - Primary+Secondary - 4 Shots Per Charge:

In this situation, the player is likely to use the primary weapon until it is out of charge, then switch to secondary and use this until it is out of charge, then switch back to primary (which will not have fully recharged yet) etc.

In short, both the primary and secondary weapons will be used to their full potential.

Essentially, due to the interaction between primary and secondary weapons, weapons with a low shot per charge rate are likely to not be used to anywhere near their full potential, in stark contrast to weapons with a medium/high shot per charge rate.

Optimising Use of Special Effect Weapons

Special effect weapons (freeze, poison, instadeath, etc) are affected in even more ways. All of these weapons do varying amounts of damage depending on the number of enemies on screen, health of enemies, etc, or other factors. Essentially, their powerfullness is varying, whereas most of the weapons in game have fixed, unvarying powerfullness.

This means that it is very advantageous to be able to fully prioritise when these weapons are shot. For example, in a round where there are a whole bunch of low health enemies, followed by two high health enemies, it would be advantageous to poison both of these enemies at once using the poison gun - poisoning a high health enemy does more total damage than poisoning a low health one.

In short, having more shots per charge is even more advantageous in special effect weapons.

Summary

In conclusion, weapons with a low shot per charge rate:

Lead to the player getting less total shots per wave

Lead to the player having to adopt riskier play strategies, taking more damage, and having less accuracy in the bullets fired by the player

Lead to the player not being able to fully maximise both guns full potential

Meaning that they are likely to be significantly less useful in game than weapons with a high shot per charge rate.

I’ve been playing around making a whole load of different guns for the game. Not all of these will make it in to the final product, I am still in the stage of playing with ideas etc.

All the descriptions of how the guns will behave are preliminary and subject to heavy revision and change.

I’ve tried to create weapons that offer unique and useful effects, such as the ability to poison enemies, etc, in order to offer functional variety/strategy to the player.

Because the player has the ability to bring 2 guns into each game, I have also tried to add guns with high powered/interesting abilities with very low fire rate, and guns that can carry a lot of shots per charge, but don’t recharge very often. This makes it strategically advantageous to bring these guns into the game in combination with a standard high powered gun, and then switch to the non standard gun every 10 seconds or so to use its ability.

Weapons will be unlocked at various stages throughout the game (e.g. 1 weapon unlocked every 4 levels maybe), and the player will not be able to bring weapons into levels earlier than the level that they were unlocked at (so e.g. the player can’t take one of the incredibly powerful weapons into level 1)

I have created 11 weapons so far, and I hope to create a few more. 

ElectroZapper

The initial, most basic in-game weapon. Shoots electricity beams.

Plasma Blaster

The second weapon - shoots blasts of plasma. Has a slightly improved fire rate compared to the electroZapper, and also has the ability to hold 2 shots per charge.

SlimeZuka

Shoots green slime at opponents. Has slightly reduced fire rate compared to the Plasma Blaster, but has the ability to hold 6 shots per charge, making up for this.

Venom Dragon

Very low fire rate (1 shot every 6 seconds?), bullets poison enemies, doing 1 damage to poisoned enemies every 2 seconds.

FlameThrower

Very high fire rate, has the ability to hold 10 shots per charge, but flames have very limited range and you must be very close to enemies to do damage.

Magma Blaster

Standard, high powered gun. Relatively high fire rate, 5 shots per charge.

Freeze Gun

Lowish fire rate (1 shot every 3 seconds?) - enemies shot with this gun will become frozen for 6? seconds, and won’t be able to shoot at you.

Mr. Death

Very low fire rate (1 shot every 20 seconds?) - instantly kills the enemy it’s fired at.

Lightning Machine

Very high fire rate, holds 10 shots per charge, moderate recharge time

Mrs. Death

Very low fire rate (1 shot every 30 seconds?) - instantly kills the enemy it’s fired at, and does massive splash damage to surrounding enemies.

Laser