A nifty festival appearance

Last weekend, we had the opportunity to present our nifty little game at a local indie game festival. We only had a couple of minutes to pitch the concept and show a short demo of the game in its current state. The feedback we received was generally positive though not numerous. For those of you who haven’t seen us (and since no one had ever heard of us there, that should be all of you), we will post a video showing said demo. We will also shed some light on the ideas behind the game and its story.

Not for all Humanoids

You may have noticed that there used to be one more icon on our intro page, this one: android

Against our initial intentions, we decided to drop the support for the android platform. This has several reasons.

There are essentially two types of Adroid powered devices on which the game could run: tablets and consoles. The obvious way of controlling a game on a tablet is by using touch which is really unsuitable for the type of game we’re making. Sure, you could use a virtual joystick which would be added as an overlay, but in our experience they do not work as well as a controller or even a keyboard plus you constantly obscure parts of the screen. The console we planned to release for is this thing. While we like the OUYA and the idea behind it, some experiments have shown that the hardware is not capable of what we’re trying to do. The fill-rate of the tegra which they used for the OUYA and the limited flexibility of the supported shaders are just not enough. (In case you’re wondering what we need the graphics power for, stay tuned, you’ll see, eventually…)

The other reason is that we have our own engine. This is something really great if you want the flexibility to change things around and do stuff other engines wouldn’t let you. But it comes at the price of having to implement everything. Even tough T.H.E was designed from the beginning to support android, and a lot of the core logic runs just fine on our favorite humanoid machine, the graphics pipeline is quite different and the abstraction and re-implementation takes time. And time is something we don’t really have. We already are way past our original schedule and there’s still a lot to do, so we decided to spend that time on the game rather than on the engine.

That’s it for now. We hope to have more to show quite soonish, so stay tuned…

We’re doing science and we’re still alive…

…still alive, still alive…

Despite the lack of updates, the project is still being worked on. Over the last couple of months, we changed some things and added some more but the progress was sadly not as big as we hoped for. This is due to the fact that all members of our core development team graduated from university and had to work on their final project. (And yes, we are aware that we haven’t actually introduced ourselves, another item on the ever-growing todo-list.)

We currently can’t really say if there will be more or less time for the development of this game in the future, compared to the last half year or so. As always, we will keep you updated about the progress (eventually). We also hope to have more game-related content to share soon, so stay tuned…

Happy Holidays and a nifty New Year

This is just a quick update on what has been going on lately. The original plan was to have a demo ready by the end of 2013. Sadly, we won’t be able to meet this deadline. Because this is a side project which is only worked on in free time, the lack thereof has severe impacts on the overall progress. Even tough we could release the current state of the project as some kind of “pre-alpha preview”, it wouldn’t be a good representation of the thing we’re going for. So we’re going to post-pone the preview demo until it’s more representative, which should be sometime in the first quarter of 2014 (hopefully…).

Before the demo, there are going to be a couple of blog-posts about some things we’ve been doing so definitely keep an eye out for those. But until then, happy holidays and a nifty new year…

A nifty diary #3: generated enemies in their natural habitat and more

Lots of things happened over the last few weeks, none of which are particularly presentable. Since the blog has been quiet for a while, we’re going to present them anyway.

Feature creep
Feature creep is the scourge of humanity, or at least of software development. We have noticed some of the symptoms of feature creep – mainly the steady increase of features and the lack of increase on things like content – and decided to take action. So we defined a set of missing features which are absolutely vital for the game and we are determined to implement only those at least until we have a demo to show (wish us luck). We will post about those features as soon as there is something to show.

Data structures, memory and concurrency
The grid, the core data structure which handles everything contained within a level, has been updated yet again. The current (and hopefully final) version uses a sparse implementation and pointers to the position of an object within the grid. This allows for a delayed and completely concurrent access to every object. With this change we were able to separate steps of the update of objects which had to be executed consecutively before. This finally led to the possibility of a parallel game loop.

Parallel updates
Most CPUs nowadays have more than one core. This is great when you want to do multiple things at once but makes it difficult do utilize the full power of a CPU in one application. This is why even today, a lot of games are not parallelized to the degree necessary to do so. With the latest changes, we made a step into that direction. The logic of the game loop which calculates the behaviour of every game object in every frame is now capable of using multiple cores at once which should lead to an improvement of the framerate on lower end CPUs. Due to the architecture of OpenGL, it won’t be possible to parallelize the draw logic as well, so we won’t be able to use all the computing power which is theoretically available.

Procedural enemies
The enemy generator described in this post is now integrated into the game. While it does currently not unfold its true potential, it is still interesting to watch. We also added a similar but simpler algorithm for generating swarm enemies. The current state of this endeavour is demonstrated in the video below.

Procedurally generated enemies

As you may or may not know, one of NIFTY’s core mechanics (if you want to call it a mechanic) is random/procedural generation of stuff. We’ve been discussing quite a bit about what parts of the game should be generated and what should be just fixed (balance between time consumption and awesomeness). One of many aspect we really liked but didn’t know if it was feasible was generation of enemies because of the huge amount of expected time we would need to implement it. As it turns out, generating sprites (and models from these sprites) is way simpler than we dared to dream. It only took 1 hour from an idea to a working prototype and a few more hours to get the whole thing to a useable stage.

First some restrictions for our generated sprites were necessary to make the generation easier and to get a rough picture of what we want. The most important restriction comes from the idea that these sprites should look like they represent something and what does the human brain like to find the most in random things? Faces. Simply put, everything that has a symmetry and some kinds of dots in it looks like a face to us. Be it animal, monster or robot, if it has a face we know we can interact with it. That said, our first restrictions is that the sprites needs to be symmetrical. Our second restrictions is as simple as our first one, we want all pixels in the sprite to be connected to each other.

The second restriction can easily be satisfied by using an algorithm which builds on already set pixels and ‘grows’ them into a sprite.

Enough text for now, let’s start with some more specific instructions:

  1. Set a seed point in the middle of the sprite
  2. While not enough pixels set do:
    1. Randomly select a pixel that’s next to a set pixel
    2. Compute probability for setting this pixel (decision function)
    3. Set the pixel using the probability from 2.B
  3. Profit!

Well that’s it. Nothing spectacular here. One bit of magic is hidden in the decision function
but even if it always returns a constant value it already generates nice images:


By adding some lighter and darker spots (again at random) and changing the decision function we can influence the generated sprites more. In our case we want some ability scores (health, speed, power) to influence the look of the sprites so the player can estimate what type of enemy he’s looking at. Here are some examples of what the generator spits out in it’s current form:

healthHigh health: big, low detail

speedHigh speed: small, high detail

powerHigh power: medium size, high detail, more light/dark spots

Code excerpt
Here are two code snippets (in Java) from our implementation to give you some idea how it is implemented in NIFTY.
Note: the openList for storing points that haven’t been checked yet and the closedList for points that have been check are both of type HashSet<Position> .

Generation loop:

public void generate() {
	long seed = r.nextLong();
	r = new Random(seed);
	long time = System.currentTimeMillis();
	int iterations = 0;
	for (int count = 0; count < (w * h / 2) * fillPercentage; ++iterations) {
		count += grow() ? 1 : 0; // count amount of pixels set
	System.out.println("Runtime: " + (System.currentTimeMillis() - time) + "ms");
	System.out.println("Iterations: " + iterations);
	System.out.println("Random seed: " + seed);

Growing step:

public boolean grow() {
	// System.out.println("Open list size: " + openList.size());
	// System.out.println("Closed list size: " + closedList.size());
	int xx, yy;
	Position p;
	Iterator it;
	do {
		it = openList.iterator();
		p = it.next();
		// Randomly pick element
		int num = r.nextInt(openList.size());
		for (int i = 0; i < num; ++i) {
			p = it.next();
		xx = p.getX();
		yy = p.getY();
		if (pixels[map(xx, yy)] != PColor.EMPTY) { // Pixel is already set
			// Move to closed list
	} while (pixels[map(xx, yy)] != PColor.EMPTY);
	int countSide = 0, countDiag = 0;
	for (int ix = xx - 1; ix <= xx + 1; ++ix) {
		for (int iy = yy - 1; iy <= yy + 1; ++iy) {
			if (ix < 0 || ix >= w || iy < 0 || iy >= h / 2) // outside drawing range
			if (pixels[map(ix, iy)] != PColor.EMPTY) {
				if (ix == xx ^ iy == yy)
	// Check if we should set this pixel
	if (r.nextFloat() < evaluator.getPixelSetChance(countSide, countDiag)) {
		pixels[map(xx, yy)] = PColor.NORMAL;
		// Move point to closed list
		// Add surrounding points to open list
		addPoint(xx + 1, yy);
		addPoint(xx - 1, yy);
		addPoint(xx, yy + 1);
		addPoint(xx, yy - 1);
		return true;
	return false;

This enemy generator is neither finished nor integrated in the game yet, and the colors need some tweaking as well. We hope to be able to show the first completely procedurally generated enemies within the game soon…