Fez is a complicated beast. Not just in its gameplay — which, as a 2D/3D platformer, can get a little confusing in and of itself — but also in its development. Thankfully, the game’s sole programmer (and one of only two members of Polytron, the game’s developer), Renaud Bédard, was at GDC to shed some light on the game’s development process from a (highly) technical perspective.
For those of you who are not familiar with Fez, it’s a platformer that combines 2D and 3D elements during gameplay, much like Crush or Super Paper Mario. You control Gomez, who moves on a 2D plane, but can round corners to turn the landscape, revealing its three-dimensional nature. This gameplay mechanic and the perspective shifts serve as the primary sources of the game’s platforming puzzles and navigational challenges. Initially announced back in 2007, Fez has been in development for years and has suffered numerous delays: it was due out on Xbox Live Arcade in early 2010, but it has been continuously pushed back and is currently scheduled for a release sometime this quarter.
Fez has an old-school, 8-bit-looking art style, but this wasn’t a choice made only for aesthetic reasons. “From an art- and level-production perspective, working with tiles is easier,” said Bédard. But although the game world takes on a 2D perspective when viewed only from one side, it is still a fully 3D environment (the nature of which you can see during the perspective shifts), so 2D tilemaps did not suffice in the development process. Instead, Bédard used 3D tiles, which he dubbed “triles”, to create the environment. These triles, which essentially served ad Bédard’s building blocks, are in turn made up of 16 x 16 x 16 voxels (three-dimensional pixels, or “trixels,” as he called them).
So to create each type of trile — there are different sets of them for different environments, including the “nature” set that he showed us with grass-covered triles, stone-colored triles, etc. — Bédard would start with a trixel and press in different parts of it to different depths to create textures, and then cobble them together. “This process gives the game that ‘blocky but detailed’ sort of look,” explained Bédard, who went on to say that there was an average of about 136 polygons per trile.
He then showed us in a demo video how he would create worlds in the game’s editor (called the “Fezzer”) by essentially selecting different types of triles and covering a three-dimensional space with them. He could, for instance, select the grass-covered trile and drag it backwards 5 or 6 blocks and then across 10 or 11 blocks to create a three-dimensional, rectangular grassy plane that, when viewed from the side, appeared to only be a 2D plane.
“The whole game is done from the editor, at least visually,” said Bédard. “It’s kind of like building with Legos, which is cool.”
But Bédard then had to take the levels he had created and use culling and batching to in order to improve the efficiency and speed of the game. Culling is essentially a piece of logic that tests the objects in an environment to see if they need to be rendered or not; given the nature of Fez, at most, there are only ever two layers (if the scenery is in mid-rotation) of the level that actually need to be rendered. The rest of the environment that can’t be seen at any given moment does not need to be rendered, lighting doesn’t need to be applied to it, etc.
Batching, meanwhile, helps decrease the amount of traffic required for multiple requests when trying to draw and environment. Bédard could load up multiple requests inside a single batch message, at which point each request would be carried out sequentially over the same connection, cutting down on the traffic each time chunks of the world needed to be drawn (and subsequently making the game run faster since draw calls are so expensive). He also combined this process with instancing — since there were usually lots of instances of the same triles in a level — and loaded up each draw call with as many instances as he could of identical trile types to get the most out of each call. With the Xbox, there is a maximum of 256 instances of the same trile type per call.
Bédard also walked us through how collision and movement in the game were handled. The idea of creating an environment out of these triles made for a rather simple collision management system, as the triles served as the actual collision map. In turn, each trile could be labeled one of four types to dictate what kind of collision it would incur, including immaterial (things you can walk through, like blades of grass), no collision (background elements), top-collide (most platforms), and all-collide (blocking barriers). Art objects, meanwhile, (like planes, decals, etc.) which are not made up of triles, had to be filled with invisible triles to give them collision properties as well.
As for movement, the rules were simple. Gomez only ever moves along the view plane, movement and time are frozen when doing a view rotation (a perspective shift of the scenery), and Gomez’s depth should never be fiddled with, since he is supposed to be move along a 2D plane. Of course, the only exception to this rule was if Bédard needed to make sure that Gomez was never walking in mid-air, or if he needed to implement some sort of depth correction to ensure that Gomez stayed visible. In the final build of the game, Gomez can actually end up behind the level or the scenery post-rotation (in other words, he can end up behind a wall that you’re looking at head-on from the 2D perspective), which is handled by showing a silhouette of his body, playing low-pass music, and essentially limiting his actions until he walks back out from behind the wall.
Before moving on to his reflection on his experience with programming Fez, Bédard also touched on the game’s time-of-day lighting, scripting (he was fond of the scripting system as it required no code, it was “all just a bunch of dropdowns basically, so you don’t have to do any coding”), and, perhaps most interestingly, its music system. Also handled in the Fezzer workspace, the music is essentially randomized and based on the scripted events. Using clips that combine with each other as they fade in and out at randomized interplay delays (e.g. anywhere from 0 to 16 bars), the music is continuous and infinite. The time of day affects it too, with daytime and nighttime presenting different sets of music tracks to blend together.
Pages: 1 2