Almost done!

All behaviours are now implemented including a combat group based tactical retreat. It all just needs a little tuning now. The main blocker at this point is just a slew of editor bugs, specifically with behaviour trees. Hopefully they’ll be fixed soon.

Cover pass 1

Work in progress

Over the Christmas holidays I implemented the base of a cover system including the AI. It’s pretty raw right now and there’s a lot that needs ironing out, but it’s getting there. The AI selects cover based on their current weapon and the players last known location. Cover can also be invalidated in a number of ways by the player. The next steps will involve augmenting the group logic for the enemies with tactical retreats and advances to create some real flow and movement to the encounters.

Cover volume construction script

While we wait for the next round of concept art for our Midnight project, I’m working on a cover based shooter in UE4.

Auto generating cover often yields messy results so I’ve opted for a hand placed solution, and this little script just makes that process far far less painful.

Initial Doodles

I’ve recruited (OK, more like persuaded) the very talented Damian Buzugbe to work on the game.

Damian is a concept artist who has been in the industry since time began… or at least, longer than I have. Most notably he was the lead character artist on the Fable games. Check out his blog: Here.

So here are some extremely early doodles of our game’s protagonist – an attempt to capture the form of a middle eastern refugee but in a more abstract and more fantastical style.

early concept

Prototype tile system

This is a Unity prototype of a dynamic world that’s the center of a small game I’m currently working on. I’m now porting the project to UE4 which should be pretty fast, but in the meantime I thought I’d share.

This system provides an open world experience while allowing us to tell a very linear story and have it not feel forced. The player can walk in any direction they choose, but once certain conditions are met the next chunk of world that instantiates will contain the characters or setting for the next beat of the story. If you turn and walk the other way you’ll find it appearing in front of you again. The story is, in part, about unavoidable events in a person’s life and I think the gameplay mirrors this nicely. You seem to have choice, but in actual fact what happens to you is already predetermined.

Here a system of slots arranged in a hexagonal grid maintains the pieces that you walk on, and can choose to instantiate a special tile from a queue if the conditions are met.

Ignore my awful designer / programmer art and the hideous Unity default character.

Porting the project to UE4

My god UE4 is fantastic. The level of thought that’s gone into the system is phenomenal.

After having played around with it for a short while and done some prototyping for our current project, I’ve decided to switch my side project over from Unity.

One of the main reasons for this, apart from how easy it is to use, is that we now have an animator on board! Very exciting, and UE4 has far superior animation systems.

I’ll start posting videos of the game very soon – I’ve re-worked the core system to support some pretty cool stuff in our little dynamic, procedural world which I’m looking forward to unveiling!

Playing with curves

Ok so I think this is pretty cool. I also think this is one of THE ways you should create core mechanics.

Simply – I’m creating a jump in a game, but this is so important to get right. A good jump is a little bit of positive feedback every time you hit the button. It can be addictive and genuinely fun. A bad jump makes you feel like you’re fighting against the controls. In fact most people don’t notice when a jump is good or bad, they just like one game and not the other and they don’t know why. This stuff is important.

So this is how I’m doing it –

I’m using this easing function generator to create and tune the appropriate curve and then converting the function into C# and plugging it into my code. This is the initial result using a standard curve, it’s not right yet but it already feels like it’s on the way.

Next I need to gut that site’s (very kindly freely available) code and create a solution that will give me more control over the curve and allow live editing

A Case For Violence

Ok so first I want to start by saying that I am thoroughly bored with violent games. This all came from trying to think about something that could truly replace it. But why is violence so popular in games?

So here’s a couple of theories.

1. Violence is easy to program. It’s far easier to program some bullets and health than it is to program complex interactions. Artificial intelligence too is much simpler when all it has to do is run around and shoot at the player. Kind of a dull point though this one, and there are always ways around technical problems.

2. Violence provides players with something to master. You see my first thought when thinking about replacing violence was something like an adventure game in which you try and find, say, a long lost sibling. You could build an entire game around this and there could be a myriad of challenges along the way involving meeting and talking to new characters mainly – but the mastery would be missing. That one core skill you practice again and again and are ultimately tested on. You could build a game without it, but something would definitely be lost.

So let’s just replace it with something – for the sake of argument let’s change the story. You’re a tennis pro searching the land to become the ultimate player. You travel in search of new challengers. But the problem with this is that it doesn’t provide the bite sized challenges that violent games do – you’d be limited to less, more meaningful encounters because a game of tennis takes a significant amount of time.

Violence is actually very well suited to a medium in which progression is so key. Bite-sized encounters hone your skill ready for the ultimate test at the end. Also from a more abstract design point of view, violence works nicely to clear the path of the blocking challenger once you’ve bested them, allowing you to continue on.

There is a lot that you get for free with a violent game mechanic – it fits games very well. In fact even in the real world you’d be hard pressed to find something that allows small meaningful rounds of challenge better than fighting does. I’ll keep thinking though..

…perhaps a game about a wondering debater in a world full of the opinionated…

Perhaps not…

Ultimately I think the answer is to simply come up with some activity and an excuse for why everyone challenges you at it, like Pokemon. Surely though there must be a more elegant solution…

A good way to die

“Be good at our game or we’ll make it less fun for you” should not be a design mantra. That’s why I dislike the harsh death penalty in the latest Zelda game, A Link Between Worlds, that ultimately sees you having to re-tread vast portions of the game to re-try what it was that beat you in the first place. Ultimately the penalty for death is time – fail and you lose 20 minutes. This is harsh indeed, not to mention tedious. This poses an interesting design question though – how do you create a meaningfully harsh death mechanic that doesn’t take away from player enjoyment? Many indie games have harsher death mechanics, but quick restarts and shallow gameplay mean you are dropped back into the game doing exactly what you were doing before you died. Super Hexagon or Hotline Miami for example. The other archetype is the game that challenges you to get to its end. FTL or Hoplite both do this – death is harsh, you have to restart the game, but games don’t last long, so again, this is not so punishing, in fact it’s a formula that has existed since the advent of the arcade cabinet. As long as the game is consistently fun, then the repetition is not tedious and death is not too punishing. The real trick is implementing a good death mechanic in a longer, story-based game. So here’s a proposal – one possible answer lies in your absence from the world. When you die, the world keeps running rather than resetting and the penalty comes from not being there to help. This would work well if, for example, you have squadmates who die permanently, or in multiplayer – We don’t specifically punish you by docking your score or character progression, or by making you repeat a section, in fact you’re technically getting a second try, but things escalate more while you’re away so it’s a scramble to get back into the action, and if done right this should be fun rather than a chore. The penalty is not what happens to you, but what happens to everything else while you’re gone, and if you design the game right this all just happens naturally and in an emergent way. All you have to do is create systems that fight each other or tick over without you. I recently managed to add this concept to a game relatively late in its development – although it’s not always possible to make changes to the core game later in the process, we compensated by placing elements in the world that the enemy tries to attack. When they’re destroyed they’re gone for good – die and you’re re-spotted away from them leaving them vulnerable until you return. This is an imperfect solution, but it did add a nice meta-game for the more advanced players – can you complete the game with all of these elements in-tact? It had a nice knock-on effect of letting better players choose a more challenging game.