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

 

Welcome,

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 88 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.

irons in the fire….

December 9, 2015

…. and lots of ’em. :)

.

Hi everybody!

While it’s a constant battle to find a free minute for Mold, we managed to work on all (started) sets and assets quite regularly… but without – actually – finishing something. I wouldn’t call our desired quality level too high, just veeery high ;) which makes even small models quite the tasks and time-sinks to be honest.

.

“daddy longlegs”

.
Babette started this fellow some time ago (I just lighted, rendered this rough and noisy image, besides of the character design) and is currently animating the clips/cycles needed for the game (which look pretty funny and awesome already). There are still some shading and texturing issues, but it’s definitely on the right track and close to be finished.

Weberknecht_blog

.

“the aphid”

.
Babette also modeled and base textured this little critter, I continued with texturing and shading and got it to this (still not rigged) state. The character is extremely tiny, so it’s definitely a bit over detailed. (and we know it, but still, it’s so hard to stop at a lower detail level)

151201_blattlaus_shade

That’s all for this time, have a nice one!

–stephan

.

Artificial Stupidity™

September 23, 2015

.

150923_brainTitle

.

Hi everybody!

It’s time for a closer look on the fauna of Mold, more precisely on the micro brains of all those little (gladly pretty stupid ;) ) critters, which populate the environment.

The hole idea of having free acting / AI (artificial intelligence) controlled insects in the game came when I bought playmaker for Unity :) , which adds finite state machines (FSM) to the mix. I originally planned to simply move a few insects on predefined paths through the sets, but with this addition, even I had a chance to get something more dynamic going ;)

Before we start, let me ‘state’ that i am by no means an expert on FSMs or AI so take my advice or setups with a big grain of salt. I’m basically just reporting how I did it, and how i got it to work, not how a ‘FSM/AI pro’ would probably do it. (so in case someone notices a big no-no, please don’t hesitate to contact and correct me.)

… but it works and by my understanding everything was done as it should be. (see? apply salt here ;) )

.

Ants (approx. IQ: 0,05 points)

 

ameise_AI_stresstestBUGS!! BUUUUGS !!!!!!!!!!

.

I created the first version of this FSM for the third Mold prototype (v0.03.xx), which, granted, did the job, but had some major (but not very obvious) problems. (like sporadically vanishing ants) The entire setup (still) relies on Unity’s pathfinding, but some parts of the FSM (like setting the agents goal) ran incorrectly on ‘Update()’ (means: every single frame), which probably caused this behavior.

I revisited this AI after i (learned a lot from and) finished the fly, and fixed most of its problems as far I can tell.

.
The Unity hierarchy looks like this:
[ANT_prefab( FSM1 )] -> [Sprite( FSM2 )] -> [view collider( FSM3 )]

A simple cone/cylinder (acting as trigger), follows the ant and “looks” for the player (it fakes the insects point of view). This event is fed into FSM1, which resides on the main prefab and controls the overall movement and behavior. The view cone itself is randomly (and in steps) rotated around its Y axis, which causes some of the insect-like, erratic movement. FSM2 finally just aligns the sprite to the active camera.

Finally, a forth FSM instantiates the ants, modulates their speed, and registers/add them to the AdventureCreator engine as NPCs.

.

Fly-o-poop (approx. IQ: 0,07 points)

.

lastenfliege_AI_stresstest_small

.

Unfortunately this (flying) creature needed a completely different approach, so I started from scratch and used the opportunity to improve on my old design. (which is usually pretty easy if your last design was also the first ever :D )

This time i couldn’t use pathfinding (well, it flies), so I had to get my hands dirty(er than usual) and transform it manually (basically creating my own tweening inside playmaker)

.

Unitys hierarchy looks like this:

[FLY_prefab( FSM1+FSM2 )] -> [noise( FSM3 )] -> [Sprite( FSM4 )]
[FLY_lookAt]

This NPC has 4 basic states. 1. Fly from start to goal, 2. follow player, 3. annoy player, and 4. fly home. This time I didn’t use a trigger to detect the player, I simply check the distance between player and fly.  FSM2 is just there to generate all global perlin noise vectors (+distance calcs) which get fed into the other FSMs/states when needed.

.

150924_fly_FSM

.

A big improvement compared to my ant AI is that all states transition smoothly (which is not as trivial as you might think ;) at least for suckers like me), the noise FSM(3) applies additional random transforms to the fly without further complicating the main FSM. (in my opinion it’s easier to use Unitys hierarchy instead of trying to calculate every motion or offset in one state)

The Flies are aligned to the FLY_lookAt gameObjects (FSM4), which  are moved between the view targets by the main FSM(1) (yellow lines in the animated gif). (the green lines show the camera alignment, the colored label of each fly shows the current state)

that’s all I can remember for this time ;) , have a good one!

–s

.

post {-posthum} silence…

August 21, 2015

.

Hi everybody!

The last six months were.. well… pretty crazy,….. I got one job after another – some even overlapped – and being a freelancer, ;) I usually take what I’m able to get, especially if I get offered such amazing opportunities like this year. So my progress on Mold was comparably trivial so far in 2015. Unfortunately….

.

;) anyway…
soooo besides the tomato…

…what’s new?

.

The second set progressed quite a lot and is pretty close to be finished. A few details here and there, the low res geometry and last but not least the characters are still on the todo list.Uzara_room_comp_v44_small

.

The third set (strictly speaking it is the first set you encounter in the game) is coming along as well… it’s basically as far as the second set and primarily misses the characters and some additional look development (it’s not good enough to show yet, obviously ;) )

.

and I’ve continued to work on the main character’s animations, this is the movie I use to test the cycles before everything gets implemented. Some clips (and all phonemes and emotions) are still missing, though.

.

That’s all for this time,
have a good one!

.

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.

.

150405_unity_ship

.

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)

150405_unity_scene_overview

.

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!

.

.

a tomato, with bad intentions

July 20, 2015

.

Hi everybody!

I finally had the chance (and free time ;) ) to detail, shade and texture the “dead mayors” watchdog. He is one of the obstacles the player’s going to encounter in Mold.

Now, when i think about, “Heinz” would be good name (you can clearly see his german ancestry ;) )

tomateHorror_shade_v015.0002
tomateHorror_shade_v015.0001

.

Beautifully sculpted by Tobias Schlage, with a little bit support from Babette Kahn.

Tomato_guard_03

the sculpt is a based on a design (and matches it pretty well btw. ) i did about a year ago.

char_tomate_guard

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:

150327_set_06_2K_ship_baked

and this is result, the textured FBX model.

150329_ship_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)

.

150314_lighting_spoAnf

.

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 ;) ))

.

150313_ship_layers_thumb

.

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:

.

140211_spotlightAnfang_new_layout_15c

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.

150305_SpoAnf_dummy

.

.

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.

Ship_v02changes

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:

Ship_v04

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!

.

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: