Mr Nibbles Forever – Prototype 2

Mr Nibbles Forever – Prototype 2

So its almost a week on since the first build of Mr Nibbles Forever and a fair bit of work has gone into the game this week. Its starting to take shape a little more now which i’m happy about.

I had a few people play the first Prototype last week and the overwhelming response was that it was too hard so the first thing I did this week was to make the game easier. So I slowed Mr Nibbles down and making the tilting of the device more responsive. Then I added a difficulty progression to the game. The longer you play it the harder the game gets. Check out the difficulty progression in the video below:

I achieved the difficulty change by ranking each chunk by difficulty then selecting an appropriate one randomly as the player moves along.

2015-01-24_17-26-15

As can be seen in the video there are now 3 themes that the player progresses through as they go along. This mirrors the 3 stages that can be found in the original game:

2015-01-24_17-30-23

I worried about this for a little while as I wasnt sure how to get the three themes in the game and make it work. The solution was to have transitions between the themes and have each theme more difficult from the last so that as you play from the cage to the backyard to orbit the game progresses smoothly in difficulty.

Because the game now features three distinct themes I needed to upgrade my chunk building tools to accommodate the different tiling requirements for each theme:

Building tilesets is now a breeze thanks to custom inspectors and other editor tools.

2015-01-26_07-52-03

I have a long list of features building up on Trello:

2015-01-26_07-46-23

But this week I hope to have most of the chunks complete and have started or finished work on the meta-game. What is the meta-game? Well find out next week ;)

BTW, if you are interested in testing the game on iOS send me an email: mike.cann@gmail.com and ill get you added as a beta tester. If you are on Android then simply join this community: https://plus.google.com/communities/100690884724496136044

I also have a facebook community for the game now too: https://www.facebook.com/mrnibblesforever

Mr Nibbles Forever – A Prototype

Mr Nibbles Forever – A Prototype

About a week ago I had an idea: what would Mr Nibbles look like if it was turned into an endless runner? Well in-between other things I knocked out a gameplay prototype using my weapon of choice these days, Unity.

After just a couple of days I had the basics of the Mr Nibbles game mechanics working, its amazing how fast you can make things in Unity when you have all the assets already:

The two fundamental ideas I had for this game was that you couldn’t ever stop running and the levels would be randomly generated. You can control the speed of Mr Nibbles by tilting the device (or using the arrow keys) but you cant actually bring him to a stop or cause him to turn around like you can in the original.

This restriction creates an interesting mechanic where you have to carefully control your speed through the air as not to land on spiders.

Speaking of spiders, I always thought they deserved a little more motion to bring them alive so now they can jump a small way out towards Mr Nibbles when he gets close:

As for making the the game endless, I needed a way to proceduralally generate Mr Nibbles levels. The easiest way I could think of doing that is by breaking up levels into small sections called “chunks” and then stitching those together as the player moves along:

Chunks must have an entrance and at least one exit tho they can have multiple exits which makes for some interesting player choices:

2015-01-16_14-35-50

For now there are 26 chunks in the game and they are randomly picked as the player moves through the world. The idea is to grade these chunks by difficulty and the longer the level goes on for the harder the chunks spawned are.

2015-01-16_14-55-282015-01-16_14-56-422015-01-16_14-57-49

To help with building chunks I took advantage of what I consider to be the single greatest strength of Unity, its tools customisability, to write some level building and testing tools:

After the hard work was done it was just a matter of adding a little more polish, some basic menus and sound effects and a few more game mechanics such as destructible floors and spring traps.

So for now the game is very basic, there is no progression and nothing in the way of challenges. My thinking is if people enjoy the raw gameplay in its prototype form then I can add Jetpack Joyride style missions and more varied themes and powerups and more mechanics.

So this is where you can come in, give the game a try, see what you think and let me know by leaving a comment or emailing me at: mike.cann@gmail.com

You can download and try the desktop version here: http://goo.gl/yDAFUm

Or you can email me and ill send you a link with the iOS version so you can play on your phone or tablet.

Unity-Ash Upgrades

Unity-Ash Upgrades

A while back I decided to scratch an itch and see if Richard Lord’s Ash Entity Framework could be ported to Unity. Well I was pleasantly surprised that it did port quite easily (with some help from David Arno’s .NET port) and worked well enough that I could also port Richard’s Asteroids game over to Unity too.

Since then I have had a few people contact me interested in using the port for their own projects so I decided to give it a little more love and polish.

Part 1 – Separation

First things first was to split the Ash library from the Asteroids example project so you dont have to include the entire Asteroids port in every single one of your games (madness). So now the Unity Ash project can be found here:

https://github.com/mikecann/Unity-Ash

..and the Asteroids project (which uses the Untity-Ash project) lives here:

https://github.com/mikecann/UnityAshteroids

Now all that you need to do to is to clone (or include as submodule) Unity-Ash into your game’s Assets folder and you should be good to go, simples!

Part 2 – GetComponents

Next up was performance. I knew that the performance of Unity-Ash was the biggest stumbling block and unfortunately it seemed like a fairly fundamental one thanks to some holes in the Unity API (more on that later). However, I knew there were a few low-hanging-performance-fruits I could pick that should speed up things a bit.

To experiment with things I setup a separate Unity project for the performance tests and included Unity-Ash from GitHub.

2014-12-10_09-30-51

The key performance bottleneck in Unity-Ash is the way the code checks for component additions and removals. Dynamic component addition and removal is key to how Ash functions and in AS3 because it was all custom code we could just fire an event when a component is added or removed from an Entity. Because Unity-Ash tries to piggyback on top of Unity’s existing Entity (GameObject) / Component architecture we dont actually have access to the GameObject source and thus cant trigger events when a component is added or removed.

The solution I came up with is to add a component to each GameObject which acts like the Entity. It is responsible for checking to see if components have been added or removed, to do this it gets a list of all the components in the GameObject each frame and compares against its internal cache to see if any have been added or removed. This solution works well, however you can probably see the performance hit involved with getting a list of components from Unity for each GameObject, each frame will likely be quite high.

Because this listing of components was so crucial to performance I decided to write some tests to see what is the fastest way of doing that:

public class GetComponentTests : MonoBehaviour
{
	public int iterations = 10000000;
	public int repeats = 3;

	public GameObject noComponents;
	public GameObject manyComponents;
	public List<Component> components;

	public void TestAll()
	{
		components = new List<Component>();
		TestHelpers.Execute(iterations, repeats, "Empty Function", TestEmpty);
		TestHelpers.Execute(iterations, repeats, "Get Components With No Components", NoComponentsGetComponents);
		TestHelpers.Execute(iterations, repeats, "Get Components With Many Components", ManyComponentsGetComponents);
		TestHelpers.Execute(iterations, repeats, "Get Components With No Components List", NoComponentsGetComponentsList);
		TestHelpers.Execute(iterations, repeats, "Get Components With Many Components List", ManyComponentsGetComponentsList);

		Debug.Log("components " + components.Count);
	}        

	public void TestEmpty()
	{
	}

	public void NoComponentsGetComponents()
	{
		noComponents.GetComponents<Component>();
	}

	public void ManyComponentsGetComponents()
	{
		manyComponents.GetComponents<Component>();
	}

	public void NoComponentsGetComponentsList()
	{
		noComponents.GetComponents<Component>(components);
	}

	public void ManyComponentsGetComponentsList()
	{
		manyComponents.GetComponents<Component>(components);
	}
}

I run each of these 10 million times then repeat 3 times and average:

1) “TestEmpty” is my control test test to get a sense of the cost of simply calling an empty function. That averaged to 0ms elapsed
2) “NoComponentsGetComponents” I test getting a list of components when the GameObject is empty (other than Transform), that averaged to 22ms.
3) “ManyComponentsGetComponents” I test getting a list of components when there are 20 components (plus Transform) to see what the cost of getting additional components would be, that averaged to 35ms.
4) “NoComponentsGetComponentsList” is the same as 2) except I avoid an internal memory allocation my passing in a List to populate the return with, that averaged to 5ms.
5) “ManyComponentsGetComponentsList” is the same as 3) except I pass in the List again, that averaged to 15ms.

So in summary, I learned its much faster if I pass in a list to GetComponents, which makes sense as I avoid the memory allocation associated with returning a new array each time. As a result I folded this performance improvement into Unity-Ash.

Part 3 – Unity vs Ash

These tests are all well and good but 10 million iterations of GetComponents in standalone is probably an unlikely use case in the standard game so in addition I wanted to test what the actual performance hit you would get if you used Unity-Ash in a game instead of the standard Unity way.

To test this I set up another scene that creates and updates 5,000 asteroids on the screen.

upout

I time how long they create then I count how many frames I get in 10 seconds of updating them. Each asteroid has a 2D rigid body and a very simple controller script that wraps the Asteroids position on the screen:

2014-12-10_10-15-54

public class AsteroidController : MonoBehaviour
{
	private Bounds bounds;

	void Awake()
	{
		var size = Camera.main.ScreenToWorldPoint(new Vector2(Screen.width, Screen.height));
		bounds = new Bounds(Vector3.zero, new Vector3(size.x * 2, size.y * 2));
	}

	void Update()
	{
		if (transform.position.x < bounds.min.x)
		{
			transform.position = new Vector3(transform.position.x + bounds.size.x, transform.position.y, transform.position.z);
		}
		if (transform.position.x > bounds.max.x)
		{
			transform.position = new Vector3(transform.position.x - bounds.size.x, transform.position.y, transform.position.z);
		}
		if (transform.position.y < bounds.min.y)
		{
			transform.position = new Vector3(transform.position.x, transform.position.y + bounds.size.y, transform.position.z);
		}
		if (transform.position.y > bounds.max.y)
		{
			transform.position = new Vector3(transform.position.x, transform.position.y - bounds.size.y, transform.position.z);
		}
	}
}

This was the base test and it took about 440ms to create 5000 asteroids and processed 83 frames over 10 seconds (8.3FPS).

Now I had my base I decided to setup the same scenario but using Unity-Ash to drive the updates. So now the Asteroid looks like this:

2014-12-10_10-19-42

Notice that there is no controller for the Asteroid, now all the update logic happens in a system:

public class MovementSystem : SystemBase
{
	private Bounds bounds;
	private NodeList nodes;

	public MovementSystem()
	{
		var size = Camera.main.ScreenToWorldPoint(new Vector2(Screen.width, Screen.height));
		bounds = new Bounds(Vector3.zero, new Vector3(size.x * 2, size.y * 2));
	}

	override public void AddToGame(IGame game)
	{
		nodes = game.GetNodeList<MovementNode>();
	}

	override public void Update(float time)
	{
		var cam = Camera.main;
		for (var node = (MovementNode)nodes.Head; node != null; node = (MovementNode)node.Next)
		{
			var transform = node.Transform;
			var rigidbody = node.Rigidbody;

			if (transform.position.x < bounds.min.x)
			{
				transform.position = new Vector3(transform.position.x + bounds.size.x, transform.position.y, transform.position.z);
			}
			if (transform.position.x > bounds.max.x)
			{
				transform.position = new Vector3(transform.position.x - bounds.size.x, transform.position.y, transform.position.z);
			}
			if (transform.position.y < bounds.min.y)
			{
				transform.position = new Vector3(transform.position.x, transform.position.y + bounds.size.y, transform.position.z);
			}
			if (transform.position.y > bounds.max.y)
			{
				transform.position = new Vector3(transform.position.x, transform.position.y - bounds.size.y, transform.position.z);
			}
		}
	}

	override public void RemoveFromGame(IGame game)
	{
		nodes = null;
	}
}

The update logic is functionally exactly the same as the AsteroidController except its now contained within a system.

This time it took 595ms to create the Asteroids and we processed 33 frames over 10 seconds (3.3FPS).

So immediately you can see there is a large performance hit in using Ash-Unity over regular Unity (8.3FPS compared to 3.3FPS). To confirm that it was the extra overhead of checking for new components on each asteroid rather than the internal updating mechanism of the Systems in Ash I decided to turn off checking for component updates..

2014-12-10_10-40-02

Sure enough the frame rate went back up (in fact higher!) than the Unity update rate of 8.3FPS to 8.6FPS.

So with this in mind I decided to add an option to the Entity component that lets you choose how often it checks for new components:

2014-12-10_10-42-02

The reasoning is that its actually quite rare that you change the components after the initial creation of the object (at least that’s what I found) and thus by reducing the number of times the Entity component checks for updates we should be able to increase the performance.

Sure enough, when set to “Every Other Frame” the framerate goes up to 4.5FPS then set to “Every 10 Frames” it goes up to 7.4 FPS. The final setting “If Component Count Changes” attempts to skip the iteration of the components by comparing the number of components against the previous frame, this results in 7.5 FPS.

So the short of the long is that you can get the same as or higher FPS using Unity-Ash so long as you know beforehand how often you are going to be added or removing components. If you have entities that is likely never to have components added or removed then set it to update “Never” and enjoy great FPS with the power of using Ash.

Just as an addendum to this, I have submitted a feature request to Unity to add in events to GameObject that we can listen to that are fired when components are added or removed, this would obviously remove 99.9% of these performance issues from Unity Ash so I would love your votes:

http://feedback.unity3d.com/suggestions/componentadded-slash-removed-events-on-gameobject

As a final step in the upgrade process I looked at what more radical changes we could make to the framework by taking advantage of Generics and some other features that C# gives us that were lacking in AS3, you can check those out towards the bottom of the readme: https://github.com/mikecann/Unity-Ash

Well that’s it for now, I hope you enjoy the improvements, please to let me know if you think its worth carrying on development, I would love to work on it some more but I have games to write!