Long time, no post. I’ve mainly been focused on updating my other blog over at shogan.co.uk and have not dedicated much time to putting up anything over here.
I tend to get small bursts of time on occasion to play around with my own ideas in Unity. This time around I created a small 3D world that is randomly generated and contains a little bit of wildlife with some basic needs.
Terrain generated with colour as the indicator of ‘height’. E.g. areas around water are sanding and fade up to grass and then darker grass as you go further inland.
Trees and food nodes are scattered around.
Water is spawned.
Chickens are created (male and female) and have basic needs like thirst, hunger and reproduction.
At the moment the animals simply wander around as their needs become more and more urgent. They’ll eat, drink or reproduce based on these needs.
If a need goes long enough without being met, they will die.
The idea is to get some interesting statistics and figures out of the simulation, observing what patterns develop and where animal populations end up highly populated or sparse.
I still need to do more work on it, but some interesting new features to add that I have planned are:
Add a genetics system with traits that can be passed on to offspring.
Positive or negative traits will either help or hinder animals throughout their lives.
Adding the above systems should definitely spice up the simulation and allow for some interesting observations.
Once you’ve figured out a general process for deploying game releases, you certainly don’t want to be manually completing every step of the process every time there is a release. If you add up the time spent copying build releases, updating websites with new build information, sending out notifications or change logs, etc… that time can really add up in the long run. Unity Cloud Build helps solve some of this, but there is more that can be done…
Unity Cloud Build already allows you to hook up to your Git (or other) repository to the Cloud Builds platform, and have automated builds created of your project whenever you push code up to your repository. This is great, and allows you to automate builds for various platforms – PC, Mac, Mobile, etc all by just updating your source repository. You can even configure it to watch a specific branch and create builds from that branch, effectively allowing you to branch off of the trunk/master and work in feature branches, then merge work back into ‘release’ branches.
The question then is, how do you continue this automation pipeline after Unity Cloud has finished your build?
The answer is to use a: Webhook.
A webhook is an HTTP POST request that Unity Cloud Build can send to an API endpoint you specify, whenever a particular event in your build pipeline occurs. For example, on the successful completion of a build. (ProjectBuildSuccess event).
You can choose a particular content type that the webhook payload is delivered with (one that your API would understand like application/json). Let’s look at an example of configuring a webhook that will send a POST request to an API endpoint I manage/own when a build of my Unity project successfully completes.
For this I will be running a simple Node.js express web server with body-parser middleware. In my Node.js server, I have set up a route for POST actions to go to called ‘builds’. When a POST request is sent to this endpoint, I’ll simply log the content of the POST body to the console to show the information that Unity Cloud Build sends along.
After setting up a Unity Cloud Build step, I went to define a webhook in the “Notifications” tab. I provided the public URL for my endpoint where the HTTP POST request will be sent to, set the content type to application/json, and chose the event that I want this to happen on. For testing I didn’t bother with providing a secret to help secure the body of the POST, as this would then need additional processing of the content on the other side to interpret it.
Note: if you are doing this yourself as a test/proof of concept, and don’t have SSL on your domain, you should disable the SSL verify option. (You should always secure with SSL if you are using this in production though, as you don’t necessarily want information about builds being passed around un-encrypted).
With the webhook defined, and saved, to test it, I simply kick off a build of the Unity project. (You can manually start a build if you don’t want to hassle with making changes to your repository).
After the build completed, as expected it sent the POST request to my API’s /builds endpoint. (You may want to click to expand the image below to actually see the details the POST drops off in the body!)
From this point onward, I could then do whatever I needed with the information sent across in the body. Here is a quick example. Let’s say there is some interesting information I wanted out of the actual build log that is generated from a build. Say I wanted to publish some of that information to another website after a build completed.
I would take the build number from the webhook POST request’s body content when it hits my API on the /builds endpoint, craft a new POST request myself, and send this to the Unity Cloud Builds v1 API, including the following request parameters: orgid, projectid, buildtargetid, and finally the build number which I got from the webhook’s POST request. This is what the request would look like for a ‘get build log’:
I fire that off, and the Unity Cloud Build API should respond with my full build log. I can then parse that log for the information I need, and update my site with it.
Once that is all setup, all I need to do is update my Unity project source code in version control, and Unity Cloud Build will build the project, upon success, it will POST some information about the build to my own API, this information will then be used to in turn query the build API for the specific build log relating to this build, the response will come back, my system will parse that log, take the interesting information, and through some other mechanism, update a website, which might at that point end the whole automation pipeline.
Hopefully this gives you some interesting ideas or inspiration to automate your own builds. The sky is really the limit. RESTful APIs make automation and interoperability of systems so easy!
Just a quick demo this evening with around 5 minutes of game play showing some of the new features like save/load of worlds (JSON serialization), fishing, and new features relating to usable items (extending the use of Interface design), crafting and building. Full screen it!
I started working on Dropship (the temporary name for this project) back in January, when I was on holiday in South Africa. It is a 2D ‘Minecraft’ style, sandbox survival game, drawing inspiration from Minecraft and Starbound, two of my favourite survival/sandbox games. After getting back from holiday I kind of just left it in its git repository, not doing too much, gathering dust. Recently I had the motivation to pick up development again in my spare time.
Over the last week or so, I’ve added the following new features.
JSON Serialization save/load system. Save your progress and quit, then load up your saved world again later. All of the game/chunk/player built items are now able to be written to JSON and persisted to disk.
Fishing and living fish colonies that are able to breed/multiply in water blocks
Cooking with fires + nutrition attributes on food
Basic survival stats and UI for health, food, and energy
Self-healing blocks – similar to Minecraft where they replenish ‘hits’ if you stop hitting them
Water/lava with surface settling effects (liquid blocks move down and fill out voids, and once settled, surface effects are created along the surface, such as lava bubbles, or jumping fish)
I’d like to work on the JSON serialization a bit more though. There are some items that still need to be accounted for when being re-generated from JSON data on load, and there are many optimisations I could still make to reduce file size and speed of the save/load system.
If you’d like to read a little more and see some videos of the game (taken before some of the above new features were added), take a look at the game page here.
In this tutorial, we’ll be covering building your very own Amazon AWS DynamoDB integrated Unity3D game. We’ll be using two public cloud based technologies provided by Amazon AWS, namely DynamoDB (a NoSQL database service), and Cognito (identity management and data synchronization).
We’ll be building a character creator with Amazon DynamoDB integration in Unity3D. This will be a modular character creator that allows you to configure the look of your character, as well as his/her stats. The screen will pull any saved characters down from your DynamoDB table, and allow you to save new characters back to the cloud.
Before we get started, here are two very quick primers for you if you are not already familiar with DynamoDB and/or NoSQL technologies.
NoSQL covers a group of database technology types that differ to traditional relational style database types. They were developed to help combat a rise in the volume of information stored in general about users, products and objects, as well as the performance requirements for accessing this information in cases where scale is very large. There are four main types of NoSQL ‘stores’ around
Without going into detail about the types, the main thing to keep in mind is that they differ to traditional relational databases, and make certain types of operations much faster in NoSQL than they are in relational style databases.
DynamoDB is a fully managed NoSQL database service from the Amazon AWS cloud stack that provides quick, predictable performance with automatic scalability based on the provisioned throughput settings you apply to your tables. DynamoDB tables can store and retrieve any amount of data, and serve any level of request traffic you require for your applications, and run across multiple servers in the Amazon AWS cloud stack, backed by SSD storage.
We’ll be using Unity3D version 5 for this tutorial, so the UI is the new Unity UI that became available in version 4.6 and above. Hopefully you are already familiar with creating a basic UI, as I’ll be skipping that in this tutorial, otherwise it would just take up too much space! Download the starter project here, which includes all the UI setup for you, along with some fancy scrolling background, and base GameObject items created, waiting for you to attach new scripts to.
Open the starter project in Unity3D, and go to Assets -> Import Package -> Custom Package. Navigate to the extracted Amazon SDK folder, and located the “unitypackages” sub-folder. Choose the “aws-sdk-unity-dynamodb-188.8.131.52.unitypackage” file to import and import all items into the project.
Browse the Project Assets hierachy, and locate the AWSPrefab prefab under the “AWSSDK -> src -> GameObjects” folder. Drag and drop this prefab into your scene hierarchy. This GameObject is required in your scene to initialise everything we need to get started using the AWS SDK in our scene. The prefab should have a “UnityInitializer” script attached to it.
Creating and configuring the required Amazon services
First of all you’ll of course need an AWS account. Register for one if you don’t already have one. You can use the free tier for 12 months on a new account which includes everything we need. Once configured, sign into your AWS Console.
Now we need to setup Cognito for identity management. This is under “Mobile services” from the main console. This will only be used in our case in an “unauthenticated” user capacity, however it has some great features like user sync across devices and identity management for user persistence if you wanted to dig further than this tutorial’s scope.
Create an identity pool and give it a name like “CharacterCreatorAWS”. Ensure you select “Enable access to unauthenticated identities“.
The next screen asks whether you would like Cognito to create some default roles with limited permissions. Make sure you click “Allow” here for the default roles to be setup. While you are still in the Cognito dashboard, select “Edit identity pool” and copy your pool ID down into a text document. We’ll need this later.
Now we need to create a DynamoDB table. Go back to the main AWS console, and choose “DynamoDB“. Once the dashboard appears, click “Create Table“. Give the table a name of “CharacterCreator” and enter “CharacterID” as the Hash Attribute Name, making sure you select “String” as the type. Click “Continue”.
The next wizard screen is optional to add indexes. We won’t be adding any, so click “Continue” to skip this, and move to the Provisioned Throughput Capacity screen. Here we can choose how many read and write capacity units we require. For this tutorial you can choose 1 or 2 each, but would need to consider these sizes using the calculator if you were deploying this for a game that would see high amounts of characters being created/read to/from your database!
The next wizard screen offers to setup a basic alarm for table request rates that exceed 80% of your provisioned throughput in 60 minutes. This is a good idea if you wish to be notified of any potential utilisation issues. Enter your e-mail here if you wish to be notified in this case, then click “Continue”.
Finish the table creation wizard, and when done, select your new table and click the “Details” tab. Copy out the ARN (Amazon Resource Name) for your table and note it down. We’ll now create a custom role policy using this ARN and assign it to our Cognito identity pool, which will in effect give your users access to your newly created table.
So, our next step is to use Identity and Access Management (IAM) to apply a custom role to allow unauthenticated users that run your Unity3D game access to the DynamoDB table that will store character configurations.
Go back to the main AWS console and click “Identity and Access Management“. Click “Roles” on the side menu, and then locate and click on the “unauth” role that was automatically created by Cognito earlier. It should be named something like “Cognito_CharacterCreatorUnauth_Role”. Look for the Inline policy section and click “Create role policy”.
Select “Custompolicy” when asked what type you would like to create, and then click “Select” to use the policy editor.
Give your new policy a name like “AllowDynamoDbTableAccess” and use the template provided below. Policies are formatted in JSON, and you’ll need to change the resource value in this template to the ARN you copied for your DynamoDB table you created earlier. Here is the policy template you can use:
Click “Validate” and once validated, click “Apply policy” to assign this policy to your Cognito unauth role. You now have all the groundwork for configuring your AWS services done. Well done! Let’s move back to Unity3D finally.
Unity3D and AWS code
Now that all the AWS setup is complete, lets begin adding our integration with AWS. The starter project you downloaded above has all of the UI ground work complete for you. If you run it now, you’ll get a character selection screen where you are able to change the look and configuration of your character, however you are not able to save it to the database or load any existing characters and change them either. This is what we will add now.
Start by adding some using statements at the top of the CharacterCreator.cs file. These will reference some of the Amazon SDK namespaces and allow us to use Amazon specific classes and services in our CharacterCreator script.
Now we’ll need to add a class for our characters to use with the DynamoDB data model concept. In DynamoDB, a database is a collection of tables, and each table is a collection of items with each item being a collection of attributes. This class that we create will represent the items in our CharacterCreator table.
Create a new class called CharacterEntity in the Unity3D editor under the scripts folder, and open it up in your editor. Remove the inheritance to Monobehaviour as we will not be needing this, as this is a plain data model class. Copy and paste the below into your CharacterEntity class.
As you can see, this class contains various properties to store each character’s configuration, from the stats like Age, Strength and Dexterity, to what the character parts are composed of (“ShirtSpriteName”, “BodySpriteName”, etc…).
Each property has an attribute applied to it, mostly all indicating the each property is a DynamoDBProperty. Note however the first property “CharacterID“. This is the same as the hash key we created earlier when we setup our table in DynamoDB. Note that it is a string value, as we dictated when we created our table. This has the DynamoDBHashKey attribute applied to it, to tell the table that this property is our primary key. To quote the AWS SDK documentation on this Hash Type Primary Key:
the primary key is made of one attribute, a hash attribute. DynamoDB builds an unordered hash index on this primary key attribute. Each item in the table is uniquely identified by its hash key value.
We also have a DynamoDBTable attribute applied to the class itself, this has a value indicating the name of your table, so make sure this is the name of your table too! If you created your table name as CharacterCreator then the above should be fine. Save your CharacterEntity.cs class and open the CharacterCreator.cs script next.
Now we will add some public and private fields to the top of this class. These will store our Cognito AWS credentials, a reference to our DynamoDB client, and a context for DynamoDB to use. They will also store a list of characters pulled from the table when the scene loads, and store the currently selected character index value. Add these just below the comment “// Add AWS specific variables here.” on line 57.
We’ll now add a Context property with a getter on it to return our DynamoDB context each time we need it by creating an instance and passing in our DynamoDB _client reference. Add this below the “allSprites” Sprite array field, just before the method call to Awake().
The context is used as an entry point to your DynamoDB database. It provides a connection to your database, and enables you to perform various operations against your tables, mostly of the CRUD type (create, read, update, delete).
Now that we have a context setup, we need some methods to load CharacterEntity objects that are pulled from our table, and to switch between loaded characters in our UI. Add the following three methods to your CharacterCreator class.
The LoadCharacter method will take a CharacterEntity passed to it, and update the UI values to display the properties stored in the entity, in our UI. The Cycle methods will be assigned as listeners to our Next/Previous character buttons, so that when you click these, the character selection in the UI updates and changes to each character that was loaded from the DynamoDB table.
Add the following listeners to the top of your Awake() method call.
You may notice that we do not yet have the CreateCharacterInTable and FetchAllCharactersFromAWS methods created, and these are referred to by our create and refresh Operation fields. These will map to the create and refresh buttons in our UI. Let’s get started on those next.
First we’ll create the Load method. This will load our DynamoDB table asynchronously, and once done, execute a callback method that will use the Context to do an asynchronous scan of our table for all CharacterEntity objects that meet the condition of “Age” is greater than 0. In other words, all characters should be returned.
This is fine for the tutorial, but if you were working with large sets of data, a scan operation is not the most efficient. You would rather use a query operation to zero in on more precise bits of data you require. The SDK documentation has lots to read about this, so feel free to explore that later!
Once the async scan operation completes, it assigns the results (which will be a collection of CharacterEntity objects) to our characterEntities field. This allows us to then iterate over them and load them / cycle through them in our UI. Drop this method into your CharacterCreator.cs script.
Now we need our CreateCharacterInTable() method. Drop the following method into the same script.
This will create a new instance of CharacterEntity type, and assign the properties with the values entered into the UI fields, like Age and Strength. It will also grab the values assigned to the fields that keep track of what character components are selected in the UI, like “selectedHair” and “selectedShirt”. Finally, it will use our context to DynamoDB to async save our CharacterEntity to the table. Once this operation completes, the table will hold an entry for the character that was configured in the UI!
Before we can run any of this code though, we need to add some initialisation logic to our Start() method. This will only run once when the scene starts up. The following code will create some Cognito AWS Credentials by taking your identity pool string, and a RegionEndpoint specification. It will then asynchronously fetch an ID and initiate another async call after creating a DynamoDB client. This client is assigned to the _client field which will be used during run of the scene to fetch characters and create characters. After the _client field is assigned, the FetchAllCharactersFromAWS() method is executed to load all the characters up into the scene from the table. Add the following code to your Start() method in the CharacterCreator script.
You’ll notice that CognitoAWSCredentials object is created by passing in a string called cognitoIdentityPoolString. This is a public string that you need to assign a value to in the Unity editor. Go back to your scene, and select the CharacterCreator GameObject in the hierachy. Locate your Cognito Identity Pool Id that you hopefully noted down earlier (don’t worry if you forgot, just go back to your AWS console, load the Cognito dashboard, and edit your identity pool to find this ID). Enter the Id into the field on your GameObject.
One other thing to check here – make special note of the region you are using for your Cognito Identity Pool in the AWS console. If it is not US East 1, then you’ll need to change the code in a couple of places in the Start() method to specify your RegionEndpoint accordingly. Auto-complete will show you the other regions you can use on the RegionEndpoint. The two places to change are on creation of the credentials object, and the ddbClient object. Lastly, make sure the TableName specified in the Start() logic matches the name you used for your table (it should be “CharacterCreator” if you followed the naming convention when setting it up).
Ensure all your scripts and your scene file is saved, then give it a run from the Unity3D editor. If all goes well and everything is setup correctly, after a few moments the async calls should complete and the table should be initialised. There is a bit of debug text you can you view in the scene that various DynamoDB calls log to (you may need to increase the opacity of the font colour to view it. It is positioned just under the Refresh button).
So no characters will be loaded at first, as we have not yet created any. Enter a name and some stats for a new character and adjust his/her clothing and body types using the UI controls. Click “Create new” when you are done, and the character should be saved to your DynamoDB table in the cloud!
Note that when a new CharacterEntity is created, we give the CharacterID a new GUID value as the Hash ID. This ensures that every character created has a unique Hash ID value. If you wish to perform super fast lookup queries on your table you can create queries and search for these ID values.
Go to your DynamoDB console, select your table and click “Explore”. You should see your new character entry and see the GUID value that was assigned as its Hash ID. You’ll also see the properties that you selected in the UI saved into each row for each character you create.
Moving on from here
That is the tutorial complete now. We can see that there was initially a fair amount of ground work required to setup our AWS services, including Cognito, a DynamoDB table, and a custom IAM role, however using the Amazon SDK in our Unity3D project after this was done was relatively straightforward. The SDK provides lots of async method calls for you to utilise the various actions available to use DynamoDB tables. Remember that all the async calls can have a callback handler assigned so that you can execute code, or update values when the calls complete.
We didn’t use any table queries, or look into deleting entries, however the SDK documentation has lots of examples for you to try out if you wish to explore these areas further.
Going forward, I’m sure you can think of tons of use cases for DynamoDB and Cognito. One simple change I could think of is that you could identify users by unique login and store all of their own personal characters in the DynamoDB table. When they login using Cognito (you could provide a login dialog box in the UI), you could use Cognito to generate them temporary credentials to pull down their characters, and save/modify them on a per-user basis.
If you didn’t know too much about NoSQL databases, then hopefully this article also helped you out there. There are lots more out there. I have personally also tried out MongoDB, running in the Microsoft Azure cloud, and found working with it just as easy as DynamoDB, although the way documents are stored is slightly different. It wouldn’t take much to change this project to use MongoDB if you were feeling adventurous and preferred to try that out instead.
Finally, here is a link to download the complete Unity3D project, or to get the source from Github if you wish to get to the end point. Don’t forget to fill in the Cognito Identity Pool String on the CharacterCreator GameObject though, as I have removed it for the download due to it pointing to my own personal identity pool!
I’ve been quiet for the last few months – looking after a pregnant wife, preparing for a baby, and lots of work (my normal day job) has kept me very busy, and meant I have not been able to update this blog as often as I wanted to.
Now, with my son born I’ve had a little bit of time this last week to fix a few bugs in the code and capture the last few months worth of updates and changes to Space Pillage in this video! Here are some of the new features and improvements (listed after the video)…
Here is a list of the items I’ve added, improved, or fixed (the ones I could garner from my list of git commits over the last few months that is!)
Massive UI overhaul (especially main menu system)
Weapon and ship module hardpoint system linked to skill/stat system
Audio improvements and a dynamic music system (music changes with game events)
Easy level event system added – you can see an example with the asteroid field event in the video – all defined in simple to use XML now 🙂
Tooltips on UI elements that are important
Added parallax relative to player movement for layers
Added boss with modular laser / gripper combination
Add improved hit effects for enemy bullets when they hit player hull or shields
Modified player damage particle effects for fire and smoke to take into account scalable player health (based on player stats)
Created Tractor Beam module for ship and only allow tractor beam usage when it is equipped.
Many more fixes and improvements…
Also to note on the sound and music side of things, I’ve found a couple of excellent composers. Music and SFX contributions so far are from David Levy (http://www.davidlevymusic.com/) and Ashton Morris (http://www.ashtonmorris.com/). Ashton originally created some music for my iOS game Cosmosis which never made it into further updates on the Apple store, so I’ve brought that to Space Pillage. David has some excellent free music and SFX resources that I’ve been prototyping with, and is able to compose original sound tracks too, so I’ve been looking at that route for music too.
In Space Pillage, various bits of the game are randomly built using modular assets. One of these types are the space ship hulls / interiors you fly through (or over) in the game. This is a quick development update showing how the interior graphics are randomised and created as needed for the game.
These interiors, for now, are purely in for aesthetics and atmosphere. There is no current gameplay usage for them, other than to possibly be part of missions or the story. However, there is a spawning system behind them (like many other assets), that players are able to leverage and modify themselves.
To spawn one of these hulking space ship hulls that fly past as part of the parallax layering system in the game, the modder just needs to add a couple of lines of XML to the level descriptor files in the appropriate place (which determines when these items spawn).
On spawn, the code attached to the template object that is used for a space ship hull item randomises all the middle pieces to create some variation. For now each hull is made from 3 x modular pieces which are randomly placed, with two different end “caps” that don’t move.
I’ve modified the script to run in the Unity Editor, so it is easy to demonstrate. See the below GIF for a low-res demo (Make sure you click the link to view full screen)!
Here is the end part of one randomised space ship hull as it would appear while flying by in-game:
In terms of code, it’s not that special or pretty either. My excuse is that I wrote it on the train on the way in to London during rush hour last week 🙂 What you do, is:
Attach this script to an empty parent gameObject, and then add sprites as children of the gameObject that represent each piece of your full object.
Position them with each graphic you want to use as they should be positioned, and ensure you name the gameObjects “Panel1”, “Panel2” etc…
Make two end “cap” pieces that will not be moved by the script (name these “LeftCap” and “RightCap” for example).
Drag and drop each “movable” child panel sprite gameObject onto the script’s “Object Pieces” IEnumerable (List) field which should at first be empty. This gives the script the items it needs to re-position randomly when the main “parent” gameObject is enabled. (The script only works for the OnEnable method). Make sure you don’t drag your two end “cap” pieces into this field though, as you don’t want those moved.
The script is set to “ExecuteInEditMode” so if you enable/disable the script in the editor, you should see your items move around each time.
This post covers my first Space Pillage dev update. It will do a quick run through of the design and thought behind the customisable / modular weapon system I have created for enemies found in the game. The customisable weapon system package is actually something I created a while back for this game. I decided at the time to submit it to the Unity asset store (you can get it off the asset store here).
My goal was to integrate it with my custom enemy and enemy wave specification files for levels. Basically, every enemy wave has a definition in XML. This means that a player (or myself as someone who designs level for my game), is able to define what enemy waves consist of (enemy count, the way enemies fly in patterns, health points, XP, rotation, speed, and many other properties), as well as the order in which they arrive in the level.
The system I built this week allows me to now define enemy weapons. Each enemy “template” in the game has a specified number of gun placement points. When you define an enemy for a wave, you are now able to also define the weapon systems that get placed on each gun placement point in XML. When the game loads a level, enemies are then generated using these entries, which means that you, as a modder, level designer, or player are able to make custom weapons for enemies – fast shooting, arc firing, shotgun-like, multiple bullets, chain guns, just about any kind of weapon is able to be created by giving each gun placement point a definition.
Here is an infographic / design I put together to illustrate how this works.
Here is how this particular enemy looks where I have made 4 x configurations – 1 that shoots two bullets at a time in a fast fire rate, arcing pattern, and 3 that fire single shots at a reduced fire rate. I set the bullet colour to yellow too.
A typical gun specification looks like this in XML:
Well, I hope that was an interesting update for those of you who enjoy design / inner-working type posts 🙂 Please do give the game a watch here on IndieDB – I’ll be posting more stuff like this, as well as updated screenshots, videos and hopefully even a playable demo in the near future! Please don’t forget to watch/follow the game on IndieDB:
I finally came up with a name for the game I have been developing over the last 8 months. “Space Pillage”. I have also got the basic concepts and ideas behind the game down, and as such was able to put together some artwork and media to represent the game on IndieDB.
I submitted the game to IndieDB over the last weekend. A day later it was approved, and so I now have an official IndieDB entry for the game! Please do check it out, and watch the game there if you wish to follow development progress or show your support – it means a lot! 🙂 I will endeavor to post updates there, as well as here on this blog.
Game progress has been a little slow lately. I’ve been doing a bit of contracting work in the evenings and I’ve also had a pretty intense training routing on the go for the last few months in preparation for a Spartan race which I am participating in this week. That doesn’t mean I haven’t tried to put effort in wherever possible though! This post will detail the latest general progress update.
I’ve been working on general updates, bug fixes and feature additions to the game, as well as some graphical enhancements. Here is a list:
Dialogue bug fixes with layouts and buttons not responding at some resolutions
Better spawning system created for planets/random objects – the new system uses a ‘probability’ factor in the XML configuration files. So you could for example specify that a level has 5 different kinds of asteroids that spawn every 0.5 seconds, and of these 5, the 3 x smaller ones have a 90% chance of spawning (30% chance for each type), whereas the 2 x larger types split their chances of spawning, so each has a 10% chance to spawn. I implemented this system using C# Generics and an interface, so it is fairly flexible and can be used for other purposes too.
More graphics! I’ve created some new parallax layer pieces that are used for certain layers in the scenery. These are space ship / hull / space station interiors, that give you the illusion of flying through old creaking, damaged space stations. I think they look great, but I’ve still got to figure out how I’ll use them exactly. My plan might be to use them for certain game events/tasks during game play to add to the story. Some of the pieces have moving bits like platforms that rotate back and forth, or ‘power core laser beams’ that arc across sections.
Fixed some bugs to do with parallax layer ordering – these were simple to fix, as you define backdrop/parallax scenery layer configurations in simple XML files for each level, and I had simply specified the incorrect layer IDs for some parallax planets/asteroids (planets were appearing in front of asteroids instead of behind)
A few interesting bits and pieces for visual flare – for example, small miner nodes that hover around some asteroids and ‘mine’ them in the background.
Here are some recent screenshots…
Interior space station parallax layer
Nuke activation and general destruction
Power core laser parallax scenery
I am hoping to have a development / progress video log out again soon – I’ll need to work on a name for the game first though!