working title: MOLD

working title: MOLD

production blog

You can scroll the shelf using and keys

feed_icon_72 FB-f-Logo__blue_72 Icon-72



to our developer blog of “mold”, a modern Adventure game currently in production.

for First-Timers and all those brave men battling against the boredom of Friday afternoons..

Click here to read from the beginning
( currently 92 posts in total )

or sort by category

News, gossip and rants
Concept and Story
Character designs (2D)
Character production (3D)
Set designs (2D)
Set production (3D)
Media (moving pictures of all sort)
useful stuff

… or jump back to the most recent posts

Please don’t overlook the green “Older Entries” link on the bottom right.

have fun!

All images are copyright to their respective owners.


techniques behind the prototype #4 “inside Unity”

August 9, 2015


Hi everybody!

I’d like to close this prototype overview soon, so this will be one of my last posts on the subject. It’s time to make some ground on the production side, get some stuff finally done. (Hear, hear! ;) )

I’d still like to write a dedicated post on the frog, but lets see when that happens.

The primary goal, ‘le grand objectif’, is to finish the first three sets this year. (sounds crazy slow if you think we’ll have to do ~35 sets in total…. totally crazy…) – Fortunately (or unfortunately) I’m still hoping for a miraculous increase in efficiency ;) so the journey continues. But this manual effort/process with a decent and consistent quality was and is very time consuming, and nothing will ever change that.




You can clearly see how “fake” the set is ;) lowres geometry and some sprites positioned in 3D space. That’s basically it. (yellow and red labels represent hotboxes, orange ones are triggers in the game)



and that’s all I got for today. Hopefully these screenshots give you some insight or ideas of how this kind of projection mapping works.

Have a good one!



techniques behind the prototype #3 “projection mapping”

March 31, 2015


Hi everybody!

Before we were able to continue our tedious workflow, we had to first build the lowres geometry. It’s constructed with simple grids, in a similar style as the layers we outputted before. These objects are formed and located as close as possible to the highres geometry.

150313_dummy_geo_andShip(the projection mapping geometry of the toy ship.)


every object got its own UV space, which were combined and packed into groups (shown via different wireframe colors in the image above) depending on their relative screensize (objects far away get less UV space).

150327_ship_uvs(the UVs of the ship)



one tool to bake them all….

Instead of creating all camera projections in Softimage with secondary UV spaces and a slow and user-unfriendly bake-tool, we decided to do it all in Nuke. (which was a massive timesaver, and one of the better ideas of this workflow ;) )

The lowres geometry and camera were imported via FBX without any problems, and were added to the test-layer-comp. (the big colored backplanes show the bake outputs)

150320_comp_final_prepare(a monstrosity of a comp tree)


We had to add dozens of new corrections and vector paints, because the way back (2 compositions) for a simple correction was way too time consuming. To make the layers work correctly inside of Unity, we eventually had to refine quite a lot. (but it’s still not perfect)

In our first attempt we baked everything in 4K, but we later learned that some GPUs/platforms don’t support it yet, so we regrouped everything and exported 2K maps just to be safe.


this is how the baked texture of the ship looks like:


and this is result, the textured FBX model.



Well, that’s basically the workflow before we move on to the characters, and later the realtime business of things.


techniques behind the prototype #2 “lookdev, forever ever”

March 24, 2015


Hi everybody!

We are going to continue from Part #1 and cover the next phase of our set creation process, before we move on to the characters. In hindsight this post feels a bit negative ;) but I’m sure optimizations will be found, and efficiency will rise eventually. (it’ll have to ;) )


fighting the darkness

Even after constructing and sculpting masses of polygons, we are far from being able to add it to the game. The next step is texturing, shading and of course lighting. You can see a wireframe and gray-material rendering of the lighting setup below. (Softimage, Arnold)




Eventually it took about 50 shaders, 20 area lights and one HDRI (mostly for reflections) – and months of spare time work ;) to get the look and atmosphere we wanted. Image composition, color corrections and other fixes, were done simultaneously at Babettes company after working hours. Thanks for the opportunity, Optix Hamburg!

The highres set was split into several layers before rendering (to avoid occlusions between them). To continue our example from last time, this is how the toy ship got layered. (don’t mind the green background, it’s just better to show these dark elements on a brighter background (it’s not used to key the footage ;) ))




The 3D lookdev phase was heavily coupled with 2D compositing, meaning we had to handle massive 10K resolution comp trees as well. And yes, they got big, real big… which brings me to the last point of this part.


worst workflow i could think of

Seriously… but still, I can’t think of any better way to do it, but this doesn’t make this workflow any good ;)  Small “mistakes” added to the problem, naturally.

One example: during the lookdev phase, I decided to add a separate rim light pass for compositing (like i do most of the time..) …which doesn’t sound like a bad idea at all, but after we split the set into over 20 passes/layer we now had to manage over 40……. a bad idea after all.

Every pass got rendered in 10000×3000 resolution, some with multiple states. The frog had around 400 frames alone (and took 2 weeks to finish on 3 PCs). The big passes took about 5 days to complete (on an up-to-date i7) for one frame i might add, so you can imagine how painful previews were (even at lower samplings and resolutions).


thai massaging pixels

But the true fun is just about to begin ;) Every pass was rendered with AOVs (separated diffuse, reflection, indirect diffuse, etc. layers) and needed to be pre-combined before it could be used and passed through the lookdev comp. (it would have been way to slow and memory demanding to have all AOVs in the final comp, so we seperated both tasks).

The reason to output AOVs in the first place was the possibility to apply post noise-reduction to some of the channels. (like indirect diffuse, or indirect reflections which tend to get pretty noisy in Arnold)

150320_comp_precombine(the AOV pre-combine comps)


Working in this high resolution is never fun, but requiring to render 40 precombine comps and 20 lookdev comps everytime you change something, is even worse. Especially because this tedious procedure isn’t done yet. (we even added a checklist about it to the comp trees ;) to avoid errors)

150320_comp_lookdev(the fairly small lookdev comp)


Before we could output the final textures used on the projection mapping geometry, the images had to be test-combined, tweaked (again…) and eventually baked to a square UV space, but this part will be covered in the next post.


have a good one!


techniques behind the prototype #1 “lets build it”

March 14, 2015


Hi everybody!

This will be the first of a hand full of posts dedicated to the techniques used in our last prototype. I’ll try to cover everything important, but feel free to suggest areas we should cover in more detail. Just let us know! (via posts on our Facebook page, or by commenting here)

I’ve already written a little bit about parts of the production in earlier posts, but lets start from the beginning to give you a complete picture of how we did it.

If you want to read all posts dedicated to the production sprint (resulting in the prototype), please click here.


design and prep

As always, a concept sketch is the first thing to do. I prefer to draw on paper, so most of the elements were drawn separately, scanned and then placed/transformed digitally to form the final concept. I’ve altered and changed it quite a few times (especially before the story was locked down) but eventually settled with this:



Next, we built a very rough dummy set in 3D to define some of the proportions, which 1. enabled us to test the set in unity very early, 2. makes it easier or even possible for multiple artists to work and contribute to the same set.




all elements, one by one

We split everything into several sub groups, modeling tasks if you will, and started to distribute them between Babette (Kahn), Florian (Stucki), Thorsten (Kesse) and myself. Lets take our little toy ship as example.


Babette started modeling the ship after we locked down the set layout and collected some references, and after a few nerve-wracking iterations of changes (sorry ;) ) she ended up with this great result:


Every single element was built with basically the same emphasis on detail and quality, which (no surprise here) took up most of the production time. A stylized approach would have saved probably 3/4 of the work (this number would be even higher if we didn’t have as many animations), so if you start to work on a game, keep that in mind ;)

we’ll cover the rest of the creation process next time, so stay tuned!


size DOES matter….

December 12, 2013

…oh yes, you can quote me on that ;) especially when it comes to story, drawings, renderings, game resolution or even genitalia. But let’s start with one of the easier, PG-rated points. :)

game resolution…

the base resolution is maybe one of the earliest decisions a game developer has to make (well sometimes the platform makes this choice for you ;) ),…. almost everything depends on it, and many influencing factors have to be considered.

but first, lets talk about basic math ;)

the expression to calculate the  memory consumption of an image is:
X * Y * (bitdepth / 8)

in case of Visionaire the bitdepth in memory is always 32 even if you save a 24bit PNG (due to memory fragmentation issues with different bit depths, when i understood the developers correctly)


so for one background image of a game in 1280*720
(referred as 720p, or “small”HD)  we get:
1280*720*(32/8)) = 3.686.400 (3.6mb)

and for one background in 1920*1080
(HD, or 1080p) we get:
1920*1080*(32/8) = 8.294.400 (8.1mb)

(1080p has a higher pixel-density by a ratio of 2.25)

(with no texture compression (it was announced for the next release of Visionaire though) if you want to know more, I can recommend Unitys online manual (“Texture2D” scroll down 3/4).

an alerting example when you used to work in “3D Animation”:

to put these numbers into perspective,


lets say your entire background consists of a beach scene with an animated ocean.  Two thirds are static, but one-third needs some moving water. soo the scene including a 2 seconds animation (lets say at (stuttering) 15 frames per second) gets us:

  • 1 static BG           (1920* 720) =                                                    5,4 mb
  • 1 animated clip  (1920*360) =   2.7mb * 30 (frames) =     81.0 mb

now, these numbers are very alerting when you think that some PCs (especially of “aged” adventure gamers :) no offense) are running with 256mb or even less video memory (I can imagine how “128mb-ers” feel to read this :) ), because we are still missing the player character, NPCs, and interface with inventory (and items).

Loading times are another factor to consider. Older harddrives peak at 30mb/s, so our example scene already takes at least 3 seconds to load, let’s keep that in mind.

lets add the rest:

the main character ( 8 angles, [walk, run, idle, talk, pickup] base animations) and lets use 200*600 as resolution
  • WALK: for 10 frames:                                                                         = 36mb
    (holy crap! i had to check it several times (200 * 600 *(32/8))/1024) = 469kb/frm ->  * (10 * 8) , because this number even baffled me! and it’s only 10 frames, 8 angles and a pretty small resolution!!)
  • RUN:         8 frames (8 angles):                                                          = 30mb
  • IDLE:        8 frames (2 angles):                                                          =    8mb
  • TALK:       6 frames (3 angles):                                                          =    8mb
  • PICKUP:  6 frames (4 angles):                                                         =  11mb

resulting in about 93 mb just for the basic actions of the main character, double that when we add all pickups, and dozens of special actions (with or without set elements) So for a HD background with just one character you need 256+mb VRAM already, which was quite shocking, to tell you the truth…

at some point, you’ve probably wondered why most adventure backgrounds feel so static, so lifeless? well, granted, it’s primarily because animation is expensive ;) , but memory certainly plays a major role in it aswell…

a lesson learned – about GameDesign documents

September 12, 2013

(the latest revision of the story/playthrough)

(the latest revision of the story/playthrough)

When i started to work on mold, I had to decide how to approach this pretty nonlinear endeavor. I did read some classic gamedesign documents like Grim Fandango, and some of the Larry(s)…. but clearly, computers must have evolved since the 90s, so maybe there was a more modern / better way to approach it, I naively thought.

the wrong way.

So eventually i went with a vector schematic of the game… in the beginning it worked out great (except some tech probs ;) ), changes could be made with ease, and it was great to have an overview over the entire game…

but as complexity grew, it was getting harder and harder to play it through (mentally). Why? because when you work on a screen, u just see a tini-tiny portion of the schematic (you can’t read it without zooming way in), and printing it, would need tons of paper and a lot of space…


a bloated, useless schematic of the game

spontaneous ideas

well, they are great, aren’t they? sure… but they can also be the last nail for your coffin, You can’t imagine how many little notes were written into my sketchbook and on dozens of loose papers, Mainly, because

  1.  I don’t always have access to my digital files,
  2. when you get to a certain complexity, a small and great idea can change a lot.. so sometimes I just want to write something down fast.

in my case, eventually, I had a big bloated not-up-to-date digital schematic with most of the story, hundreds of papers and sketchbooks with all kind of changes, puzzle ideas, backstory elements, hell even “new” parts of the story. Unneccessary to say, this totally crippled the process… I arrived in “stucktown” so to speak.

being stuck for months


my workstations cpu-cooler, right before i had my cleaning frenzy

I cleaned my office down to the screw, bought and setupped a new workstation, reinstalled old ones, added a new blog theme, and did a lot of other unnecessary things, just to accomplish something useful during that period ;) (besides my commercial jobs at the time, I hope ;) )

So eventually to overcome this state of unproductivity, Babette and I sat down, she took pen and paper, and we talked the story completely through (with the goal to continue even if something is not right or still unfinished). It took around 4 hours to work it through, still with a lot of stuff which was kinda “meehhh, maybe ok at most”, but now I knew where to start.

Since then, I searched and collected everything useable from old sketchbooks and papers, and revised the story several times (especially during vacation). Just to give you an idea: the first draft had 8 pages, the most recent one has 23.. so the oldschool approach is definitely the way to go in my opinion.

Game Pitches has an interesting collection of game design documents, in case you are into this kind of stuff ;)

my final thoughts

I can’t speak about those numerous tools written to organize/plan explicitly adventure games, but working on a story is hard enough itself, the last thing someone needs is to struggle with buggy tools or technology… so don’t hesitate to give paper a try ;)

If you are totally stuck I would recommend:

  1. walk/talk your story completely through, write every action down in short and simple sentences.  Don’t stop when something isn’t right (even if it’s a major problem), work it through to the end. Always leave a few lines space under each sentence (it does make “analog” editing a lot easier, later)
  2. read / work / talk it through several, SEVERAL times (it took me 2 months, after being stuck) until you are sure everything is solid.(a brainstorm partner helps a lot here) – you probably have to update your word document from time to time.. (it’s getting really hard to read with all those handwritten little text addons and notes)
  3. eventually when you are (almost ;) ) completely satisfied, a reduced schematic just showing Sets/Items and Characters would provide a good overview over the project (it’s also useful to calculate the costs later)

so in my humble and home-educated opinion: a printed step by step story plus a reduced schematic (something like this) is the way to go.

that’s all folks! ;)

PATV: Extra Credits…

August 15, 2013

Hi guys!

This is one thing I have to share right away, in case you missed it (like I unfortunately did, until recently). PennyArcadeTV releases a weekly 5min cartoon show called “Extra Credits” covering all aspects of game design, theory, well almost all aspects of how a game changes/fit into our society.

Truly Amazing Stuff! I’ve blazed through 6 seasons in a few days and I can recommend them to anyone (especially if you are interested in game development and art).

Here are all direct YouTube links:

hope you like them like I did ;)

research: length/complexity of “Monkey Island 1”

May 13, 2013 2 Comments

ok, I finally finished it. (thank god I have this one off my back ;) ) I can’t claim it’s 100% error free (I’m too busy at the moment to have a clear head / the time to recheck it several times, to be absolutely sure ;) in case you find something, please drop me note)


I didn’t upload an additional bigsized JPEG this time, so here is the vector PDF:


just a note on the side: the blog will be updated every thursday night, from now on.

research: length/complexity of “Day of the Tentacle”

January 28, 2013

ha, this is probably the first really useful blog post ;) (at least for adventure interested indies). I’m planning to do this kind of research with a few more classic games, just to get a better feeling about proper gamelength and complexity.

Day of the Tentacle (LucasArts(c)) is one of the few games i really admire, so i think its the best to start with.


or if you prefer a PDF: <130128_length_research_DOTT>


%d bloggers like this: