Creating 3D art for The Time Traveler's Garden (Part 1?)
Hey folks, Omni here again to talk about creating 3D assets for our jam entry, The Time Traveler's Garden.
Why 3D?
It probably goes without saying that the majority of entries to most game jams opt for 2D visuals. I think there's a number of reasons for this. To name just a few:
- the barrier of entry for learning how to author 3D assets in the first place is higher (although modern tools have become very accessible in recent years for anyone brave enough to overcome that initial fear that many aspiring 3D artists have)
- even for those who are comfortable in both 3D and 2D, 3D assets can take longer to produce and implement, especially when game engines are a factor. If the goal is to impress, then it can be more efficient to allot time to 2D assets, as the amount of time that would need to go into 3D assets for the same payoff is often greater.
- working in 3D space (not only with art, but also programming and gameplay design) introduces a lot of complications that would otherwise not be as much of an issue working with 2 dimensions. This includes things like more complex collision, lighting,
But despite this, we knew we wanted to create a 3D game for this jam because we wanted to be able to use this as a learning opportunity. The only way to get better at solving 3D problems is to put yourself in a position where you have to!
Self-imposed constraints
So with all of the potential obstacles in mind, and with only 72 hours to work, there were some key constraints that we gave ourselves in order to give ourselves a better chance of getting as close as possible to a complete realization of our ideas.
Constraint #1: Simplified character design for easy animation


In our case, simplicity meant that our humanoid characters would have no arms or legs, detached feet and hands, and no fingers. This meant we didn't have to worry about complicated IK/FK setups for limb posing, and it also meant no finger posing, which can often feel like posing an entire body. Additionally, the positions of the hands and feet didn't need to be constrained by the characters' proportions. Characters with large heads often have trouble with arm poses, but floating hands avoid the issue entirely.
From a design standpoint, our player character adhered to this principle of simplicity more than our enemies, as the player would require more animations. But even our enemies are fairly simple to animate, even if their designs ended up being more detailed. Two were essentially just a head at the end of a bone chain, and one was just a ball with a bunch of leaf bones for secondary motion.
Constraint #2: Vertex colors everywhere!

Creating materials for 3D models can be a time-intensive process, often requiring multiple texture maps to be implemented for a single model. And before you can even think about texturing, a model has to be UV unwrapped first, which only adds to the time requirement. In a jam, time is of the essence, so instead of worrying about high-fidelity materials, we used vertex paint as the primary means of conveying material characteristics.
Most assets in our game used one shader, which manifested as 2 materials. Both materials make use of the mesh's vertex color for the albedo, with the only difference being that one is set to full metallic and moderately high smoothness (used for things like kitchen countertops, silverware, etc.), and one is non-metallic with lower smoothness, to achieve a generalized, matte surface appearance, which we used for practically everything else.
But sometimes texture goes a long way though
While we relied primarily on the vertex color shader, we did have a handful of assets that we ended up texturing. These assets were ones that were generally entirely flat, large surfaces, such as the walls and floor of the kitchen, the grass and dirt, and some concrete stones slabs (essentially just flattened cubes). Since these assets were trivial to UV unwrap and accounted for a large visual area, we felt it was important to give these surfaces some detail. But we were careful to try to come up with textures that didn't feel too realistic, as this would clash with the assets that only had vertex colors, so normal details were kept to a minimum.
Constraint #3: No blend shapes (shape keys)
I'm a blender boi, so the verbiage I'm more accustomed to is "shape key," but in other contexts, the term is often "blend shapes" or "morph targets." To those who aren't familiar with 3D, the principle of a blend shape or shape key is pretty simple. Basically, rather than using a 3D armature or rig to move the vertices of a model, a blend shape allows you to specify a new position for any given vertex relative to that vertex's default position and then interpolate between these two positions using a slider value from 0 to 1 (or sometimes values higher than 1, but this is uncommon). A single blend shape can therefore specify one new position per each vertex in the mesh. In the example below, I have 2 blend shapes, one that changes the top of the cube to a slanted trapezoid, and another that uniformly moves the 4 top vertices upward.

Blend shapes are often used to easily animate a model in ways that might be prohibitively complex using only weighted rig deformations. Conversely, sometimes a specific deformation would be more easily achieved using a simple bone/joint transformation on a rig, because a blend shape can only interpolate linearly between the 2 vertex positions, which isn't always ideal. Consequently, blend shapes are often used in tandem with a rig to give an animator as much control as possible. Often, a blend shape's purpose is to tweak the shape of a model when a bone is positioned in a certain way (these are often called "corrective blend shapes" or "corrective shape keys).
This particular self-imposed constraint was less about the viability of blend shapes in a short timeframe and more about our unfamiliarity with its implementation when exporting an FBX from Blender and into Unity. I'm very familiar with using bone transformations to drive shape key values, but when it comes to getting that animation data from Blender to Unity, I have very little experience. So we figured it would be best to avoid shape key animation entirely.
That's all for now!
There's a lot more I could talk about when it comes to the art process for our jam entry, The Time Traveler's Garden, but I don't want to monopolize your time. If I have some extra time, I'd like to write about one of the other tricks I employed for producing quick animations, which could come in handy if you're a Blender user.
I also would like to thank everyone who has played our little game! We're almost to 50 ratings!! If you haven't played it yet, I'd definitely like to invite you to try it out as the rating period comes to a close in the next couple days.
