Blogs - 2PersonGames

First off, apologies for delaying the Steam release. There's a few things I want to finish up before letting it loose on Steam and I've been somewhat behind on things due to a strong down period end of last month. But here's the good news: scanning! More importantly how talents affect scanning.

Scanning

Scanning is new in Space Salvager and the idea behind it is to let you know a bit more about the things you're shooting before you shoot them. So far you can scan three things:

• Asteroids
• Salvage
• Space Ships

Each of these will return some basic information, such as the celestial entities unique identifier and possibly it's name. For more detailed information though you need to ramp up your talent levels. There are a number of different talents in Space Salvager, all of which are increased by spending time doing the associated task, and can be found in your pilots license.

Asteroids

With a mining talent of one you can find out the mass of the asteroid as well as the rock type it is, this can be helpful to estimate how many resources are within it and of what type. With a mining talent of two you can find out the name of the ore inside, telling you what kind of resources are within. Finally with a mining talent of three you can find out the exact amount of resources within the asteroid.

Salvage

With a salvaging talent of one you can find out the mass of the debris as well as the name of the ship if this happens to be a wreckage. With a salvaging talent of two you can find out the amount of machinery and electricals that might be inside. Finally with a salvaging talent of three you can find out the amount of aluminium, iron and tungsten as well as the name of any equipment that might be found within the debris

Space Ships

The data you can retrieve from scanning a space ship is a little more complicated than the asteroid and debris.

With a piloting talent of one you can find out the mass of the space ship. With the previous talent level if you have a laser weapons talent of two you can retrieve the ships shield percentage and if you have a mass driver weapons talent of two you can retrieve the ships current armour percentage. With a piloting talent of three you can find out the exact number of weapons that ship has.

For the past month I've been sitting around writing very little code and thinking a whole heck of a lot about the next game. It's been a 'month off' to collect my thoughts, but now March is over and April is the month of investigation! Engine investigation anyway, starting with GameMaker.

When I speak with other developers about engines and I mention GameMaker I get very mixed reactions, usually somewhere between apathy and blind frothing-at-the-mouth hatred - I have yet to find anyone that actually likes GameMaker, except for possibly @TheCodeTroll. If you're not familiar with GameMaker then I suggest you take a look at the link above and see what the fuss is about.

I last used GameMaker about four years ago, would've been late 2009, and at that point it was an alright engine for introducing people into game development without getting people distracted by any of the lower level concepts. What drew my attention back to GameMaker was the additional deployable platforms added over the last year or so, for example the PS4.

What I Did

So the first step was to complete the first tutorial: some game about a bouncing 'clown' that gets faster every time you click on him gaining you points. I got so far as implementing the basic game before replacing the standard 'drag & drop' mechanics with scripted ones using the engines proper physics engine. Also I added a load of clowns:

I got bored... #indiedev #gamedev #physics pic.twitter.com/otyDBzuBu5

— Sam Albon (@2PersonGames) April 5, 2014

As with most physics engines it's all dependent on accurate collision meshes, the resultant collisions were pretty awful when I used circular collision but after manually building a six-point polygon around the 'clown' the results were pretty swish. From there I went on and started implementing a little space scene with a sun and a few planets orbiting the sun. I used the same orbital calculations as Space Salvager and they ported quite well into the GameMaker Language (GML). The final piece was implementing 'gravity' into some asteroids, so every time I clicked somewhere it dropped an asteroid won into the world and began drawing them towards the nearest gravity well. That worked well, mostly.

That's as far as I'm going tonight, learnt quite a bit and I'm happy with that. #gamedev pic.twitter.com/Afeepeu7e8

— Sam Albon (@2PersonGames) April 5, 2014

Each little speck is a tiny asteroid, they sort of clumped together and followed the closest planet to them.

My Thoughts

Although this never produced a game of any sort, this did exactly what I wanted it to: experience the engine and get a feel for it. GameMaker has some good points: physics are easy to implement, collision meshes can be produced quite expediently, sprite animations are very flexible.

That being said, I found it quite hard to do anything really complicated in a clean fashion. Now this might be down to my inexperience with GameMaker, however I was attempting to manipulate to camera to perform two things: centre on an object and scale on the mouse scroll. Centring on an object isn't hard, GameMaker room views will track an object and maintain them inside the viewport with a given buffer around the edges of the viewport. However, merge this will modifying the view by 'zooming' with the scroll-button and you find an issue. Every time you change the zoom you have to change the buffer around the edges of the viewport to keep the object in the new centre of the screen, something that's fixable by running the numbers in the script but it felt as though this should be available as a feature or maybe I'm just being lazy...

One of the things about GameMaker that did annoy me was the way you declare class variables, or rather how you do not. If you want to use a local variable for that script you declare it using 'var' much like javascript, it's type is undefined until you actually start using it which irritates me but I can get on with that. If you want to use a class level variable you just start using it, there's no declaration of any kind and much like the local variables you can store whatever you want in it. Personally I don't mind having to be aware of my variable names and their types, one of the most fun things I ever wrote was a little demo for the PSP in C using Notepad++, but that doesn't lead to an expedient ease of development which is what using a high level IDE like GameMaker is about. This is more of a peeve than an engine-critical issue, a contentious rant shall we say.

...upon reflection...

I've taken my time writing this post and that's because my opinion slowly changed over the course of the days proceeding. I do like GameMaker, I think it had the potential to be a very good engine for small development teams: like lonesome me. I am torn between the ease of multi-platform deployment for GameMaker and the high-level of control in using my own engine. I'm not the greatest games designer ever, I'll be the first to admit that, but I'm a very decent programmer and fairly good at technical design - using GameMaker was difficult for me because it took away a lot what I'm good at and made me focus far more on the games design aspect, which is good and bad. This was bad because it was playing to my weaknesses, but good because it forced me not to hide away from my weaknesses and tighten up my games design skills.

I intend to go on using GameMaker, perhaps not to make any full titles, but to make all these little ideas I keep having to prototype and hone my weaker skills in design. GameMaker is good for prototyping and decent for full titles using the right concept. Every tool though, no matter how hated, does have it's use and I think I've found my use for GameMaker.

It's been a long time coming, but it's finally happening.

If you've already purchased from IndieGameStand then you can redeem your Desura key now I believe, although you may have to wait to download it. If you've bothered me for a key on twitter then that should be working too.

There's an article I posted up in IndieDB in 2012 talking about being published on Desura, for all that time though it has done wonders for the game. The HUD has been completed redesigned, so has the player and station menus so they actually look a tiny bit pretty. Space Salvager is now a game I am quite proud to say 'I made', not a perfect game but a legacy that I will continue to develop and add to as time goes on... and it is tremendously fun to shoot pirates: they're hard as nails but it's great when you finally get that kill.

But for now, it's out on Desura right now:

Something I have been forgetting to mention, it is cooperative:

Gameplay is pretty much working at least. #multiplayer #gamedev #indiedev #spacesalvager pic.twitter.com/pBlRYkihYj

— Sam Albon (@2PersonGames) February 17, 2014

Research Time For the last week I’ve been taking time out to watch films and play games that I’ve not seen before to start filling my head with new ideas and concepts. Last night I watched 1984, which was a lot more gratuitous than I’d previously though, and over the weekend I managed to pick up Planetary Annihilation which was… promising, certainly worth playing and I can see it will be amazing when it’s completed.

The image used for this, which I tweeted a while back, is just a spontaneous place holder I made. @Tupperwits should be coming up with something much nicer in the coming week or so, but if you want to see it sooner feel free to harass him on twitter.

The current list of ‘research material’ includes:

• Blade Runner
• Elysium
• Donnie Darko
• Dark City
• The Matrix
• Sword Art Online
• Sin City
• Dredd
• Fifth Element
• Red Line
• 1984
• Metropolis (Anime)
• Metropolis
• Evangelion (Neon Genesis)
• Evangelion (Rebuilds)
• Rah Xephon
• She, The Ultimate Weapon
• Patlabor
• Rumbling Hearts

• Planetary Annihilation
• The Secret World
• Ico
• Baldurs Gate
• Frozen Synapse
• Deus Ex

Space Salvager 1.4.2 is finally out! Admittedly without multiplayer, which I am very unhappy about but it had to be done unfortunately.

The Future

The current plan doesn't involve any more patches for Space Salvager, although knowing me I probably will anyway. Currently I'm planning on making a few small prototypes and seeing how they go, at least two of which are sequels/prequels to Space Salvager. So stay tuned!

Patch Notes (Fixed)

• You can trash your only ship (assets menu)
• Add accelerators back in
• Changing from no/new profile to saved profile crashes game (possible from space to station)
• Check death/life effects for resource spawners
• Check player death
• Closing save profile menu re-activates the navigation bar
• Constellation menu too small for 1080p
• Fix shadows
• Fix switch profile save/load menu
• Issue jumping from “First Boneyard” to “Muspell” (player does not re-appear)
• Lasers do not always show, particularly when firing at something close
• Light ship better
• Loading text will sometimes go green but not change the actual text
• Resolve compilation warnings
• Tweak shadows over the top of objects
• You can trash all items and go back to an empty menu (assets menu)
• Y Button on gamepad does not perform exclusive check
• Cannot open player menu with Start Button on gamepad while in sub-menu
• Cannot close player menu using B Button on gamepad
• Check the efficiency of particle engines
• Radiation warning not rendering when HUD is not displayed
• Change HUD arrows to use different sizes and colour filters
• Resource drops should appear on HUD when close-by
• Have interactable orbital objects jump you further from the centre
• Reduce the number of render calls for shadow mapping
• Remove PC overlayer
• Change ships and equipment to only exist at stations they were left at
• Change asset menu to disallow the destruction of the last ship at that station
• Change asset menu to disallow the destruction of the last engine (including equipped to ships) at that station
• Lasers do not fire at the correct angle
• Svartalfa and Harbingers labels on constellation map are off
• Destination text sometimes goes beyond the HUD display
• Add weapon positions on ships
• NHSA Enforcer always drops the last weapon equipped after undocked (or the NHSA Hulk)
• Change the hangar menu so only successfully changing an equipment removes it
• Job board assignments double select and print bad text
• Change laser beams to check collision from where they are actually are
• Rebalance entire economy
• Equipment/Metals do not affect cargobay, change this so they do
• Game crashes after death, attempting to re-dock at station
• Ship still visible after death
• Dying from radiation outside the sector does cause the player to go into a dead state
• Engine trail still visible after jumping
• Fix engine trails for Gold Dumpster (Lorry_2)
• Change the UESA Travellers engines
• Accessing a ship on the station hangar bay should move this ship to element zero in the array
• Add cargo bay menu
• In game messages do not take into account camera zoom
• Change the mission payout values for time and unit count
• Change the HUD text to go above the darkness
• Sometimes won't undock until restart
• Sometimes discos out when jumping
• Cargo bay confirm menu not closing
• Moving resources from your cargohold to your station does not increment your resources
• Emptying your cargo bay does not update your data display
• Undocking seems to fix armour/hull
• Remove L3 has HUD toggle
• Trashing your last equipment makes the menu think you're trashing your last engine
• Finding the nearest ship throws an exception when a player ship has no location
• Pressing enter after player ship death sometimes does nothing
• When launching from the HUB the first ship is not selected
• Remove station back route
• Remove mission routes
• HUD text scaled wrong for camera zoom
• Explosion particle engine not rendering correctly
• Redeploy new game description
• Clean up arrows in wrong locations for first tick of after creation
• Armour/Hull are not priced correctly
• UESA Traveller Engines y axis flipped
• Region maps clamping values causing issues
• MEC Belt connection not in map menu
• Laser HUD colour needs changing
• Change resources not to re-spawn on destruction, but only on exiting on boundary to limit the number of resources harvested
• Rotate enemy health to face the player
• On clearing a sector of everything inform the player (positive reward)
• Cargo bay not showing electricals
• Experiment with arrows getting bigger as you get closer.
• Show enemy damage when player hits them
• Play around with the shadow clearing (perhaps only draw objects AT ALL if they're in line of sight)
• Player ship is still visible after death
• Fix polygon collision generation
• Change swapping a weapon to see all weapons, not just weapons of that type
• Transport missions can select themselves
• Change missions to be available form spawn only, eight for each planetary sector
• Fix AI not to obsess over the centre of the map
• Change AI to pathfind and not strike eachother
• SpaceShip circular collision mesh not generated properly
• Small ships (UESA Alpha 2) do not collide with big objects (asteroids).
• Change ship data to have a flag for locked, using this flag for being able to see and build
• Change hangar menu to accept more than seven weapons
• Issues changing equipment
• Add warning message to equipment change menu
• Remove credits display from hangar bay
• Add credits display to the armour/hull fix menus
• On player ship death engine sound does not stop
• Stop music when player leaves
• Sometimes pressing escape in the confirmation menu does not close the menu properly
• Change player to store a name based on the user logged in
• Confirmation menu doesn't close when creating or viewing a server
• Joining a server doesn't work
• Change the server and client to push and pull once every second, not every tick
• Changed chat box to only update the selection menu on click
• On game exit player does not leave the server
• In server menus player display does not have a 'c' at the end of the credits count
• Server does not shutdown properly
• Chatbox shows on undock
• Fix chatbox button collisions
• Change station and player menu colours to reflect the current regions colour.
• Add the name of the station to the station navigation bar when nothing is open.
• Add chat send and receive on server/client
• GameObject::TakeCreationStream failing every time, going outside buffer range
• Sometimes you can connect multiple times on the server whilst connecting zero or once on the client
• Jumping sometimes does not spawn the player on the other side
• Docking causes no station menu to be generated
• Change load profile display boundary to reflect the colour of the owning region that profile was last saved at
• Shooting causes the client/server to begin handling update packets badly
• Client ship is added twice
• Add corporation manufacturer on item
• Undocking from the server does not add the server player ship to the client
• Add corporation to all item data
• Display corporation logo on item display
• Add corporation data
• Finish logo for UESA and NHSA (remove manufacturer/logo existence check on DataDisplay)
• Override default ActiveShipData data with TemplateShipData
• Display corporation logo on station menu 'no-menu'
• Fix mouse texture not rendering in centre of mouse
• Shading for light flicker (rounding issue with DrawLine)
• Salvage does not always drop items
• Ship doesn't always dock/interact first time
• Add animations into the menus based on cameras and states
• HUD does not position correctly in two player
• Mouse is rendered in the wrong location in two player
• Menus stretch horizontally in two player
• Station menu name in two-player position is incorrect
• Change all light emitters to re-render, not just the camera
• Tutorial text does not always appears in two player
• Switching profiles with two people causes viewport issues
• Leaving the game when another player is in the player loader menu causes the viewport to stretch
• Resizing the viewport causes the camera to jump around

Things have not progressed how I wanted: at all. I purposely set a fairly wide deadline for 1.4.2 to ensure it was definitely going to be ready for the end of January, but then everything fell apart. It was nothing that happened to the game, but something that happened to me personally that stopped me from being able to work. I won't go into the details, although anyone who follows me on twitter probably pieced it together when I announced the title of my next game:

Needs some work, maybe scrapping entirely. #gameart #betrayal #gamedev #indiedev pic.twitter.com/hJXHezJ9pF

— Sam Albon (@2PersonGames) February 6, 2014

So January sucked and I got nowhere near the work done that I needed to, however now we're half way through February and things are looking better here is the plan:

• Release 1.4.2 with or without multiplayer for the Ragnarok - supposedly 22nd of February


• Release exclusive content on IndieGameStand same day or after
• Release on Desura soon after
• Give a bunch of free keys to all my twitter/wordpress followers
• Re-bother reviewers for reviews

That's the plan anyway. So if you know anyone or you yourself wants a free copy of Space Salvager bother me on twitter or here.

The purpose of this post is to give an introduction to making thread-safe calls specifically within .NET/Mono.

Thread Safe Calls

A thread safe calls are a type of call that can be made from any thread that won’t interfere with the operations of another thread. This is an important overhead to include because, as an example, if you have one thread reading a list and another thread writing to that list at the same time the first thread is most likely going to go beyond the bounds of the list. One of the ways to achieve this in a thread-safe environment is to control access by using either a lock, mutex or semaphore.

Locks, Mutexes and Semaphores

The way a lock, mutex and semaphore work is to block the calling thread until they have been released. For .NET/Mono there is very little difference between a lock and a mutex; a semaphore on the other day is essentially a more complicated lock, allowing for multiple threads to read/write. Most of the you’ll use a mutex, but sometimes you may want to control read and writes in a far more complex way in which case you should use a semaphore.

How To Use Them

The way mutexes work is you enter the mutex before accessing the memory in question, perform your operations, then exit the mutex after you’ve completed. However, the best one I have found for using across .NET and Mono is a semaphore called ReaderWriterLockSlim:

using System.Threading;
 
public class ThreadLock
{
    ReaderWriterLockSlim mLock;
 
    public static void Main()
    {
        /* Create the lock */
        mLock = new ReaderWriterLockSlim();
 
        /* Enter the lock */
        while (!mLock.TryEnterWriteLock(-1));
 
        /* TODO: Processing */
        throw new NotImplementedException("Do Processing!");
 
        /* Exit the lock */
        mLock.ExitWriteLock();
    }
}

The above TryEnterWriteLock() will attempt to enter the semaphore for an infinite number of milliseconds (-1). This is a fairly efficient and fast sempahore that supports both read and write locks, with multiple and combined cases for both. Personally I use it as a straight mutex instead of a SpinLock because at the time of porting Space Salvager it was not available in Mono.

When executing code that requires a mutex it’s fairly standard to run that inside a try and finally statement. What this ensures is that any synchronisation exceptions are caught and, in the slim but often frequent chance, any exception is thrown the mutex is always released. The below example shows the base object GameObject in Space Salvager handling it’s update call using a mutex:

public void Tick(float delta)
{
    try
    {
        /* Lock this object */
        Lock();
 
        /* Check the timer */
        if (Enabled)
        {
            /* Call update */
            Update(delta);
        }
    }
    catch (Exception e)
    {
        ComponentOwner.Game.Log(e.ToString());
    }
    finally
    {
        /* Unlock this object */
        Unlock();
    }
}
 
protected abstract void Update(float delta);

All objects inherit from this abstract class, overriding Update to implement their own update code. Because the call is made from within Tick all the calls made within Update to itself are thread-safe. If another object is accessed, you would call Lock on that object to ensure synchronisation. The issue to bare in mind, however, is not to cause a recursive lock. If a thread enters a mutex a second time before exiting this is known as a recursive lock. Some mutexes will allow this, for example a Monitor will, however the issue with this is when the subsequent exit is called the mutex is immediately released before it is expected to have been.

The solution to a recursive lock is simply to plan your architecture and ensure you don’t lock your mutex twice on the same thread. Sometimes this is very easy, but if you’re making a rather complex game then it can become very tricky.

Interlocked

Sometimes it isn’t necessary to use a mutex to access an object atomically. .NET/Mono implements an atomic class called Interlocked, which allows integers and other numerical value types to be read and written to atomically.

private void BroadcastAddObject(GameObject obj, string sector)
{
    /* Find the object */
    long? identifier = GetTrackedObject(obj);
    if (!identifier.HasValue)
    {
        /* Get a new identifier */
        identifier = Interlocked.Increment(ref mTrackingIdentifier);
 
        /* Add to the tracked objects dictionary */
        AddTrackedObject(obj, identifier.Value);
    }
}

This is good when using an index or an ID number for example, to be honest however if you need to use an Interlocked you’ll know when.

ve been meaning to start writing about my experiences porting Space Salvager from XNA to MonoGame, but as is often the case things keep getting in the way – but not tonight! These are a few issues I found porting from .NET 4.0 to .NET 4.5 Portable, these are not strictly MonoGame but are a part of going from XNA 4.0 to MonoGame for Windows 8.

Type.IsSubClassOf(Type)

This member function is used to check if a class type inherits from another, useful if you want to get all the objects of a certain type and their subclasses from a scene. More often than not is would be used, for example:

if (obj is GameObject)

This would return true if obj is or inherits from the type GameObject – this works for both classes and interfaces. However, it is not always possible to do this and so Type.IsSubClassOf(Type) must be used, such as below:

foreach (GameObject obj in objects)
{
    if (obj.GetType() == type || obj.GetType().IsSubClassOf(type))
    {
        yield return obj;
    }
}

In .NET 4.5 Portable this method is no longer available, however it can be replaced with TypeInfo.IsAssignableFrom(TypeInfo) found in System.Reflection. If we apply this change to the above example we end up with:

foreach (GameObject obj in objects)
{
    if (obj.GetType() == type || type.GetTypeInfo().IsAssignableFrom(obj.GetTypeInfo()))
    {
        yield return obj;
    }
}

For ease of use it’s advisable to wrap this inside a function somewhere, this makes using both versions for multiple platforms much easier as well:

public static bool CheckTypeIsSubClassOf(Type super, Type sub)
{
#if WINDOWS8
    return super == sub || super.GetTypeInfo().IsAssignableFrom(sub.GetTypeInfo());
#else
    return sub == super || sub.IsSubclassOf(super);
#endif
}

StreamReader

.NET 4.5 saw the move to all API calls with an average execution time of over 50ms , which is yet another annoying change for developers moving to Windows 8; that being said it is good practice to run certain processes on a separate thread from the UI thread. This can be become problematic later on when you have to run certain processes on the UI thread, but that’s something I’ll cover in a later post.

One of the commonly used API calls moved to asynchronous execution is System.IO.StreamReader, which can no longer be created by simply calling its constructor. The solution I chose to implement was essentially a work-around the asynchronous nature of the call and force the current thread to wait for task to return. I chose to do this for reasons:

Streams were already being created asynchronously in Space Salvager.
These new asynchronous functions are not available in .NET 4.0 and therefore was not cross-platform compatible

public static StreamReader GetCurrentLocationStream(string filepath)
{
#if WINDOWS8
    /* Get the current storage folder */
    Windows.Storage.StorageFolder folder = Windows.ApplicationModel.Package.Current.InstalledLocation;
 
    /* Wait on the task to complete */
    System.Threading.Tasks.Task task = folder.OpenStreamForReadAsync(filepath);
    task.Wait();
 
    /* Return the result as a stream reader */
    return new StreamReader(task.Result);
#else
    return new StreamReader(filepath, System.Text.Encoding.UTF8);
#endif
}

Above is the solution that Space Salvager uses, both versions of the function will return the StreamReader synchronously.

string.Contains(char)

This is barely worth mentioning as it’s such a small issue, however it does perplex me why it was removed. string.Contains(char) was removed in .NET 4.5 Portable, however the solution is very simple. call char.ToString() to convert it to a string. Easy, but still odd that it was removed.

Thread

There are a two major changes for System.Threading that I came across whilst porting.

First off the Thread class has been removed, however the Task class behaves almost identical except there is no Task.Sleep(int) function. There may be another way to sleep a Task, however there isn’t one that I’ve found.

System.Threading.Tasks.Task start = new System.Threading.Tasks.Task(delegate { /* Task */ });

Second there’s no longer a System.Threading.ThreadPool: now this was a major issue for Space Salvager as it runs a lot of processes in the background that don’t need to be completed straight away, but do take quite a long time to run and have a tendency of fighting each other for resources if you just spawn them all as Threads/Tasks and walk away. The solution I chose was to implement my own ThreadPool, but that’s something I’ll cover in a later post as it’s quite a lot of code and deserves it’s own post.

So what would multiplayer be without being able to chat with each other? Better than that, what’s the point in fighting pirates if they can’t smack-talk you?

Multiplayer Chat

Every game with multiplayer has the ability to chat with each other, at least every multiplayer game I can think of does. The chat itself will be separated into sector wide, region wide and constellation wide – the latter being everyone in the current game. At the moment I’m not thinking of putting private/group chat in, but that’s something to consider for a later patch.

IRC

Since the Norfolk Games Expo I’ve been considering integrating an IRC channel into Space Salvager. This came from a talk with @CWolf and @Jargon64 about the popularity of IRC within certain gaming communities. I don’t know whether IRC would be particularly popular for Space Salvager, however I think integrating would be a good challenge and be a nice feature.

It’s unlikely to go in 1.4.2, as I’d rather focus all my time on ensuring multiplayer works and the existing features are polished quite nicely. But, it’s something to think about.

AI Chatter

Something I’ve been bouncing around for the last week is the idea of pirates talking to one another. I was flying around a sector testing some of the fixes for the AI whilst thinking about multiplayer chat and thought it would be kind of cool to have the pirates talk to one another in the same sector, maybe talking about the player or space weather and then smack-talking the player and so forth when they’re actually in combat. As with IRC integration it’s unlikely to go into 1.4.2, but it’s something for 1.4.3 .

Chat Box

Below are the two concepts for how to implement the chat box:

A

B

The preferred layout seems to be A, thanks to @iisjreg and @astin1992, however I’m still gaining more feedback on it and we’ll see what happens from there.

That’s all for now, but stay tuned for more!

Pictures! Pictures galore! Everyone loves screenshots, right?

Enemy Health Notifcation

One of the enhancements people were asking about at the Norwich Games Expo and GameCitySquared was “targeting” in combat. Essentially, retaining who you’re shooting at because there can often me a number of enemies on screen and a number visible on your HUD. Now, the enhancement here is two fold: inform the player of the targets health and inform the player who the target actually is.

The former has been done, as shown above: when you shoot at enemy their health (shield, armour or hull – whichever has taken the damage) is displayed. This works quite nicely and I feel doesn’t clutter things up too much, although I’m considering only showing it when the HUD is visible. The former however I’m still unsure how to do. I’m considering having the last person you shot flash on the HUD and perhaps introduce randomly generated names for pirates so you can identify them, displaying their names underneath the new health popup at the top. If you have any suggestions please tell me or if you hate the changes so far that’s good to know too.

Celestial Objects in HUD

Another suggestion was a way to convey distance of objects in space (hey look, an episode of Firefly!), which resulted in changing the size of the arrows. Seems like a simple idea right? I hadn’t done it before because the original concept was that each type of celestial object would have a different size and colour arrow, but using both different sizes and colours is somewhat redundant as turns out. The change of colour has been retained, but now as your approach the celestial object its arrow gets bigger, likewise when you retreat away it gets smaller.

The other change was the colours in general, because they really just didn’t work. So now blue means jump gates, brown means asteroids, silver/grey means debris, green means stations and red means death pirates.

Collision Bounds

The last change of note for this post is the collision bounds. Now, long long ago Space Salvager used “tight pixel” collision detection which was very expensive and didn’t really work. During my final year at University one of the assignments we had was an investigation into game physics, specifically collision detection. As with most things I thought this was a good opportunity to shove something new into Space Salvager, so I decided to implement SAT collision detection in.

Unfortunately much like the previous collision detection this didn’t really work either, but recently I’ve actually found out why and fixed it. Short version: the two-dimensional polygon being created was based on a texture that was colour compressed and wasn’t returning the correct results – between you and I I’m surprised it didn’t crash the entire game. Now though I have fixed it by rendering out the image into an uncompressed format. Above shows the debug render where the yellow circle is the collision radius, clearly broken on the ship which I will fix (note added) and the purple wireframe shows the two-dimensions convex hull. The result is a much, much more realistic collision detection and response. The physics for the game have responded much better with working SAT collision now, it’s really nice.

That’s all for now, but there will be more. I’m hoping to do a post every week about what’s coming in 1.4.2.