Black Golem Wed, 16 Apr 2014 21:15:19 +0200 FeedCreator 1.7.2 Black Golem - Independent Game Developer Trailer for Nordenfelt 0.6 In preparation for Nordenfelt's Desura/IndieDB presence I had to make a trailer.

Have a look:

I'm quite new to the trailer/video maker club. So if you have some tips for improvement please tell me.



P.S.: This is a cross-post from

hermitC Mon, 06 May 2013 00:13:01 +0200
Why Showing Single Assets is Worth Nothing When I started out making 3D models for Nordenfelt I made all design sketches, 3D models and rendered sprites public. I thought it would be a clever way to get feedback what's good and what's not. Theoretically not a bad idea. Practically: it was worth nothing.

Due to the fact that I was a newbie game artist back then I was not aware of what's essential for game graphics. Nordenfelt's visual style is "simplified realism", alike Baldur's Gate. So I thought making somewhat realistic graphics would be sufficient. As you may guess the fuzzy word "somewhat" turned out to be a stumbling block.

Whenever I presented an asset people started to argue that the angles of the Gatling guns were not realistic, that steam engines need boilers or that there's no hint how the machine was able to float in the air (e.g. visible propellers). In my naivety I followed these hints and altered my assets for the sake of realism.

I remember having a forum discussion about the cockpit shape of the player ship. A guy argued my design was flawed because there never has been any real-life aircraft with a cockpit shaped like my 3D model's cockpit. That was the moment I asked myself: What does all this not-plausible-in-real-life carping have to do with my game? It doesn't make an iota of difference to the gameplay.

final player ship design

The problem with showing assets in isolation is that the formative design rules are not obvious. Above all assets have to carry the gameplay. If necessary paint tanks and war planes in pink and red if it helps to distinguish them from the background (what would be disastrous in real war). It's irrelevant if propellers are too small to carry the weight of a hover bomber. It's more important that they don't cover other enemies which may become a real threat then.

Finally feedback on assets is just "noise". Everybody has a different taste and idea of what your assets or game should look like. Therefore it's a waste of time to adapt assets to other things than gameplay and overall style. As soon as people see your assets in motion and interaction with each other the scope of feedback jumps to a way more helpful level: how good the GAME is/looks.

Don't get trapped on the details level.



hermitC Fri, 18 Jan 2013 14:32:38 +0100
Top-Down vs. Bottom-Up Scaling project scope triangle

When it comes to scaling features in game development there basically are two approaches: top-down and bottom-up. This means you can either put more or less effort into a feature to meet limits like time, money or quality (aka the project scope triangle).

So far I've used a top-down approach for making my game assets. It's simple: decrease asset quality when you run out of time. Seth Godin's N-1 blog post was the main inspiration for this. After 2 years using it for Nordenfelt I dare to say:

Top-down scaling does not work for game assets.

The Top-Down Scaling Dilemma

Let me explain the problem by the following example:

While happily developing your game you take a look at your schedule. Half of your asset budget is gone but only 30% of the assets are done by now. They have decent quality and also underwent some polish. So you need to complete the remaining 70% of the assets within the left (half) asset budget. The top-down scaling approach solves this problem: decrease the quality for the remaining assets. Problem solved.

Let's do the maths for this example:

  • it took half of the asset budget to create 30% of all assets in 100% quality => 0.3 * 1.0 = 0.3
  • to complete the missing 70% within the same time you have to decrease quality to 43% (0.3 / 0.7 = 0.43)

Finally you have to create the new assets in less than half the quality of the other assets. So you'll get a game with some polished and much more unpolished, drafty content. Put simply: pure inconsistency.

google maps inconsistency

You get it


The problem is that top-down scaling is like building the roof of a house first, mounting it on very high pillars and say "that high we have to build the walls". When it's time to downscale the quality of the underlying walls the house may not stand the roof's weight. Therefore this scaling method does not work when you create entities which depend on each other like game assets.

Basically the asset quality downscale approach does not save you from going out of time/budget. You would have to find the right quality level at the very beginning of a game project. This would make a mockery of quality scaling because you already have the perfect quality level for your budget.

Rather Scale Up

The alternative bottom-up scaling is way better suited for assets. First you have to settle for a minimum quality. The optimum: settle as low as possible, speak sellable quality. I've written about that here.

How to define "sellable quality"? Well, a good question. I thought my guts would tell me what's the minimum acceptable. Forget your guts! Instead head over to platforms like Desura, Indievania or Indiecity and check out which minimum asset quality sells. You will be surprised how low-fi you can go.

Using the new, as-low-as-possible quality should allow you to complete ALL assets in budget. When all assets are there and your game is sellable you can either starting selling it or exhaust the left budget for better quality. Improve the assets step by step but don't go too far to keep the overall quality consistent. Better polish many assets a little than polishing a few out of equality.

Positive Psychological Side Effects

The best thing about bottom-up scaling is: I sleep way better.

Before switching from top-down to bottom-up scaling I often missed deadlines and quality levels. Over time this had a strong impact on the psyche. It felt like nothing could be achieved in time and rendered deadline estimations senseless.

With upscaling I now can set a time frame and crank out minimum viable assets until the time is over. When there is time left I use it for polish. If not all assets could be done within the time frame: no problem. Not all of them are necessary and I made the most critical ones first.

Bottom-up scaling brought the fun back to my project.



hermitC Mon, 14 Jan 2013 19:49:17 +0100
Ignore New Game Dev Wisdom ... while you are working on your project:

three monkeys


I have a big problem with newly acquired knowledge, regardless if in game programming, design or art. Whenever there are articles or discussions about these topics on the net I have to read them. The problem: afterwards I want to apply the new wisdom (or nonsense) to my game. I feel obliged to do so. Otherwise the game won't be as good as it can/should/must be.

This behaviour is very dangerous. Adapting a running project due to "infiltrating" knowledge will send you into an endless improvement loop.


  • new features seen in other games,
  • fancy graphics your game can't live without,
  • adapting your engine from single- to multi-threading - for the sake of it,
  • optimizing before you face performance problems (I confess myself to PE) or
  • data-drive as much as possible.


It's important to guard your running project from the latest craze and daunting competition influence. The most important purpose of projects is to deliver results. In terms of game development this is the game itself. Started projects are dime a dozen. Finished projects are not. Prevent your game from stalling due to "I need that to" syndrome, also known as feature creep.



hermitC Sun, 02 Dec 2012 11:48:06 +0100
Game Piracy = Apathy Lately I've watched Thrive. It's a documentary about the bad government, greedy corporations, our diabolic bank system and suppressed scientific results - everything garnished with some esoterism. It sums up to the conclusion: the establishment has a master plan to enslave us all.

I'm not sure what to make of this movie. These stories about "all bigwigs are deceitful" are so common these days. Especially all the mentioned great inventions which never went public puzzle me. A perfect cure for cancer found in the early 20th century pharmacy companies want to keep secret? Clean energy supply out of thin air? Come on.

perpetuum mobile


However, it made me ponder how the establishment can do bad things to their own people. We know that political and financial decisions don't get made for the public benefit. They get made for the decision makers, to keep them in power. Therefore bad things happen to the common people regardless what they want from their leaders. Democracies grow into oligarchies, it's the old game.

The question for me was: why is money more important than people?

A single word took shape in my mind: apathy.

Apathy is the absence of emotion towards other beings. When someone has no emotional connection to an other being (s)he will see it like an object and treat it that way. Insects are a simple example. Would you have concerns squashing a fly when it gets annoying? What about killing spiders just because they look disgusting? Humans don't see themselves in these animals and therefore have no empathy for them. Killing them is not killing. It's removing distraction.

It gets more difficult when animals get bigger and "mammal". Dogs, cats, pigs, cows, dolphins - whatever has a recognizable face and "voice". How easy is it to kill a dog, especially when it squalls in pain? If you don't have a problem ending a dog's live just for fun please consult a psychologist. Otherwise read on.

The point is: when there is no emotional bond and no compassion towards an animal or human being it's easy to exploit it in any way we want. This apathy seems to be the root of most problems we have with our establishment(s). The often demonized money isn't the problem. It's just a catalyst for unethical behaviour. When leaders are too far apart from the people they (have to) guide and decisions get made out of selfishness regardless if they harm others we have reached apathy. When I don't see the pain I create, when I don't have a relationship with the victims or simply can ignore their fate (best masked with statistics where the starving are just a percentage) I'm able to exploit these "insects" at will and squash them when no longer needed.

At this point it's time to lead over to games.

Imagine how pirates get copies of your game. Usually somewhere from a server, from a generic Internet link. There is nothing there pointing out that you invested months or even years making this game. The pirate doesn't know you or just has no empathy for you. There is no emotional connection. The monetary loss for you is not the his/her problem. Pirating your game this way doesn't feel wrong.

A complete different experience for a pirate would be getting into your flat with a picklock, hacking into your PC, copying the game and leaving without a trace. The result is the same as downloading it from a server. No physical theft happened, the game is still on your harddisk. No immediate harm was done to you. Despite the same outcome as a download the pirate feels that (s)he acted unethically. It gets even worse when the pirate is a friend of yours. How unscrupulous would that be?

It's easy to exploit others as long as the harm does not affect ourselves. This becomes more difficult when we have an emotional connection to the victim.

That's the hook game developers should utilize for less piracy. Building a relationship with the audience is vital. There are several things a game dev can do:

  • start a blog where you talk about your work, your thoughts and opinions,
  • communicate with your audience, e.g. in forums,
  • support clients personally - no call center shit,
  • share your knowledge,
  • help out,
  • be friendly,
  • etc.

A load of true fans, interested in you and your work, sounds like the ultimate goal. Empathy and trust are critical for this endeavour. People with a positive emotional connection to you will be happy to spend money on your games. It's no longer buying stuff, it's supporting a person or team they feel connected to. That way spending money feels more like help than trade.

That's the way I would love to spend my money!



hermitC Sat, 10 Nov 2012 19:17:05 +0100
Game Update Convenience A few days ago I've finished reading 37signals' e-book Get Real. It's a manifesto how to write better software faster. Most of the content reminds me of the mantra-like agile knowledge infiltration in software management during the last decade. You know, Scrum and the like. This may sound a little pejorative but it isn't. Get Real is an easy read, no pointless chit-chat and full of useful hints to make your programming life easier. The word "agile" just became a little outworn and buzzy these days.

two women fighting, cause: the word "agile"


Anyway, this book made me thinking how to translate the "new feature deploy" points from web development to desktop games. When you're making a website updating is no problem. Changes to the server side immediately change the client side. Installed software OTOH needs the user's permission for updates. How to implement this as painless as possible?

In the year 2012 updates should no longer have to be explicitly downloaded and reinstalled. Auto-update is the word. So I've added a new update system to Nordenfelt's work agenda. Basically it should inform players at game startup that there is a new version available. An optional click on an update button should download the new stuff in the background while the player is blasting his/her way through the levels. The next time the game gets fired up the new version is available. No installing, no additionally running update programs in the background and no annoying pop-ups "you wanna update?". Hopefully I'm able to write such a slick update system. :)


This article was cross-posted on Just wanted to share my Get Real thoughts here as well.

hermitC Fri, 26 Oct 2012 21:36:34 +0200
A Summer of Silence After five months I'm finally back on this blog. Some people already were curious where the hell I went. I never left, I just did an experiment...

The Book Project

I always wanted to write books. I've started my first one at the tender age of 16, just to fight the daily boredom while waiting for the train home from school. It was a fantasy novel on which I spent every free minute for about 3 years. As far as I can remember I quit after 200 pages. The main reason was that its scope was way too large. It would have taken about 1000 pages to complete it. Another reason was the inconsistent writing style. I think puberty and it's hormone level fluctuations are to blame. It's funny how different you express yourself after a few years. And the final reason: everything was written on paper. It would have been a lot of work to digitize that. So there's just the script left, rotting somewhere in the attic...

In March this year, more than 10 years later (and hopefully out of puberty) I thought about writing another book. Just a little side project. A major motivation was to have something small I could finish in a short period of time. Nordenfelt has already been in the making for too long. So there was this craving for some success feelings.

Soon it became clear that running a side project in parallel to Nordenfelt wasn't applicable. They just would delay each other even more. So decided to freeze the game until the book is done. Back than I was thinking about 2 months. Man, was I wrong. As ever.

The first draft was finished within 80 hours. That's about 6 weeks in I-have-a-day-job-as-well life. Then came the famous last 20% of finishing the nearly 60 illustrations, proofreading, and writing the code examples. It seems to be a global rule that projects proceed slower the closer you come to the finish line.

Finally, after about 280 hours (ca. 22 real life weeks) the book is available as pdf e-book and as paperback:

book 2D Game Collision Detection

Check it out:

Lessons Learned

The following list is a brief recap of what this project taught me:

  • everybody you tell "I'm writing a book" thinks: novell - write one, people want entertainment (damned hedonists!)
  • no need to release all versions at once (pdf e-book, paperback, Kindle, etc.)
  • a project has no definitive finish line, it's more of a decision of what not to include
  • not sharing your everyday progress frees you from expectations
  • the 80/20 rule is everywhere!
  • time estimation for projects is worthless (speak: always wrong) - you can only change your feature list

As you can see, most of the points hold true for game development as well.

What's Next

As you may guess, I'll continue working on Nordenfelt. First of all the way of how I work on this game has to be changed. The most critical change is shrinking the focus. There are too many features in there right now. Most of them are not even visible to the player. That's the major problem. Up to now it was primarily engineering-driven. Most of the fancy mechanics in the engine don't bring the player any fun. It was just fun to implement them. The last blog post already explained the reasons for this deficiency.

Further I have to rethink the asset creation process. Handcrafting everything is no longer an option. It was cool for learning asset creation but the time has come to gear up. Automation, freelance artists, style changes, whatever is necessary.

Aside Nordenfelt I'll go on promoting the book. That's actually the most interesting part of the book project. And the toughest. For this reason I want to ask you, my fellow reader, if you could spread the word about the book? Any help is welcome.

Winter of Noise

The summer is over. Game dev goes on. So will this blog. The next post's silhouette is already on the horizon...






hermitC Sat, 06 Oct 2012 00:00:00 +0200
Victim of the Machine metropolis

Lately I was asking myself why Nordenfelt isn't released yet. It's 2.5 years in the making now, so...

A short analysis of my Subversion log showed that plenty of technical features were added and polished. The engine works fine. OTOH gameplay features hardly went into the game. A well greased engine is important but why the lack of gameplay treatment?

This question takes us back to my school days. I went to a school for furniture and interior construction. Everything there was about craftsmanship and perfection. Afterwards I attended university for studying software engineering. This wasn't that different to making chairs and planing rooms, just more virtual. Both schools made solving technical and constructive problems second nature for me.

Right after graduating I started working in the arcade games industry. It was a cool environment with professional guys in there. Nevertheless the company I was in was a boat steered by others than me. I was a coder, a cog in a bigger machine. That was OK with me for some years. But it was not the final goal. So I quit after a few years and started Black Golem.

The first indie year was the best in my life. Not because I could lounge all day long. I've worked more than ever for zero income. It was the freedom to do what you like when you like. Getting up in the afternoon and coding until the sun rises is just epic. A great time.

But then one thing started out to be missing.

Nobody taught me autonomy.

By autonomy I don't mean things like project management. That's stuff I was trained for. What I'm talking about is the holistic approach of managing oneself. Things like self motivation, endurance, finding your own vibe, gaining/keeping satisfaction or simple risk management. Which People to follow other than big money makers like Bill Gates, Peter Drucker or Warren Buffett...

Back to the present.

During the last weeks I've listened to Seth Godin's manifesto Stop Stealing Dreams. Godin explains the roots of our current school system and why it fails to produce autonomous individuals. Simply because yesterday's industrial economy needed masses of drilled workers and managers. Today labour gets either automated or outsourced to countries with lower wages. The information age with the Internet as its driving factor makes labour-drilling schools obsolete. How to solve this problem is explained in the manifesto. I really recommend reading (or listening to) it.

Anyway, this made me aware why I was not ready for being a successful indie developer. School had no intention telling me how to become independent. Schools are worker supplies, nothing else. Teaching how to stand on your own feet would be counter-productive. You would not fit into the machinery. I don't want to say modern education is conspiratorial. IMO its breakdown is just a symptom of an outdated mindset.

Finally, to close the circle, Nordenfelt is a reflection of the skills school told me: a journey of mastering technical challenges. It takes some time to put off "for tech's sake" attitude when you were drilled to act this way. But I think I'm on the right way. A fault confessed is half redressed.

At the close I've listed some lessons indie life taught me, which school won't tell you:

  • bankruptcy is not the end of the world
  • pleasing everybody is pleasing nobody
  • there is no 100% in life, never
  • base alternative opinions on hard facts
  • forget "you need to team up" if you don't want to
  • giving up is no option
  • people fear change so they discourage you doing your own thing
  • don't shy away naming your price
  • there's always a second chance
  • you can't afford perfectionism
  • always think: why not?

In case I could give just one advice I would say: No fear, just do it.


hermitC Sat, 12 May 2012 16:34:23 +0200
Define Motivating Tasks Do you know these seemingly small task which sit on top of your todo list forever?


It frustrates facing the same task several days or even weeks despite you're working your ass off. Refining tasks, e.g. by using stacked todo lists, is the logical answer to this problem. But then there pops up another problem: where to stop refinement?

The last list-clinging Nordenfelt task made me pondering how far tasks should be broken down so that I can tick something off every day. For me as part-time indie that means: tasks not exceeding 2 hours of work. Better they require just one hour.

One approach I've tested over the last two weeks is breaking everything down until I can imagine it. What exactly does imagine mean in this regard? For clarification let's refine this task as an example:

implement server login

At first glance it sounds simple. Call function login(name, password) of the network/lobby API and it's done. But while figuring out where to put that line of code it already starts to get complex. How will I trigger the login function? Where to get name and password from? What if the function fails?

A little pondering brings up the following list of sub tasks:

  • query name and password,
  • handle errors, e.g. in offline mode,
  • remember credentials for case of later login,
  • handle states (are you logged in?),
  • run asynchronous login thread - nobody wants freezing programs

That's quite a bunch of details which were not obvious at the beginning.

Looking at the first task - credentials input - the mind's eye sees a modal dialog showing up, asking for name and password. Again, trying to figure out where to fire up this little window... Oh my god: there's no dialog component in the engine yet.


Sometimes simple things turn out to be much heavier than they seemed at first sight. Envisioning working on them reveals many hidden estimation pitfalls.

To get to the bottom of this login example we break the new dialog-making task down as well:

  • create dialog background image,
  • create OK button image,
  • create CANCEL button image,
  • write class ModalDialog,
  • ...

The image creation tasks already seem applicable without further ado. Dialog background = create a new image in Gimp, draw two text input areas on it, label them "Name" and "Password" and set colors. That should not take longer than 10 minutes... OK, let's say half an hour.

You get it. Once you can envision the whole task without vagueness it's atomic.


The advantage of such detailed todo lists: their tasks should be doable within an hour or less. Some of them may be done within minutes, some of them surprisingly can take a few hours. Anyway, the most important gain is the rewarding feeling of ticking tasks off several times a day. It provides this great sense of progress and accomplishment. Finally it's an important source of motivation which will keep you going on in your project.


hermitC Thu, 29 Mar 2012 22:01:00 +0200
Never Ending Construction Site After a socializing hometown weekend (face2face fun, not Facebook) I hit the road heading back to my worktown. On the highway between the towns there is this never ending building site. For 10 minutes there's just a small two-lane passage between an infinite number of concrete bollards, separating the working area from the street. The funny thing: nobody is working there. Building firms (at least in Austria) like to set up road works all along highways in autumn and abandon it during winter. They just leave speed traps installed at outrageously low speed limits, dangerously small tracks and some crazy guys seemingly left from the last Gumball rally.

As I sat there in my car, bored, my game dev mind immediately compared this situation to game production. There is one big similarity I'm facing at the moment in Nordenfelt:

a never ending construction site

The game has loads of assets and features which are still under construction. It's full of road works which can't be tackled because there is just one worker shoveling: me. Wouldn't it be smarter opening and completing sites just one by one? That's what I want from these hoaxing construction companies. So why I'm not doing this for Nordenfelt?

That's a legacy. I've opened too many construction sites within short time in the past. Starting that many tasks in parallel made me feel busy which was nice. At first. The nice feeling soon faded and dozens of incomplete road works lay ahead. Now they sum up to a behemoth task which remains in "not-finished-yet" state.

epic construction site

It's not that bad as it may sound at this point. Some tasks are already done (e.g. audio and explosions), others are still enqueued (e.g. tech tree or further levels). But now I'm working and completing one aspect at a time rather than starting many and treating them in parallel. It's some kind of awakening from the multitask lie.

Like roads and highways games should be in working condition most of the time. This includes also features which are under construction. In the past game development seemed like cooking to me. Today I see it more like making shelves. What's the difference? A few wooden boards and screws can make a useful shelf. When you want it prettier you can sand it, carve patterns into it, paint it, whatever. Cooking a meal demands multitasking (maybe that's the reason why women are renowned for this gift - you know, praise 'em today) because everything has to be served warm at the end. There are hardly improvement steps in cooking.

In the end it's all about the feeling you can get from making games. Not finishing any task is demotivating. Completing tasks after one another will provide the endorphin rush you need for a successful project. So go for your body's own drugs.


hermitC Thu, 08 Mar 2012 21:54:32 +0100