From black powder to gibberish

Welcome to the first development update for 2016.

I’ve been constantly working on various systems and assets to build up a solid foundation. I want to finish a vertical slice through all game elements from mechanics to visuals. The goal is to get an idea of the size and shape of all the bits and pieces of the game before I start expanding.

So what has happened since the last update?

  • I built a first draft of a procedural quest system and worked on the environment manager
  • A 3rd party IK solution (Final IK) is now in place to drive all kind of (subtle) procedural rig changes like gun-aiming, head-aiming, feet-grounding, etc.
  • Added projectiles and ‘things-which-can-throw-projectiles’
  • Created a bunch of new assets like a few guns, some melee weapons, bags and particle effects
  • The usual performance tests, bug fixing, code clean-up, refactoring and last but not least: updating unity and 3rd party assets to stay up to date

CAool list of things – check. Now onto some real information:

Bla bla bla: a procedural quest system

Randomly picked quest elements build up a procedural quest

This is something I wanted to build from the very beginning. I often missed some kind of a story or long time goals while playing open world – survival – sandbox games. Even though procedural story systems fall short in terms of quality and soul they are perfect in throwing out quantity. Now what I don’t want to create is some kind of bring-me-10-bla-of-blabla quests machine. What I’m aiming for has more similarity to something like a road map: a system which gives the player a good reason to travel to certain regions of the world. A paper chase maybe. It should generate an unique journey each time you start a new game.

At least that’s the plan! A basic system is already running. It allows me to test the interaction with the environment manager and experiment with different ways of constructing short and clear (grammatically correct) sentences out of simple text modules.

IK or not IK – or: should we use third party assets?

dm_2016-02_finalIK

The feet align themselves to the ground level and angle

With the help of FinalIK I implemented the weapon aiming. Unity has a built-in IK system but FinalIK is simply better. It made me able to quickly add some additional features I normally wouldn’t have implemented. Why? Because they fall into the nice-to-have section. And there are many entries in there. Core elements first! But that makes me even happier if some make it into the game from time to time.

So, why should I use third party tools anyway? Well, they help out where Unity is lacking in functionality or quality. Most stuff I use extends the Editor. Just a minority ends up in-game. I try to keep it to the absolute minimum because it’s always a trade off: You gain time but loose control. It’s more likely that I use a third party extension if it just makes the game shine a bit more without being a hassle when it has to be removed. What I don’t do is use them for game mechanics like the described quest system or anything which would end up deep in the engine. Only exception: the network engine Bolt where it’s simply impossible to keep the integration shallow.

Guns, Lots of Guns

dm_2016-02_handmortarNow to something important. Not that I think guns are important per se but the game mechanic is. Implementing the complete functionality to hold, aim and fire “a tool which throws objects” was not a small task. But it did turn out to be quite interesting! For example watching a cliché American ex marine (yes, he’s the one from Full Metal Jacket) telling surprisingly interesting details about gun history and physics accompanied with beautiful slow motion shots. A perfect reference.

It’s blue light…

dm_2016-02_candledm_2016-02_candle2 So as we’ll dig, run and fight through many dark caves and tombs we might want to be able to see where we are before getting killed. One very effective way to do so is to use – light.

A few days ago when I was writing the first paragraph of this article I realized I didn’t had a proper night in game to showcase lights. I had to expanded the environment manager to support a real day-night circle with changing sun color and intensity and stars for Unity’s procedural skybox shader.  But I made it! I made the game dark. What a hell of a developer I am.

There will exist various ways how to utilize light and I made sure to go with deferred rendering and HDR lighting to be able to draw enough brightly glowing lights on screen to support that goal. The different light values (color, brightness, ‘fuel’, etc.) should have an significant effect on gameplay. The most obvious is of course… being able to see something.

And now for something completely different…

There are more things I’m working on but they’re hard to showcase or need some more polish. Anyhow: 2016 is going to be an exciting year with a lot of cool stuff coming up.

I’ll keep you updated!

Huge Update Video

Hi there!

Here’s now an updated video presenting the current state of the development. As already mentioned most of the work went into systems deep inside the core of the game. All difficult to showcase.
But it’s really great to finally be able to present what I was working on.

Following next is to build the system behind the dwarfen base camps.

First screenshot of the current version

dm_2015-10_worldGen

After more than one year of development I’m done with the biggest part of the underlaying engine (on top of unity of course). Most of the time was spend with programming but I also redid the player model and the mecanim system, built some new props, switched to normalmapped and tesselated world textures (if this is not going to kicking me in the back one day…), switched completely to PBS, deffered rendering, linear workflow and implemented most of the image effects I need.

I’m already quite happy with the look of game and over the next months further finetuning will bring it even closer. It’s always difficult to decide how to split the time between code and art but it’s dangerous to let one fall back too far. Turned out it was a good mix so far.

Next to come: some ingame footage.

Previously…

h_previously

Here we are. New blog – first post.

Let’s use this to sum up what has happened up till now.

The very first version of the voxel engine was created at the end of 2012 by a group of colleges of mine in unity. I guess we started with Unity 3.something. At this time I wasn’t involved into any programming yet. The world had a fixed size and only one layer of blocks. The engine was used for a mobile game which sadly didn’t made it out to the public yet. You’ll find most infos still on this page.

I guess my first real contribution was a system to combine all level meshes to one object to save drawcalls. I called it MeshCombin0r and it soon became a rich source of new tasks. At that time every peace of code was running on the main thread and you could notice when blocks changed by the annoying hiccup every time the mesh had to be recombined. The newest iteration of that system is just a few weeks old and I doubt that even a single line of code has survived from the first version I wrote over the Christmas holidays 2013.  It runs now on multiple threads (like most of the heavy work of other systems) and works 1000 times faster.

At the beginning of 2013 we split our engine into two sub engines. A more generalized, higher level abstraction which was able to handle blocks and the other part for gameplay mechanics for Octolab what Dwarf Digger eventually became. The higher level “block-engine” became the seed of Dwarf Mines.

The production itself started in mid 2014 after a tough phase of network engine research and development. I developed a system which was capable of state replication but in the end I couldn’t overcome Unitys shortcomings (at that time) to build a real authorative solution. After all I decided not to build low level solutions for the game myself (like GUI or networking). So I choose bolt instead.
I’m still glad I did.

dwarfM_001

The game is now able to produce randomly created worlds based on specific rules you can visually setup in the unity editor. It’s possible to place and destroy structures. There is an inventory system capable of all the usual stuff and even the exchange of bags with content like the ArmA games use it. You have a gta3 like camera navigation expanded with some tricks to work even under ground in close quarters.

What’s up next?

Now comes the fun but difficult task of implementing all the gameplay mechanics. Also the interface needs to be made even though it’s already working from the technical side. And a few core features which are still bit tough to get right (I just say “global pathfinding”).

Over the next weeks and month I’ll outline some of the components which are already on duty and of course  talk about new concepts and developments.

Cheers!