Rollin's Forge – > game(art) dev blog

Pre-alpha 0.3: accomplished!

rollin |

8. February 2019 |

Slowly but steadily.. I guess this is the best way to describe the development of Dwarf Mines. Today I want to announce the completion of pre-alpha 0.3. As planed the game can now be played via internet on a dedicated server. But obviously that’s not all and not everything did run as planed: It took me nearly a year to finish this update. But I think the result was worth the effort and over the following weeks I’ll show you what has changed.

Small cattle…

It was important to me to do a full round of debugging, enhancements and refinements this time. Incredible how much work is hiding behind those generic tasks. I have weeks over weeks of this in my past schedule. But I have to emphasis that maybe the most important work was done there: The performance is way better now and the game needs just a fraction of the previous system memory.

Of course I could just have skipped over it and instead focused on the next big things. But eventually the whole project would collapse into a mess of unmanageable code and bugs that are caused by bugs which are caused by even more bugs. And even though I constantly try to keep a clean codebase there is often room for improvements after a round of development.

Performance comparison of 0.2 and 0.3 with max details

GUI progress

If you are a Unity developer too you probably know that Unity’s OnGUI() system is very slow. But as it’s also very handy for prototyping I use it a lot. But eventually I have to port game related GUI code over to the much more powerful Unity UI system. In the past I have already done that for the whole main menu and the inventory. Now the constructor (required for placing structures) and the individual structure screens followed. As most of the GUI interaction in Dwarf Mines runs through structures this was a very important step and also quite a huge task. As there where multiple screens to convert I took the opportunity to implement a complete system to streamline the process of creating GUI screens. It’s now as easy to use as the old OnGUI() system. And thus it allows me to add new GUI screens with minimal code.

Comparison of the sawmill GUI before and after the port. Beside the technical improvement the GUI still use placeholder graphics and the layout isn’t final

As a side node: I have implemented my own colour picker as I wasn’t really satisfied with what I could find on the assets store.

Tinting garments will be possible even though the final “how” isn’t decided yet

Playtesting

For this update my overall goal was to make the game ready to be played by people other then myself. Obviously I can play it in the editor but that’s not the same. Therefore, beside evolving the GUI, I improved the overall usability. As mentioned before I currently use itch.io as distribution and patching service. From now on you can visit the project page here:

To be able to link the game to a shop’s account system Pre-alpha 0.3 now includes an intern account system. It can run on its own (using my own authentication server) or linked to an external shop account (e.g. steam).

This allows me to already use and test it during production.

Bug reporting

As the purpose of testing is to find problems I have integrated a bug reporting tool to make the process easier. It allows the tester to quickly send a short bug description together with a log file and screenshot to me. Having a screenshot and the console output often helps to track down issues way faster then relaying just on bug descriptions. The bug reporting system uses functionality of the TouchConsole Pro asset, adds additional data and then sends it to my bug database.

What comes next

Now after 0.3 is out of the door I’m focusing on AI again. The goal is to bring enemies, NPCs and other creatures into the game world. In connection I will work on the fighting mechanic, improve the dialogue system and everything else related to AI creatures. And I want to add the first bunch of sounds to the game together with an overhaul of the sound system. As usual all details can be viewed on the roadmap.

Roadmap

Quite some work to do for 2019. So let’s get started! :)

Until next time with more news about 0.3.

Goodby 2018 – Final remarks

rollin |

3. January 2019 |

DwarfMines

Hi 2019! I hope everyone had a few nice days between the years and that a great new one is coming.

The last year was a very busy one for me. Beside working on Pre-alpha 0.3 I also did some contract work to keep the whole thing running. I don’t feel I should do a kickstarter at this stage though (funny how much effort you have to put in before “kickstarting”).

However: Pre-alpha 0.3 is now in the last phase of testing and features some really nice unexpected additions. I’ll go into greater details about this next time! And even though the game has grown way bigger then it ever was, the current version is the most stable one. Primarily thanks to extensive testing and bug fixing and me favoring stabilizing existing features instead of adding a ton of new (broken) ones.

But today I want to cover a few new features which didn’t made it into their own post yet.

The new preview system for placing construction sites

Engineering 2.0: New Construction Preview

I’ve improved the way how placing construction sites work. As before you see a transparent preview of the structure you want to place. But now you can put it somewhere. And you just need one solid block as starting point. So no more guessing why you can’t build. Just place the preview and work around it to remove any intersections or holes in the foundation. As soon as all preconditions are met the preview is automatically replaced by the construction site and you can start with the actual construction.

Engineering 2.0: Lanterns

This is a smaller change but an important one. It allows structures to carry the same kind of attachments as actors (e.g. a helmet) or items (e.g. a candle on a helmet). Of course they don’t carry helmets but maybe a candle. This makes items now even more important and structures more customizable.

Constructions use a basic stability system

Engineering 2.0: Anchors and stability

Something super important I nearly forgotten to mention: The new stability system. It defines where and how structures are connected to each other or the ground. Say you would build a bridge without pillars. At some point it just has to collapse.

Now every structure you place is anchored to it’s contact surface. In most cases this will be the ground below but some structures can even be placed on top of other structures (like pieces of a pillar) or on walls. If a structure looses its last anchor it collapses – which in turn might cause other, connected structures, to collapse too. That way certain types of structures even become meaningful (pillars) and awkward looking constructions are less likely to show up.

Btw: everything for now without “BlingBling” or eye candy. First getting the systems right.

Looking forward

As I told you: Pre-alpha 0.3 isn’t far away anymore and I’m eager to show what’s new. And Pre-alpha 0.4 will bring the first AI creatures to the game and I can’t wait starting to work on it. So chances are 2019 will be at least as busy as last year.

Thank you for visiting and see you soon!

Pre-alpha 0.2 – Screen space sub surface scattering – masked per pixel

rollin |

17. August 2018 |

DwarfMines

Hi there and welcome to a new development update. This time I want to talk about skin shading or more generally speaking: sub surface scattering (SSS).

SS-SSS

I had already implemented a solution for SSS on a per object basis for quite some time but it required the objects to be rendered in a forward rendering pass while the game now primarily uses deferred rendering. I can’t simply convert the shader to deferred rendering as in this mode the required light information is not available for object shader. As mixing deferred and forward rendering for half transparent objects is already annoying enough I eventually fully switched to deferred rendering for all opaque objects. But this forced me to find a new solution for rendering SSS. From all currently known solutions I chose to use a screen based approach. For now without any depth analysis.

There is one restriction though: it should be possible to mask the SSS effect not only per (sub-) mesh but also per texture. I wanted to be able to avoid splitting models into multiple submeshes just to realise different SSS parameter on a single object. Therefore, before applying the SS-SSS effect, I had to mask not only the required objects but also the affected texels.

But – of course – it didn’t turned out to be that easy. In Unity the usual approach in this case would be to render the scene using a replacement shader to a black and white mask. But this approach would have forced me to create replacements for all possible shader in the game. You can read more about replacement shader in Unity here. In my case it turned out I would have to write additional replacements for all shader doing vertex deformation (e.g. the tessellation shader). Beside their primary task of masking the required objects with a specific colour these replacements have to provide the exact same vertex deformation as the original shader. That would have cost me quite some effort.

Another approach uses the stencil buffer for masking but it can only mask per object/material not per texel. And for deferred rendering it turns out to be nearly useless as the stencil buffer is also used by the deferred renderer itself. Check this out for more in depth info.

To reach my goal I came up with a method to combine both techniques:

First, for each affected screen pixel, the SSS enabled material writes one bit (the only available in deferred mode) to the stencil buffer.
This bit is then read by the SS-SSS full screen shader which discard any pixel where it is not set.
Then I render a 2nd camera (from the same perspective) using shader replacement. By using a ‘replacementTag’ I can make sure to render only objects containing a SSS enabled material.
The replacement shader I use is very simple and just outputs the colour of the object’s SSS-mask texture.
Finally I combine both images to get the required screen space mask for the SS-SSS effect.

One issue still remains with half transparent pixel: They can’t receive a proper stencil buffer flag as they are half-visible but the stencil buffer only knows ‘completely visible’ and ‘completely invisible’. But as mentioned earlier I rarely use them anyway. In the few remaining cases it doesn’t look too wrong as you can hardly tell if the amount of SSS you see through half transparent pixel is ‘too much’ or not.

Thanks for reading and see you soon.

If you know of some new developments let me know!

Pre-alpha 0.2 – A closer look at Engineering 2.0 – Goods

rollin |

14. May 2018 |

DwarfMines

Hi and welcome to this development update!

Before I start I want to give a short update on what I was working on the last few days.

First I settled for itch.io as my patcher and hub during the pre-alpha and test phase. It is super easy to setup, reliable, free and I like the philosophy behind it.
Then I implemented an in-game bug reporting tool with screenshot, console log and bug description. This drops the effort to report a problem significantly.
I switched my automated build system to unity 2018.1, now using .Net 4.x and IL2CPP
I’m now also on Instagram.
And now I’m in the process of setting up the first test server.

I can’t wait until the while system is up and running as it marks the moment where the game really becomes a multiplayer game for the first time (beside smaller local tests).

But now back to this new “closer look” update about engineering 2.0. This time I’ll go over several systems which deal with goods in various ways.

Building a wall

Engineering 2.0: Compound Model System

This is a very relevant part of the whole engineering concept. It allows to construct bigger models out of smaller elements which are smartly chosen and aligned. This does not only cover the ability to build walls, pipes and alike but also allows communication between the connected elements. And this ability makes it very relevant when we look at the next topic:

A dwarf on a conveyor

Engineering 2.0: Transmission of goods

In my opinion a mayor gameplay fun-factor is to try to find the best way to connect your whole production network together. Therefore a system is required which is capable of exchanging very different types of goods. We need to send various forms of energy around, fluids, gas and solid objects like a pile of wood. They all have to be send from one point to another over some kind of a connection. And here the compound model system becomes very handy.
All types of pipes, lines and conveyors use it. Rules can be set how elements are allowed to connect. Conveyors can only connect horizontally while pipes, for example, connect in all directions.

The transmission system is capable of simulating an ‘omni present’ network like a power grid where changes on one side practically immediately have an effect on the other side. And a decoupled system like a conveyor where the sender and receiver have no immediate contact and maybe don’t even know from each other.

Engineering 2.0: Warehouses

Warehouses are kind of a key element of the whole engineering system as they hold not just goods like a chest but they can also supply them. This means two things: When you’re close to a warehouse you can automatically use it’s storage for construction. And bigger warehouses can be connected to a conveyor network which allows them to send goods to specific positions at a specific rate. Still, conveyors aren’t required everywhere.

Engineering 2.0: Trading

Well, trading is one of the new features I’m most exited about. Primarily because it features vehicles. Again something I worked on in the last few month and certainly a topic of its own. But what I also really like is how it connects your small settlement with the big picture, the ‘invisible’ world around it. Like a harbour makes you feel there’s more out there than what you can see: other harbours, other cities, other countries.

Anyway, trading is based on simple rules. You can trade a certain amount of goods you own against a certain amount of goods you want. The rule defines how useful a certain trading option is. One rule might be to trade a specific amount of whatever you want against something else you can choose. Of course that would be a very handy rule. But usually rules only allow to trade a specific good into another. Finding or unlocking better rules might be one reason why you head out into the wild.

Of course all these systems need to be fleshed out by playtesting.

So that’s it for the moment. Thanks for reading!

Pre-alpha 0.2 – To the core of things

rollin |

17. March 2018 |

DwarfMines

Welcome to this development update. This time we look at what has changed beside the engineering 2.0 update. Less noticeable but absolutely relevant for the success of the further development.

Triplanar world mapping

The code which is procedurally generating the world’s mesh is one of the oldest systems in the game. I started working on it back in 2012. Since then I learned a lot about programming – in general and related to Unity. So the system got reworked several times because it has to process as fast and efficient as possible. You can’t get away with lazy coding if you are dealing with a performance bottleneck.

Now I came to the point where I want to improve it once again. But first I had to prepare a new, more efficient mapping technique. So I’ve changed the level shader to ignore the mesh-uvs and instead generate triplanar mapping coordinates.

Triplanar mapping means we generate texture coordinates procedurally and in our case: directly in the shader. Here is a nice explanation. Here it visually does not change the look of the world but it gets rid of the need of texture coordinates stored in memory. For a big voxel world this can be a lot. Implementing triplanar mapping is just the first step to the next level of world rendering. But it’s an important one.

Everything is an entity

A difficult to visualise new feature is the one regarding the entities system. It’s now responsible for most objects in the game and it allows me to handle them all in the same way when it comes to the core functionality. Now every tree, every character, every sword or rock are sharing the same core logic. So creation, destruction, networking etc. is handled by a shared system which makes it more consistent to work with and thereby less error prone. I’m glad I have it now and a bit angry about myself that I didn’t set it up earlier.

Development Tools

Over the past couple of month I had to come up with a solution that would help me keep track of the constantly growing number of entities. The engineering update alone brought along a whole range of new asset types. So the new entities toolbox allows to quickly configure multiple objects and additionally throws errors if something is misconfigured. Basically it’s a combined spread sheet / hierarchy viewer / editor with a configuration checker.

Beside that there where several smaller additions and improvements to my development tools whenever something could be automated.

So far for today. Thanks for reading and I hope it was of some interest for you. If you want to check back in a week or so the next part of the Pre-alpha 0.2 news series should be online.

Pre-alpha 0.2 – A closer look at Engineering 2.0 – What is what

rollin |

5. March 2018 |

DwarfMines

Hi everyone!
So this is the first part in a series of “closer look” development updates. They are meant to give you a better understanding of the basics behind engineering 2.0. This time I’ll outline the principles of construction, production and research.

Engineering 2.0: Blueprints, Kits, Recipes and Fuel

This is a feature that adds modularity and flexibility to the whole construction and production system. It is split into multiple elements:

Blueprints allow the owner to – generally speaking – create something. They exist in two types: construction and production blueprints. They act like items and can be found, stolen or bought.

Construction Blueprints: If you want to build a structure, lets say a sawmill, you need the blueprint for it. As soon as you have one you can add it your list of known blueprints in your inventory. From then on you can create a sawmill construction site. If you carry some of the required construction resources you can start building the structure. Alone or together with your team mates to speed up the process.
Production Blueprints: Think about a normal cooking recipe and then split it in two sections. The first part tells you what you need (this represents the production recipe) and the second part how you actually cook the food (that’s the production blueprint).Therefore: if you want to produce items you not only need to chose the required recipe but also be in possession of the respective blueprint.

Structure Kits: So what I just told you is not always true. Some structures are just too small or primitive to justify a construction site. Lets say: a pipe segment for example. Such elements are simply placed. All you need is one ‘piece’ of it in your inventory. It’s simple: If you have 3 pipe segments you can build a 3 segments long pipe. You can also deconstruct such elements and take them back into your inventory and place them somewhere else.

Recipes: As described above recipes tell you what you need for production and what you get out of it. They don’t tell you how to actually produce it. That’s what blueprints are for. Recipes exist for operation, production and research purposes:

Operation recipes define what is required that a certain structure operates
Production recipes are (additionally) used in all producing structures
Research recipes work like production recipes for research structures

Production and research recipes allow to modify the behaviour of a structure while operation recipes are bound to it.

Fuel is exclusively used by operation recipes: Primarily it means stuff that can be burned to heat up something else. Every item theoretically can be used as fuel but the amount of energy you get out of it differs. If you want to burn that metal helmet it wont do much. But if you want to burn your wooden shield (because you have no other fuel or bc you don’t like it) you can.

Engineering 2.0: Research

Your research is bound to certain structures which allow to spend resources on specific topics. A tech tree decides how you can progress.

The required resources are primarily used for research. Also they are rare enough to make them very valuable. The more you have the more you can improve your current technology. If you don’t find them you might decide to buy them with a reasonable amount of other resources. Or you sell them for good money while neglecting your current research progress.

Lucky ones: During research there is a certain chance that a related technology gets coincidentally discovered. This should reflects the true nature of research which is rarely fully predictable.

I hope this shed some light on what to expect form engineering. Next time I’ll show you more about building a working production infrastructure.

Thanks for reading and see you soon.

Pre-alpha 0.2 – Dwarfs are engineers!

rollin |

24. February 2018 |

DwarfMines

Hello and welcome to the first update in 2018 – Finally.. Pre-alpha 0.2!

You might argue that it would make sense to write news more often. But this time it turned out to be quite an effort to get to the point where it starts to make sense to show something. Many of the new features where too interwoven. It felt bit like trying to unravel a chaotic thread ball. Despite: many of the more visual changes where just done in the last few weeks.

However, now there are so many new things I want to show you that I had to split the post into smaller pieces. 8 in fact…

So this news is just the first in a row about Pre-alpha 0.2. I will constantly release them over the next few weeks while working on less news worthy stuff. This will include the basic infrastructure required for testers and in general for preparing a first iteration of a fallback distribution system beside Steam, GOG and co.

This update not only took way longer then expected, it also includes way more then intended. Some tasks where planed to be tackled later but they turned out to be required to properly implement the engineering system as a whole.

What’s new?

Engineering 2.0

New structures (obviously)
Enhanced construction preview system
Blueprints, kits, recipes and fuel
Production
Research
Storage
Trading
Transmission of goods
The compound model system
Structures with attachments

What else?

Triplanar world mapping
Physical objects (local or network wide)
Entity system
Screen space sub surface scattering (ss-sss)
Layered attachments

Performance

And then there is this big chunk of invisible work done to make the game faster and more stable. Like when I discovered (thx Frame Debugger!) that the moon was still causing a full shadow caster pass – even though he was on the opposite side of the world.. -.-

Tools

And last but not least the creation of development tools I need to handle and streamline the dev process. I really love this part! There is hardly something more satisfying as pushing a button and watching the computer doing all the boring work in just a few seconds.

Engineering 2.0: New Structures

I’ve implemented now several structures in a basic conceptual (grey box) stage. They feature all the new gameplay systems of Pre-alpha 0.2 and even some I can’t reveal yet. Most of them are just a few blocks in size but some are huge. I mean really huge (yes, I’m talking about you Airfield).

Placing and building such big structures becomes a task for it’s own and benefits a lot from working together as a team.

Engineering 2.0: Wreck it

Wrecking! This is tiny but nonetheless important: You can now destroy structures in an orderly fashion. Which means you get some of the resources back you (or someone else) put in. This not only includes the full inventory content but also parts the construction materials. Wrecking takes longer then destroying so it’s not the best approach during battle.

As mentioned above this was just the beginning. The following posts will be online soon. If you like newsletter you can sign up to get one as soon as the next news shows up.

Thanks for reading, till next time!

Merry Christmas, happy Holidays and a good new year

rollin |

24. December 2017 |

DwarfMines

Hi everyone!

Sadly I was not able to finish Alpha 0.2 this year. While digging deeper into the whole structures and construction system I had to swivel my planed roadmap a bit. This was becoming necessary while more and more elements had to work together to form a coherent package of interconnected features. And as I was adding additional features the whole package grew a bit bigger then initially intended. However this also moved some of the later parts of the roadmap upfront.

At the moment I’m primarily in the last phase of testing and bug fixing the game locally and over the network. I do this constantly but especially for big milestones. It ensures the code base is not only working but also thought through from as many perspectives a possible.

As soon as this is done I will go over each new subsystem in a separate blog post. This will range from new structures over the brand new research system to blueprints and production recipes.

As development now slowly shifts from core mechanics to gameplay related features the next step after Alpha 0.2 is out of the door will be to prepare everything for the first testers. Including player profile related systems and the first intern test server. From then on getting constant feedback on the current build will grow to an important part of the development.

For now I wish you all a good time at the end of the year and stay tuned for Alpha 0.2 news in January 2018.

Happy digging! :)

Camera and Characters

rollin |

12. July 2017 |

DwarfMines

Hi and welcome to a new dev news.

Currently I’m somewhere in the middle of Version 0.2 and I thought it would make sense to give an overview over the past few weeks.

On my way to 0.2

The next version will feature better collision avoidance for the camera and more character customizations.
Additionally I decided to include the GUI 2.0 update. Primarily because I don’t want to force any tester to deal with my development GUI. The following version (0.3) will then be mainly focused on making the game ready for playtesting. Including an online patcher and player profiles.
In view of this I thought it would makes sense to tackle the GUI better sooner then later.

The Camera

The third-person camera controller is one of my favourite game elements. It looks so simple but in fact requires a lot of clever ideas to make it work right.
Previously the controller was just able to avoid clipping and keeping a free line of sight but could act quite erratic when moved through rough terrain. Now a system checks a volumetric area for obstacles that might come into view. It calculates a sweet spot of avoidance and follows it smoothly.

Developing a camera controller is an invidious task. If you do a perfect job the majority won’t even notice your efforts. But if just one small element does not work correctly everyone is complaining about you. So just let me say: Kudos to all the camera devs out there!

Comparison between old and new camera collision avoidance

Character customization and a short inventory preview

One thing first: My current intention is not to create an action-RPG-like amount of items. Instead there is a list of distinct equipment. Each with a clearly defined role (e.g. a breathing filter for regions containing contaminated air). Nonetheless, most equipment should be visible on the player model. So some kind of customization system was necessary. I decided to build a more generic one which allows to add any type of equipment or item. Mainly because of the enormous amount of work I decided against a full scale face and body customization system (most likely there will be a set of avatars to choose from, bit like in Torchlight 2).
But it’s possible to dye items with up to three colours.

Now what does this mean for the inventory? Currently the player can wear a full set of garment containing boots, trousers, chest pieces, shoulder pads, gloves and helmets and there are slots for various bags. Additionally some items allow attachments (e.g. some helmets can carry mine lamps).
But: Like with many other aspects this might change during development.

First preview of character item customization

And now..

Directly after writing this news I’m going to start fleshing out the engineering update. It includes all the required steps to build up a first settlement. More details about it will come with the next news. This is a mayor gameplay element and I can’t wait to get my hands on it :)

So stay tuned and thx for reading!

Pre-alpha 0.1 – Now with some brain

rollin |

4. June 2017 |

DwarfMines

Hi all!

Today the game finally reached pre-alpha 0.1. This means all game pillars are implemented. Some already quite final, some just in a basic form. Non the less they are there. Of course countless smaller features and game mechanics still need to be created.

The last missing pillar was the AI. It’s a big system including pathfinding, remote controlling actors and behaviour networks. Implementing such big systems tends to end up with lots of strange bugs. While the system itself was already in quite a good shape it was still running in a sealed of environment and not in the game world. Kind of a laboratory situation. The task was to really put it into position. To tackle this I did some extra work during the implementation. I checked every system I had to touch regarding performance and stability. This postponed the whole process but usually pays off later.

OK, now what has changed since March?

I moved through all my commits of the last two and a half months and compiled the following list of mayor changes. To avoid clutter I skipped all the less prominent things like adding features to the options menu.

Improved group-AI which is responsible of managing monster hordes and similar
Implemented the AI system

AI path finding through limited space while respecting each other as obstacle

Items

Added grenades (throw), explosives like TNT (plant) and torches (just hold)
Implemented ammunition as a resource for items like guns
Implemented consumables (e.g. health potion) which can be activated through a customizable hot-key-bar similar to what torchlight2 uses

New logic for throwing (e.g. grenades), planting (e.g. TNT) and passive items (e.g. torches).
Models still work in progress.

Configuration

Overhaul of the configuration system. It’s now reading commands the Quake3 way. Currently this includes binding keys to actions and setting game variables
Implemented a console asset (TouchConsole Pro) to gain access to our commands

World Generation

Improved the world generation back-end functionality and streamlined the workflow

Misc

Moved to unity 5.6.1
Restructured most data elements to be easier to mod. This includes moving variables into text files and these to Unities ‘StreamingAssets’ folder
Setup a batch build system to automate the build process with additional pre- and post-processing
Last but not least I did refine the logo to read better in various condition.

What is next?

A quick glimpse on the road map reveals:

Some visual improvements for the player model (clothes and custom colors)
An update for the camera controller. I love the Jedi Knight games where you can choose to play in first or third person view. I always wanted to implement this feature myself. Of course this does mean both views have to work flawless to the point where it makes sense to use a certain view
And the very most important part for the upcoming version: The implementation of the first bunch of structures

Together this will lead to pre-alpha 0.2 which should eventually allow to really play the game with enemies and settlements.

Let’s get it on!