Dealing with Modular Design

Our Demo­li­tion Derby game is mod­u­lar. Each mod­ule is a low poly­gon mesh, and a player assem­bles these mod­ules to cre­ate a wheel-based vehi­cle. These vehi­cles are then used to com­bat other play­ers’ vehi­cles in a sim­u­lated physics envi­ron­ment. Vic­tory is deter­mined by break­ing apart the mod­ules of the opponent’s vehi­cle before they yours.

That’s our game in a nut­shell. It sounds sim­ple enough, but to any­one famil­iar with deter­min­ing appro­pri­ate scope for a game will notice some seri­ous obsta­cles: It’s in 3D, it’s mul­ti­player online — in real­time — and it uses physics. And with all the blocks falling off your car, there are dynamic col­li­sion meshes based on what’s still attached. Did I men­tion that it’s in a browser? Yeah, that’s all in a browser.

Thank­fully, the game­play itself is sim­ple, even if the imple­men­ta­tion is not. Basi­cally, it’ll be you and some friends smash­ing your blocks together, ala kinder­garten, except with a server ref­er­ee­ing who hit whom.

Now, what is it that I do? One of my jobs is to make the game look nice. For a mod­u­lar game such as this, I must pro­vide the play­ers with build­ing blocks. I must also assume that play­ers will use those blocks in every way pos­si­ble. For the sake of sim­plic­ity, the basic unit block is a cube, which has no explicit for­ward direc­tion. The more com­plex mod­ules that do have explicit ori­en­ta­tion will each need spe­cial rules gov­ern­ing their place­ment on a vehi­cle. This is espe­cially true for those that exceed the unit cube size with their mesh or by way of a par­ti­cle emit­ter. With­out the more com­plex pieces, how­ever, vehi­cle sil­hou­ettes would be all right angles, and we want the play­ers to feel like they can be unique if they want to be. It still all comes back to the the cube, as that’s where the aes­thetic of the game is deter­mined. This is what’ll I’ll con­cen­trate on for the rest of this post.

I started with a stan­dard cube: eight ver­tices, six faces.

Build­ing some­thing out of cubes, in the con­text of the over­ar­ch­ing videogame dia­logue, reminds peo­ple of Minecraft. But, noth­ing is truly new under the sun. Our game can be com­pared to Cap­tain For­ever and even Banjo Kazooie 3, but it can also be as eas­ily com­pared to LEGO bricks or even build­ing blocks.

It’s the look and feel of the game that will ulti­mately deter­mine what we’ll be held up against when we’re inevitably com­pared to other games. Hope­fully, we’ll end up with a favor­able com­par­i­son. With­out fur­ther ado, here are two sets of cubes, one with no tex­ture and one with out­lined faces:

I’m of the opin­ion that the out­lines are an improve­ment. It gives me a visual indi­ca­tion of what my oppo­nent is made of, and how much is left. We’re also pulling away from using strictly cubes though the addi­tion of wheels. Envi­ron­ments may also not nec­es­sar­ily be cube-based.

vs.

You’ll also notice here that there is a dif­fer­ence in the rel­a­tive size of cube-to-wheel. On the left, the wheel is three cubes in diam­e­ter, whereas on the right, the wheel is five cubes in diam­e­ter. We call this the gran­u­lar­ity of the work­space. More, smaller mod­ules gives us a higher gran­u­lar­ity, mak­ing vehi­cle cre­ation more com­plex and time con­sum­ing, but allow­ing for greater vari­a­tion. How do we deter­mine how much space is the right amount of space? We need to allow enough space to con­tin­u­ously spur cre­ativ­ity, but not so much space that a novice will turn away from the com­plex­ity of get­ting started. This is all has to be taken into account in the cre­ation of our unit object.

While a tex­tured cube can become just about any­thing, per­haps another way to pro­vide com­plex­ity is to expand our def­i­n­i­tion of “unit object.”

  

Instead of just a retex­turable cube, why not have an array of pieces?

All of the sud­den, and despite low­er­ing the gran­u­lar­ity (big­ger pieces, less space), we now have an enor­mous jump in cre­ative possibilities:

 I’d like to bring atten­tion to how these last pic­tures have no tex­tures on the meshes. These vehi­cles are work­ing off of their shape alone. In fact, at the dis­tance and speed of play, it’s doubt­ful that any appre­cia­ble tex­ture will be vis­i­ble any­way. I only arrived at that con­clu­sion after try­ing it out, though:

Yes, I was able to visu­ally sep­a­rate the blocks, but any detail is lost in-game. This leaves me with bright col­ors and high con­trast as my tools of choice. Rather than remak­ing all the tex­tures again, I com­piled a library of col­ors and sketched out some scenes:

As a player, I would like to be able to clearly see my oppo­nent. Since we’re not mak­ing a stealth game, my oppo­nents can­not look like or blend into the envi­ron­ment. That led to lower sat­u­ra­tion back­grounds and brighter play­ers to con­trast against it.

While it’s clear that I’m bor­row­ing from the nat­ural world in these sketches, the game itself was envi­sioned in a more abstract form. The low sat­u­ra­tion nat­ural envi­ron­ments do help prove the point, though. Unfor­tu­nately, the ear­lier visual sep­a­ra­tion of the blocks would be lost again. But if tex­ture is no longer the method of visual dif­fer­en­ti­a­tion, then it’s back to the shape.

The sim­plest ways to recre­ate that divi­sion while keep­ing the cube’s color solid would be to either drop a nor­mal map on each face, or to have an alpha lay­ered black out­line again. But why not try some­thing new? So at the cost of 200% more ver­tices, I pur­sued the beveled cube:

Basi­cally, I’m try­ing to do away with tex­ture alto­gether, con­tribut­ing to a cleaner look. The extra faces will pro­vide more sur­faces for light to reflect off of, or at least for the shaders to do their magic with. The fact that the sil­hou­ette pro­vides dif­fer­en­ti­a­tion between blocks means that there’s no longer a need for arti­fi­cial out­lines. Frankly, the bevel makes the blocks feel more phys­i­cal and nat­ural than any tex­ture ever did on the stan­dard cube. And this is despite hav­ing the goal be an abstract physics-based play­space.

(the floor is a repeat­ing nor­mal map made using the beveled cube)


With the beveled cube as the new stan­dard, I’ve given all the stan­dard pieces a reboot. I can’t say for cer­tain that the final design won’t change, but I do very much like where this iter­a­tion has led so far.

Though this is prob­a­bly what should have hap­pened first, my next step is to deter­mine, in a more com­plete fash­ion, what the game, as a whole, should look like.

Mak Mendel­son

Mak is an artist at Gra­di­ent Stu­dios. He stud­ied fine arts and then elec­tronic arts, focus­ing in char­ac­ter design. He really enjoys think­ing about var­i­ous game mechan­ics and how they work together, mix­ing and match­ing to cre­ate new ones that might one day end up in an actual game.

More PostsTwit­ter

2 thoughts on “Dealing with Modular Design

  1. I like it. You have more than enough cus­tomiza­tion and indi­vid­u­al­iza­tion with the selected pieces and small set of col­ors. I’m not all the way con­vinced about the bevels, though. Yes, it looks much bet­ter, but in a mult-player set­ting will it put too much pres­sure on the game, espe­cially when the oppo­nents might not be close enough for you to tell? Or are you going to imple­ment a LOD through Unity to han­dle that? Over­all, I like the crisp look of untex­tured build­ing blocks, and com­bined with a color set, could make for a very fun and inter­est­ing design sys­tem. (I just started read­ing, so I’m going to go back through and get more caught up :) )

  2. Pingback: Transition to 2D Vehicles – Why and How | Gradient Studios

Leave a Reply to Ryan Cancel reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>