working title: MOLD

working title: MOLD

production blog

You can scroll the shelf using and keys

Welcome,

to our developer blog of “mold”, an anti-retro 2D Point and Click Adventure 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 70 posts in total )

or sort this big “mess” by category:

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

… or jump back to the most recent posts

convenient image galleries can be accessed via the top menu, and please don’t overlook the red Older Entries link on the bottom right.

we hope you follow and enjoy this still very long and tedious ride (we certainly do ! ) ….. well most of the time ;) 

production crunch report #4 – the engine

March 21, 2014

140305_unity

.

One important goal of this crunch was to test Unity as possible replacement for Visionaire,

.

risking to “pull a Duke

.

I’m thinking about switching to Unity for quite some time now, I even researched path finding, inventory systems and all the other good stuff ;) nobody wants to write him or herself. (at least not when you are more a storytelling type of developer)

Unfortunately even the most basic 2D adventure features were missing or were sub-optimal or non-existent on the AssetStore. So just getting to the point of having one room and protagonist (with UI, Inventory, click&point controls, loading/saving, etc.) would have been quite a task. Honestly, I got a bad feeling about the sheer mass of scripting I’d have to do,…. still … the plan was to give it my best shot no matter what..

Luckily I’m able to use the words “would have” and not “was” (which would also be impossible unless i get my hands on a flux compensator someday in the far future).

Chris Burton, a fellow CG Artist and filmmaker took the challenge and created “Adventure Creator“, an Asset for Unity which almost feels like Visionaire… well “almost”.. There is certainly more scripting involved, and some features are still inferior to Visionaires implementation, but overall this asset provides a lot bang for the buck.

The support is great (and very patient with us click-action-export-run n00bs ;) ), I’m pretty sure AC will mature even further in no time. (I bought it less than 3 months ago….. 5 or 6 updates with bug fixes and new features were released since.)

…. so Unity it is.

.

why not Visionaire?

as much as I feel bad for not supporting my fellow “hamburgiens”, Visionaire currently lacks in some pretty important areas (at least for Mold)… the biggest arguments against it were:

  • no other platforms except PC and MAC(beta) (iOS in development, but (more importantly)….. ->
  • no public info on ETAs, development milestones, planned features or even bug tracking… When i started Mold, Visionaires version was 3.7.1….. now, 2 years later, it still is 3.7.1.

there are quite a few additional minor issues, (like: everything moves linearly (no smooth camera, or acceleration of any sort..) which affected my decision, but the “no communication” issue was definitely the major one.

.

advantages and risks of using Unity

more features are usually a great thing.. but the ability to do more, often results in ..well… actually doing more.

Unity is a native 3D engine, so using a polygonal set in conjunction with some kind of projection mapping seems to be the best approach…. but the effort to set up all layers, render them in 10K, bake them to new square UV maps (almost like “batching” in unity, but manually) shouldn’t be underestimated.. seriously….

..on the other hand the results are pretty impressive (when you imagine how the final art could look like with it), I’ll post a gameplay video montage in the near future, so stay tuned!

–s

production crunch report #3 – leveraging everything…

March 15, 2014

140314_dummyset_fill3

.

Set assembly

.

The first thing that needs to be done is a very simple dummy set, which matches the 2D concept design… It serves as scale reference for all models and is used as a starting point to build up the set.

140314_dummyset

.

my current approach is very similar to real life kitbashing…

  1. create something (a rock, plant or whatever) using whatever method
  2. retopo, UVs, and bake 8K EXR displacement maps for parts or the entire object. (some are resized to 4K when appropriate)
  3. add it to the set, put a simple shader(incl. displacements) on it
  4. instantiate and fill up the set as much as possible (which is pretty much the only advantage “3D” brings to the table compared to painted or photographed backgrounds.. everything else is a lot more work, though)

.

140314_dummyset_fill1

140314_dummyset_fill2

.

soo….when your TODO list exceeds 500.000 items (like this project feels like ;) ) you begin to look for every opportunity and possibility to get something done… so to follow-up on point “1. create something”… these are the methods we usually use to create “stuff”:

.

…most models are created manually “new style”..

.

(sculpted in ZBrush or 3dCoat, then retopoed (in either ZBrush or 3dCoat), and finalized in Softimage) the following models were sculpted by Florian Stucki and (partially) myself:

.

140314_skullNbones

140314_huefte

140314_liegendSkelett

.

.

…some are created “old style”…

.

(an aubergine modeled by Babette Kahn in Softimage, which will be detailed later in Mudbox)

140314_frank

.

.

..and some are even created using automated photogrammetry….

.

(canon 7D, a good jacket, autodesk 123Dcatch, and a lot of patience)

140314_wood

140314_wood_close

140314_woodsand

the quality of the (photogrammetry) output varies a lot, but I’ve already processed around 30 models and most of them are quite useable. It’s a nice and cheap way of adding organic detail to the scene.

.

the final images (its broken down into several layers for the game engine) are rendered in 10K (wide), so the overall quality/detail level of all models has to be (and I can proudly say “is”) pretty high, (the cube with the 2 spheres on the left side is a frog dummy, in case you are wondering ;) )

at this point I started to test the set inside the game engine….
…. but more about that later…..

 

140314_dummyset_fill4

140314_dummyset_fill5

.

production crunch report #2 – the first element

March 7, 2014

.

We went right into production after the first designs got finalised and locked. (which wasnt easy… even.. or.. especially because I’m the one sketching and approving them. ;) )

.

sculpting and retopo

.

Florian Stucki started working on our so-called “BottleRocks” element of the first set using ZBrush,

140305_bottleRocks_stucki

I imported all highres OBJs into 3dCoat (to add the last touches myself). Which also happened to be my first “real” session with 3dCoat… and, after some struggle, user errors, and several interface “facepalms”, it ended up feeling quite nice (especially for rocks and hard-surface stuff).

140305_bottleRocks_sh

3dCoats retopo process was fast an easy, but the baking process took forever. I’ve invested around a workday for additional sculpting, but the bake (rebake, and rerebake) process took probably even longer. 3dCoat always produced some (and sometimes a lot) artefacts, and outputted really weird EXRs. (the difference scaling was totally off, so I had to manually match it (Pi*Thumb)).

But after all the work and love we put into this element it would have been a shame to live with sub-par displacements, so I tried to bake it with Mudbox. This time I ended up with way better results, but it took literally hours to bake one rock (some have 20-30mio polygons). And because there is at least some trial&error involved, it would have probably taken days to finish it.

I did end up baking the maps in Softimage, which took around 5mins/rock, and brought decent results (after several tries I must admit ).

Eventually, those six different rocks became the base (instance sources) for most of the “stonework” in the following image. The chicken bone was sculpted and retopo/baked by Florian Stucki  (simply beautiul….for what it is ;) )

140305_rocks_bashkitting

production crunch report #1 – Preparations

February 23, 2014

.

Hi everybody!
has it already been a month? damn!

.

but finally…

… it has begun.

.

 140218_pilz_gross

We decided to move into production, starting in january’14. The goal was (and still is :) ) to create a playable (non-public) demo of the first 3 or 4 sets of the game. a proof of concept if you will.

But this also meant I finally had to finish and lock some of the set-designs. In december, I started sketching bashkit-like elements on paper, arranged/warped them digitally, and over-painted a lot until I was happy with the final layout..

140218_spotlightAnfang_new_layout_15b

.

Preparations..

.

one drawback of external help is clearly the amount of work needed to prepare all designs and references, to sketch and communicate changes, generally speaking to “produce”.

I broke up the set, added descriptions and references

140218_spoAnf_tasks1

140218_spoAnf_tasks2

The mushroom got moved to another set, that’s why its missing in the final layout.

140218_spoAnf_tasks3.

Every element got its own card in Trello  (which is a great, free (online) tool to organize and track everything.) with every info available, and additional references/links.

140218_trello

Thats all for now!
I will cover the actual process of creating some assets next time…

–s

knocking it up a notch

January 10, 2014

an earthworm disguised as tortoise with a dead fish hat?

January 7, 2014

140107_worm_tortoise

just a little fun doodle… :)

first status update in 2014!

January 2, 2014

pen_razer

Hi everybody!

quite a lot has happened. I did a few concepts in december, continued the story and most importantly, I managed to hire a great artist for the first ever ..

production crunch in january !!

Florian Stucki aka “2838″  is going to model/sculpt the first environments, while I’ll work on texturing, shading and lighting. (and I’ll try to build the prototype in Unity in my “free time”).

140102_skull

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)

130712_resolution

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,

-

background

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…

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: