It's Gomez Time (Again)
Reflections on Demaking FEZ
Since then, it has become by far my most popular project to date with over 12,000 plays on the PICO-8 forums, over 13,000 views on itch.io, and an overwhelmingly positive response from folks online. It even got the attention and appreciation of Renaud Bédard, the programmer of the original game, which was incredibly flattering and cool to see.
Now that it just turned one year old last week, I thought it was high time to do a reflection on the game and everything that went into it.
This post will be spoiling most aspects of the experience of FUZ, as well as
You can play FUZ on itch.io and on the PICO-8 Forums,
some details and puzzles from the original FEZ. If you care about that and
haven't played them yet, I recommend you do so before reading this!
(It'll also just make way more sense with context.)
and you can find info on FEZ from the official site!
|01. Some Summertime History||What led up to FUZ|
|02. Spire, FUZ's (Slightly) Older Cousin||FUZ's direct predecessor|
|03. Fuzzy Beginnings||How FUZ got started|
|04. Distilling Cubes, Please Stand By||Translating FEZ into PICO-8|
|05. And Now for the Twist||Rendering and rotation|
|06. Walking Right Into a (Development) Wall||Early collision struggles|
|07. Some Time Later||Recovering inspiration|
|08. Deep Thoughts||Revisiting collision|
|------------------ SPOILERS BEGIN ------------------||-----------------------------------------|
|09. Nuish||Designing the Nuish alphabet|
|10. Hypercube Interlude||Making Dot (and clouds)|
|11. Revving the Engine||Kicking dev into high gear|
|12. Puzzling Matters||Implementing FEZ puzzles|
|13. The Longest And/Or Shortest Puzzle||Designing the Nuish puzzle|
|14. The Fakeout||Implementing you-know-what|
|15. One Final Secret||Adding FUZ's deepest secret|
|16. Audio||Notes on sounds and music|
|17. The End Result||Reflecting on the final game|
|18. Aftermath||Post-FUZ personal effects|
|19. Reception||Discussing the fan response|
|20. Final Notes||Where I am now and next|
Some Summertime History
FUZ was started back in the summer of 2017, I believe while riding in a car on vacation with my family. It technically began as one of my earlier projects with the PICO-8 fantasy console, and although it wouldn't see the light of day for years it was in some ways the culmination of that summer. That was an important time for me for a lot of reasons - I got my first job, I started my Twitter, I turned 18, I was preparing to head off to college for the first time - but most importantly for this, it was the summer I really sunk my teeth into PICO-8 and began taking game development seriously.
While I'd been experimenting with making video games since I was about seven, and even finished a handful of them, it wasn't until I released Messages on June 16, 2017 that I ever put a proper game of mine publicly online. Messages had been deliberately planned as an introduction to PICO-8 and didn't make use of any of its more complex features, but now that I'd gotten a taste of working in it I was eager to see what else I could do.
In a fit of productive creative energy I don't think I've since matched, I went on to almost immediately delve headlong into my second major release, the RPG A Dream's Command. ADC started with the idea of seeing if it would be possible to make a PICO-8 RPG with a combat system centered around simple minigames, kind of like Mario RPGs. Once it became clear it was doable I didn't stop until it was finished, chipping away at it whenever I could outside of my summer job at Target. I ended up releasing ADC on July 30th, while on a family vacation no less, and then made the logical next step of jumping right back into tinkering with my next project. This time around, I was completely comfortable with PICO-8 and eager to explore ways to really push its boundaries.
Spire, FUZ's (Slightly) Older Cousin
At the time, I was intrigued the most by PICO-8's spritesheet. Like many aspects of the fantasy console, it is severely but not impossibly limiting. You have literally 16 colors and 128x128 pixels of space to work with, and the whole lower half of the spritesheet shares data with the tile map. The map itself is just 128x64 tiles (each assigned to an 8x8 sprite), so you have very limited space on both fronts.
What I realized was that you technically can get more map space out of the lower half of the spritesheet if you use individual pixels to represent tiles (as opposed to the 2-pixel scheme the built-in map system uses), at the cost of implementing the rendering system yourself and generally only being able to use up to 16 tile types at a time (one for each color).
Conveniently for this, PICO-8 uses numeric IDs to reference both sprites and colors. It also lets you read pixel color data from the spritesheet directly with the built-in sget function. As such, one can very easily read pixel colors, map them to specific sprites, and draw those sprites at the appropriate world coordinates.
As such, the spritesheet data displayed in the upper-left region can be translated directly into sprites.
Now, on its own admittedly this isn't that exciting. But, I had a plan. Drawing some loose inspiration from FEZ's laid-back perspective-shifting platforming (and I suppose the level structure of a now-removed iOS game I used to play called Rinth Island), I came up with the idea to create a climbable tower out of columns of sprites represented internally through this spritesheet method. The player would also be able to leap through the center of the tower at certain points to reach the opposite side.
Although it would have a 3D-like appearance, internally the game would really be 2D with the X-coordinate
wrapping around via modulo. The player's coordinate would match up to a spritesheet pixel location, allowing
them to detect collision with floors and walls by sampling the spritesheet pixels near their position. The
clouds in the background also would rotate along with the player as they moved, staying at consistent locations
relative to the tower.
(I'll spare you the details of exactly how this and the rendering all work because it'd be better suited to its own post, but I bring these aspects up now since they'll be relevant later.)
At any rate, three days after launching ADC I had developed a proof-of-concept demo of this tech, tentatively called Spire, sufficiently enough to be ready to show it on Twitter:
This little tech demo kind of exploded in popularity, especially given how small my following was back then (it's still one of my most popular tweets of all time, aside from a few about FUZ itself). Apparently the demo bore a striking similarity to some older games/levels I'd never even heard of at the time, namely Tower Toppler, Nebulus, and the Kirby's Adventure level Butter Building. The whole thing unintentionally turned into a kinda fascinating conversation piece between generations of gamers.
But despite all of the attention, my inspiration was faltering on the process of actually turning it into a proper game. At one point I attempted making an enemy but could not figure out how to get it to move and render how I wanted. I was also having difficulty finding a performant method of smoothing the depth-based color transition in the rotation effect, which certainly didn't help with motivation. As such, the project quickly got shelved. (That's not to say I'm opposed to ever revisiting this tech later, but no promises for now.)
Anyways, back towards FUZ.
Although the Spire demo got set aside, it wasn't a dead end. Shortly after moving on from it, I had a revelation: it might be possible to modify the same pixel-color-as-tile technique to store a textured voxel model in the spritesheet. And with that, it might be possible to actually attempt a proper FEZ demake, not just make something vaguely inspired by it.
There would, of course, be some limitations to the system. For instance, I'd only be able to map one sprite to each pixel, so voxels would only use a single texture regardless of perspective. Fortunately, FEZ's side-view perspective meant that you would only ever see blocks from the sides in normal gameplay so this wasn't much of a concern.
I now had a new mission, and a proof-of-concept prototype was in order.
Now, you may be wondering why I had the urge to tinker with FEZ of all things in the first place. It wasn't exactly new in 2017, even for me. You might reasonably assume between that, actually releasing FUZ, and now writing this whole thing that I'm just a superfan obsessed with it. And you'd be kind of right, I suppose. While I wouldn't actually label FEZ one of my personal absolute favorite games, haven't ever quite gotten the 200% ending (as of writing this, at least), and haven't really delved into its deepest-held secrets, I can't deny that I'm a fan or that it's been an important game for me.
I first stumbled across and played it way back in July 2014 from a Steam sale (I think it was one of my earliest game purchases). I thought it was neat, but I got the 100% ending and didn't really do much else. I later revisited it and got way more into it in early-mid 2016. I tracked down almost all the Anti-Cubes, found all the relics, and (once I learned about the "Rosetta Stone" room) took a deep dive into learning and deciphering Zuish, the coded text hidden throughout the game. In fact, Zuish quickly became one of my favorite elements of the game. It got to the point that in my Senior year of high school I could read and write in Zuish without even needing a reference sheet.
So yeah, I guess I'm a pretty big FEZ fan. I appreciate the non-violent exploration-centric gameplay, I love how mechanically unique it is, I love the aesthetic, and I really love the whole Zuish language. FEZ even introduced me to Disasterpeace, who remains one of my absolute favorite musical artists to this day.
Given all that, I suppose it's no wonder that it got lodged deeply enough in my brain for me to want to try demaking it.
Distilling Cubes, Please Stand By
Based on my files, I started making FUZ on August 6, 2017. The first order of business was to figure out how to represent the world. If you've ever played FEZ you know the game is broken up into many diorama-like rooms, grouped into areas with themed tilesets. It's a game of remarkably vast, open scope, to the point I believe it's a bit notorious for giving people choice paralysis. This presents a dilemma with the prospect of making a PICO-8 demake, as everything about PICO-8's design drives and forces you to scope small and simple. There was no way for me to cram in multiple biomes of textures and environment details and still have room for an interesting, faithful game. On top of that, PICO-8 sprites are only 8x8, versus the about 16x16 of FEZ's tiles, and I couldn't afford to use larger sprites.
My solution to the issue was to simplify the world tile textures drastically and represent just a few of the most commonly-occurring types as best as I could with the PICO-8 palette. Rather than having numerous variations of each type, I had three: a normal wall and two grassy versions. I also added a generic dark one to use for wall blocks cast in shadow, along with tiles to use for treetops and wooden walkways. I made sure to preserve the trademark thin edge shadows and highlights of FEZ tiles as well, where possible.
but these work well together and help ensure that other gameplay elements contrast appropriately.
While I was at it, I also created sprites for Gomez, the protagonist of FEZ and FUZ. Due to the small room size afforded by PICO-8 and the complexities of the movement code and spritesheet space required, I opted to remove Gomez's abilities to hang from ledges and to climb. Even still, I ended up using a significant chunk of the spritesheet for him, primarily to give him as smooth and faithful of a walk cycle as I could but also for details like blinking, jumping, falling, and excitement.
Technically in FEZ he keeps his mouth hidden when running, but I opted to include
it to give him a little more charm and personality where I could. Zero regrets!
While some may argue that going sprites-first is kind of a backwards or inefficient way to get started, I think it's important for a demake in particular to ensure that you're going to be able to capture the aesthetic you need to before delving too far into it. It's the ol' "fail faster" mantra, I guess. (Plus 8x8 and 8x16 sprites are pretty quick to draw, anyways.)
And Now for the Twist
Once I had world tiles and a character drawn, the next task was to devise a way to internally represent and render the world. This is more complex for FEZ than most platformers thanks to its unique movement system: the world appears 2D, and Gomez interacts with it as such, but it's actually 3D and made of voxels instead of flat tiles. The player can rotate the world between four side-view perspectives, and Gomez will treat whatever is currently in-view as ground. This leads to some bizarre spatial shenanigans where, as a simple example, you can cross a huge gap by just rotating the world to a perspective where the distance is manageable and crossing from there.
These screenshots are taken with Gomez at the exact same position in the world,
just viewed from a different angle.
For my project, this meant two things:
1. I needed a way to represent and render voxel models in a tool without built-in 3D support.
2. I needed to allow the player to rotate the perspective they see the world from.
The solution I came to for the former issue was to store each room's voxels in a dozen 12x8 pixel slices over a 12x96 pixel region of the spritesheet. Why those dimensions? After investigating the size of the screen and spritesheet, I decided that 12x8x12 voxel rooms would be the optimal room size. This would let me make them large enough to fill most of the screen with playable content (the screen is 16x16 tiles) but keep them small enough to let me cram eight or more rooms into the spritesheet. It also works out that the levels would be small enough I can completely omit FEZ's fall damage, a feature I can't say I miss anyways.
As with before, each color of pixel maps to a specific sprite tile. These tiles are drawn back to front in vertical layers based on the current perspective, ensuring that they appear in the correct order to give the impression of being in true 3D space. However, there is one special case: pixels marked with color 15 (tan) represent an actor - an entity with special drawing code, such as door or tree trunk. When reaching one of these points in the draw loop, the game will look the actor up by their coordinate and use their specially-defined drawing method instead of the default simple sprite tile one.
which it draws based on the current perspective (right).
The model slices are ordered bottom-to-top (going down) to simplify coordinate calculations.
(If the seemingly random tiles at the bottom seem weird, hold onto that thought...)
Now that the underlying tech was in place, I needed to create the rotation effect. This presented an interesting challenge, as my voxels weren't actually rendered as 3D cubes, they were just square 2D sprites drawn at the locations of the voxels. As such, there wasn't an option to just rotate the camera around the world - in fact, I ended up needing a separate drawing function for each of the 4 perspectives as they each read the world data in such different orders.
I realized I could get part of the way to cheating the effect by progressively offsetting the voxel layers based on their distance from the center, switching the view, then making the layers settle back into place.
It wasn't flawless, but because the offsetting reveals the edges of tiles on deeper layers it gives the impression of seeing the next side of the voxels as the structure rotates surprisingly well. The view transition, however, was a different story. The illusion of rotation completely fell apart at the very jarring jump point between perspectives. To remedy this I tried adding on an overlay effect that swept by and hid this cut, and the results speak for themselves:
I immediately knew I'd found my solution. Sure, it relied entirely on an illusion, but the effect was quick enough that didn't matter. This essentially was the final effect I used, just with some tuning to the look and speed, as well as adjusting the color used by room (to help minimize how jarring it looked).
Once I had the rotating effect satisfactorily implemented, I was struck with an idea for how to incorporate it into the title screen and so got to work making that, too. Since it wouldn't be feasible to do the fancy rotation and zoom animation it does in the original without devoting a ton of code resources to it, I instead opted to make the title text transparent to reveal the world rotating behind it. This allowed me to easily keep it visually interesting and give a little teaser of what lies ahead, in a manner loosely inspired by the FEZ II teaser trailer. I made it using primarily sprites applied as map tiles, but I couldn't reasonably make enough sprites to get it perfect so I also touched up some details by drawing elements through code.
Incidentally, I don't think I have a very sound reason for why I chose FUZ as the project name so early on. It just felt (heh) right - it was only slightly off from the original (like any good bootleg), it sounded appropriately cutesy or silly, and actual fez hats should be a little fuzzy anyways thanks to being made of felt.
By this point, the project was really starting to show promise, but one major hurdle remained.
Walking Right Into a (Development) Wall
Next came the most complex part of the whole game: the movement system. At a glance it might not seem that tricky: without ledge grabbing and climbing it would just simple jumping. Ceilings and horizontal walls and aren't an issue because they literally don't exist in FEZ - Gomez can freely move anywhere. Heck, I'd even already gotten basic tile-based platform collisions like this working with Spire.
And yes, getting that far was relatively trivial. I made the concession to have Gomez only able to stand on grassy surfaces, treetops, and wooden platforms, as finer-tuned collision with many props like in the original FEZ would be unnecessarily complex. With this, I was able to just treat tiles in a certain range of colors as solid ground, and voila, platforming worked from a 2D perspective. (Ok to be fair it wasn't that smooth, ironing out the kinks with landing smoothly on blocks took a while even during later development.)
The rotation mechanic, however, threw a wrench into everything. Although Gomez appears to treat the world as 2D, he still has to move in 3D coordinates under the hood. To stand on a platform you have to align with it on both the horizontal axis (of the camera's perspective) and the depth axis, as otherwise you'd completely lose your position when you rotate the world.
For walking, this doesn't add much complexity. Walking left and right just need to move Gomez in the appropriate directions along whichever axis is horizontal for the current perspective. Things get trickier, however, when you need to then update his position in the current depth axis to reflect whichever platform he's standing on.
The naive approach would be to simply look for any floor aligned with Gomez's feet from the current perspective. If there's floor in the appropriate row/column of the slice below him, Gomez gets placed at the closest region of it to the camera you can stand. Otherwise, he falls.
This sounds reasonable, but there's a key flaw: it doesn't account for walls.
With the way FEZ's logic works, surfaces that are hidden from view by changing the perspective still technically exist. If Gomez ends up standing on one after rotating he treats it like normal ground and, until he steps out into view, only interacts with floor behind the wall. Thus, there are a few different cases to consider with this. Gomez could be in front of all walls, behind all walls, or in between two. And the moment he steps out into view, he effectively moves to the foreground and can no longer collide with hidden floor. And unfortunately, that's where I got stuck.
I banged my head against this issue for a while, but ultimately didn't get far and couldn't seem to iron out the kinks I needed to. It didn't help that I was also having issues detecting floor that was close to the camera on the right and rear views. While I was reasonably sure I was just missing something, I couldn't crack the problem at the time and it didn't feel worth the headache. And thus FUZ too was shelved, at the ripe old age of three days old. I never even mentioned the project online; it was just too nonfunctional.
Some Time Later
Fast-forward to late April 2019. A lot had happened since I'd last done anything FUZ-related. I was wrapping up my second year of college. I'd gotten way more experienced with PICO-8, with two of my games made in it (Night Fright Flight and I Just Wanna Land!) even getting showcased at my college's Interactive Media and Game Development PAX East booth. I'd also dove headlong into pixel art, doing daily pieces through Pixel Dailies for over a year straight (I'm still going as of writing this, incidentally).
Around the start of that school year one of my roommates had picked up FEZ and got very into it himself, bringing the game back into my focus a bit. Then on April 14th, Pixel Dailies happened to pick "fez" as the daily theme. Naturally, I took the opportunity to use that as an excuse to make some FEZ fanart (complete with a FEZ-themed haiku written in Zuish):
#FEZ is a really cool game ok— Henry Stadolnik (@Jusiv_) April 14, 2019
Great aesthetics, interesting mechanics and puzzles, and also that soundtrack (Disasterpeace is so good)@Pixel_Dailies #Pixel_Dailies #PixelArt #Pixel #PyxelEdit @Polytron
(437x Streak!) pic.twitter.com/u94pSaSis7
For whatever reason, that piece of fanart was the catalyst I needed. That day, I made some time and cracked open my old FUZ file.
With fresh eyes and renewed inspiration, I was ready to revisit the task of programming FUZ's platforming. This time around, I was careful to come up with a well-defined plan for achieving this. The two most critical changes I made were to introduce a boolean tracking whether the player was exposed or hidden behind a wall (as opposed to determining this solely by his position) and to overhaul the floor-detecting system.
The core steps of the revised floor-detection algorithm I devised were as follows:
- If outside the bounds of the room, mark Gomez as exposed and skip to step 6.
- Exception: if Gomez was not exposed and is falling off the map, keep him unexposed.
- Store these for easy access
- This sets the near boundary to search for floor within.
- If no wall is found, mark Gomez as exposed and set there to be no near boundary.
- This sets the far boundary to search for floor within.
- If no wall is found, set there to be no far boundary.
- If floor is found, set Gomez's depth so he is standing centered on it.
It might be worth noting that this isn't a perfect implementation of FEZ's movement system. In particular, Gomez's position when rotating is much less stable: in FEZ if you rotate in place Gomez will always stay at the same coordinate, but in FUZ he technically gets pulled to the nearest edge of whatever surface he's on. That said, I'd argue my version is a good enough approximation for imperfections like this to not really matter, and I think most everyone who's played FUZ agrees.
One other issue that'd been bugging me was figuring out how best to show Gomez's position to the player when he wasn't fully visible. FEZ itself draws parts of him behind walls as a silhouette, tints the screen slightly darker, and muffles the audio, but unfortunately those are difficult to effectively replicate in PICO-8.
Initially, I tried to go the route of drawing Gomez directly as part of the world drawing loop, making him appear at the exact correct position based on the depth ordering. I was even hoping to be able to draw his head and body separately when he was partially behind things.
However, this proved to be needlessly over-engineered and counter-productive. The far simpler solution was to just draw Gomez as an overlay after drawing the room, and to display him as either entirely in shadow or in full view (without any intermediate state besides a quick fade animation) using palette swapping. I'd have to show his whole position anyways, so there was no need to include logic to draw him with depth sorting.
I did actually opt to keep the system of drawing Gomez's head separately from his body, though. It turned out to be a nice way to add some expressiveness and polish (like reacting to landing or indicating when you're dropping down from a platform).
Watch closely and you can also see Gomez's little head movements.
(Also check out that sweet sweet debug overlay with room slice readouts.)
With this all implemented, I found myself with a working FEZ-like engine. At long last, the game could continue!
That evening, I revealed my project to the world:
So yesterday apparently got me on a FEZ kick, because today I dug up my old broken attempt at a PICO-8 FEZ demake (which I'd started 2 summers ago) and actually got the core mechanics functioning!#Pico8 #FEZ #Demake #Gamedev #Indiedev @lexaloffle @Polytron pic.twitter.com/6MrCt2D3py— Henry Stadolnik (@Jusiv_) April 15, 2019
I was fully planning to finish this anyways, now that I'd gotten through the biggest hurdle, but the immediate and dramatic positive reception this first tweet started drumming up certainly further encouraged it. I was locked in now.
(Brace for significant FEZ and FUZ puzzle spoilers from here onwards! You've been warned!)
As I'd mentioned before, one of my favorite aspects of FEZ is the decodable Zuish language. Snippets of it are found engraved throughout the game's world and sometimes as dialogue, offering splashes of flavor and worldbuilding, factoring into a select few puzzles, and going a significant way towards making the world feel like it has history. On top of that, the text also just plain looks really dang cool. I absolutely wanted to capture some form of Zuish in FUZ.
However, the actual details of implementing it were less straightforwards. Zuish characters are usually written as 5x5 pixel symbols, and can't really go smaller without losing detail and distinctiveness. This was a poor match for PICO-8's emphasis on 8x8 sprites and limited spritesheet space, which meant that to fit the text neatly in without taking too many resources I'd need to find a way to represent the characters in 4x4 pixels instead. And even if I did find a way to legibly crunch the characters down, people would then be able to use existing decoding guides to crack the text right off the bat (which would let them bypass any puzzles I made about decoding it).
One silver lining here was that the Zuish alphabet has the quirk of only using 24 characters (K and Q share a symbol, as do U and V). As such, if I could find a way to make 4x4 Zuish characters I'd be able to cram the entire language into just six sprites worth of space. The language is also formed only of six base characters, each rotated in four orientations to reach the total of 24, so I'd only actually need to design six unique characters in the first place.
(Have I mentioned Zuish is aesthetically pleasing?)
I wanted to figure out how to handle Zuish before proceeding too far with development, so I ran a poll on Twitter to see whether people thought I should try to recreate the original Zuish characters or devise my own. The clear winning result ended up being to create my own character set. Which was good, because if I recall correctly by that point I'd already made the unique character set I wanted to use (I have a bit of a thing for drawing pixel fonts, ok?). And anyways, the uniqueness ultimately helped me make more interesting puzzles.
I ended up dubbing the resulting language Nuish - y'know, like Zuish but new-ish. It followed all of the structural quirks of conventional Zuish, but had a completely different set of 4x4 pixel characters and assigned the symbols to the letters differently (so there wasn't a direct Nuish counterpart for any Zuish base symbol).
Once I'd designed Nuish, I created a special tile actor to display them in-world, automatically setting its own size based on the text provided to it. True to the original Zuish, Nuish is also read top-to-bottom then right-to-left (as opposed to how English is read left-to-right then top-to-bottom). After implementing this (and revising the title screen logo to properly match the style of FEZ's one), I posted my next update:
FUZ Update:— Henry Stadolnik (@Jusiv_) April 21, 2019
- Revised the logo! It matches FEZ's one better now style-wise.
- Reworked the object drawing system to be a lot more flexible.
- Added Zuish (using a unique set of 4x4 characters)!#FUZ #FEZ #Pico8 #Demake #GameDev #IndieDev #ScreenshotSaturday pic.twitter.com/ccBgRkh6j7
(The latter was in reference to Renaud Bédard for his comments on my original FUZ post)
My next major step wasn't necessarily the most interesting advancement to talk about, but it was an important one: I implemented Dot, Gomez's trusty tesseract companion!
Given the scope I was planning for FUZ, Dot was a key addition as nothing else in the game would be able to explain the significance of anything or what your objectives were. As in the original game, Dot appears out of thin air to talk to you whenever something important happens or you approach an object of interest.
Ironically, I'd never actually written code to manually render anything properly 3D before doing this - I jumped straight from 2D to 4D. And despite carefully studying how Dot looked and animated in FEZ and tinkering around with a customizable hypercube animation I found online, I never actually figured out how to accurately recreate the way Dot moves.
I knew from the start that there was no way I was going to be giving them solid shading, as PICO-8 doesn't provide built-in support for drawing triangles or for blending colors and it would take way more resources to make them myself than would be worthwhile. Likewise, I didn't attempt to recreate the room preview effect they provide when Gomez stands near a doorway, and just relied on the small scope of the planned map to keep navigation manageable.
Instead, I drew Dot in wireframe using a range of different colors, interlinking in a loosely gradient-like manner, and made them drift around while rotating in 4D. The underlying tech isn't actually that strange, it's just a set of 16 vertices connected in such a way as to form a hypercube, with their coordinates rotating about the YZ and YW planes. The fourth dimension of their position is represented as a scale factor on their relative position, so Dot appears to have two shifting cube "layers" linked by edges.
Incidentally, I also added clouds in this update, which while less-than-exciting as a concept definitely helped add some visual flair and interest to the game. When the player rotates the world they move with it, staying at the same relative location to the perspective they were viewed from and looping around when the player rotates far enough. I styled them directly after the way clouds look in most areas of FEZ:
I'd later go on to revise the system to let me have different cloudline heights, cloud color, and sky color, which together really helped to make the different rooms in the final game be visually distinct.
Revving the Engine
By May 4th, progress had really started picking up. I was finally out of college for the summer and free to devote myself to the task at hand. I'd gotten most of the core tech working by then, including transitions between rooms via doors (which in true FEZ fashion function more like portals than logical physical connections), creating collectible Cube Bits (the main collectible objective item from FEZ), and some underlying tech for detecting sequences of inputs (more on that ahead).
FUZ Update #4!— Henry Stadolnik (@Jusiv_) May 4, 2019
- Area transitions!
- Cube bits!
- Some underlying/hidden stuff!
I'm getting close to feature-complete, but the cart is also close to full so we'll see how much extra polish & stuff I get to fit in.#FUZ #FEZ #Pico8 #Demake #GameDev #IndieDev #ScreenshotSaturday pic.twitter.com/01siGGKevA
All that really remained was to put together the game's actual content and get it out the door.
When adapting a puzzle-heavy game like FEZ into a demake, you have to strike a balance between crafting faithful recreations of puzzle mechanics and actually presenting new content. Fail the former, and it kind of defeats the point of a demake in the first place. But fail the latter, and diehard fans who know the original by heart and would be most eager to play your demake won't find any of the challenge that got them into the original game in the first place. My main approach to this in FUZ was to preserve the core mechanics of the puzzles, but wherever possible change up the details enough that it would be impossible to use pre-existing guides for FEZ to solve them.
One major perk of FEZ puzzles (from the perspective of demaking them) is that oftentimes they use shared mechanics. In particular, there are multiple categories of puzzle that listen for a specific pattern of inputs (like moving, jumping, and rotating) and react when the player successfully enters it. The main differences between them are instead which specific inputs they listen for (some only care about rotations, for example) and what methods they use to communicate the target pattern to the player. This type of input listening proved to be rather straightforwards to implement and versatile while requiring minimal situation-specific assets or code, so I opted to model many of FUZ's puzzles after these.
One of the simplest types of these puzzles are Tuning Forks. If you listen closely, these signal a specific sequence of left and right inputs through audio cues (as well as through directional controller vibration). If you rotate the world left and right in the indicated sequence, you are rewarded with a prize (usually a special collectible progression item called an Anti-Cube).
I implemented this almost identically in FUZ, except since there is no vibration option in
PICO-8 and I didn't want to force people to try to interpret PICO-8 sounds, it instead uses a combination of sound and a simple visual indicator.
(shown with the solution)
A more complicated class of FEZ puzzle incorporating this type of tech are the Etched Pillars
(I have no idea if that name is official but I'm going to use it anyways). These are mysterious stone obelisks adorned with an irregular vertical groove, which repeats on each side. You find these scattered around several locations in the world, but it's unclear what significance they're supposed to have until you stumble across this room:
while the Etched Pillar on the right indicates a sequence of actions.
The device currently shows the symbol for "rotate right".
While Gomez stays near to the grid-like device in the room, its lights turn on in specific patterns in response to which actions he takes, namely directional movement, rotating left and right, and jumping. If you look closely at the marking on the Etched Pillar, you can actually tell that it's constructed from connected tetrominos (this is especially obvious looking at the bottom-most symbol). It just so happens that the symbols that the device correlates to the player's input are also tetrominos. Coincidence? Most certainly not.
If you've made the observations above, it logically follows that there should be some way to interpret the Etched Pillar's marking as a pattern of inputs. But if you try to just read the pattern directly, you'll find that something doesn't quite add up: there's no symbol produced by the device that exactly matches the markings like the one at the bottom of the pillar. What gives?
As it turns out, the symbol at the bottom does in fact match, but seeing how requires a different perspective. The key clue here is that the marking at the bottom has the correct shape but in the wrong orientation. If you rotate the etching 90-degrees counter-clockwise you get a sequence of symbols that exactly matches the set displayed on the device:
And, lo and behold, entering the corresponding pattern of inputs completes the puzzle.
(Yes, I'm aware there's also a note you can find elsewhere in the world of FEZ that clues you into the fact you can break apart the marking and rotate it, but I figured it out without that on my playthrough so I don't consider it critically important).
When recreating this puzzle type in FUZ, all I really had to do was break it down into a to-do list of key features and come up with equivalents for them. Specifically, I needed:
- A distinctive set of symbols, including ones that can be used to
deduce the correct reading orientation.
- Something that reveals the symbols in response to player input.
- Etched Pillar objects that listen for a specific pattern of inputs.
Although it would have been feasible to directly re-use the original tetromino symbols from FEZ since they were so small and simple, doing so would allow people who had played FEZ before to skip over my Etched Pillar puzzles by just using their prior knowledge of how to read them. As such, just as I did with Nuish, I instead made my own set of symbols to use:
The "rotate left" and "rotate right" symbols here were specifically chosen to be easy to recognize against the others (they have no 2x2 pixel filled region and have a 2x1 pixel protrusion) and to be usable as reference points to orient the etched markings for reading. Since there's no symbol with an isolated 1x2 pixel vertical section, the presence of that marking on an Etched Pillar can clue the player into the need to rotate the symbols. The directional symbols, on the other hand, were deliberately chosen to differ from each other only in orientation instead of shape while still indicating a clear direction (just like the directional symbols FEZ itself used).
To address the second requirement, I looked to FEZ's skies for inspiration. They have naturally-appearing (but usually meaningless, to my knowledge) tetromino-shaped constellations you can spot at night.
I wanted to use as little extra art as possible, and since I had already settled on simple 3x3 pixel shapes for the etched symbols I realized that displaying them on a 3x3 constellation would be the perfect solution. I could draw it entirely using code and sample the spritesheet directly to figure out what patterns to draw, so it wouldn't cut into my art budget at all and would be relatively cheap from a code perspective as well. This was how it ended up looking:
The final piece of the puzzle was to create the actual Etched Pillar tile actors. These were based off of the Nuish text ones I'd already made, and used a similar system to display their markings. I ended up putting two in the final game, with the one in the constellation room designed to be much more easily read:
If you've played both the mobile-friendly and original versions of FUZ, which differ only in their control scheme, you might have noticed that the Etched Pillars actually look slightly different. This is because the revised control scheme changed up the button input set and required me to add an additional possible symbol to these puzzles:
The puzzles are functionally identical aside from this.
Together, the Tuning Fork and two Etched Pillars in the final version of FUZ are 3/4 of the main puzzles in the game. The final one, however, is entirely different and far more original.
The Longest And/Or Shortest Puzzle
While the Tuning Fork and Etched Pillar puzzles served as great callbacks to the original FEZ, they borrow so heavily from it that people already familiar with the game should be at a significant advantage with figuring them out. To help combat this, for the remaining major puzzle in the game I really wanted to take things in a more original direction. And I knew the perfect way to do it: create a puzzle centered around decoding Nuish text.
In the original game, you learn the non-numeric part of the Zuish language in essentially one giant info dump from a place I refer to as the Rosetta Stone room. There's a tablet with the classic "The quick brown fox..." pangram inscribed across its sides, and a dog and fox right next to it perpetually acting out the sentence. If you successfully make the connection between them, *BOOM* you've learned the language.
Now, this works perfectly fine for FEZ's purposes. It also conveniently removes all ambiguity about the fact that certain letters share a character. However, as far as being a puzzle goes there's not much to it - you either pick up on the environmental clue and the whole thing clicks, or you don't and don't get anywhere with it. As much as I love Zuish, I've always felt like this binary approach to learning it could have been handled in a more interesting way.
It turns out that Hyper Light Drifter, one of my absolute favorite games of all time, actually has its own language to decipher as well, and I love that game's approach to it. Essentially, you find text organically in the world in meaningful contexts (like the sign for a shop), and by combining this contextual information with the character meanings you've previously deduced you can incrementally work out the whole language.
(Taken from https://steamcommunity.com/sharedfiles/filedetails/?id=659081549)
Thus for FUZ, I set out to devise a puzzle that combined both games' approaches. It would have players incrementally decode the language by observing environmental details and drawing upon their previous findings, and then use this information to decipher instructions on how to reach the solution. I specifically wanted to do this in such a way that zero prior knowledge of FEZ and Zuish would be required.
The first step was to come up with the puzzle's solution. Since FEZ is somewhat known for having some 4th-wall breaking elements and puzzles, and PICO-8 lets you create and remove custom pause menu options, I hit upon the idea of making the solution instruct the player to open the pause menu and press a special custom option only available in one room. Of course, this does have one major flaw: people can stumble into the solution immediately if they just happen to pause the game in the room. Fortunately, this is used nowhere else in the game and FUZ is short and has no threats or action-centric parts, so I saw very little reason the average player would be entering the pause menu ordinarily. And since launch I've only ever heard mention of this accidental exploit happening a single time that I can recall, so I think for the majority of players it worked as intended.
Issues and all, I was really entertained by this concept and so I decided to proceed with it. The plan was as follows:
- Make a room with a lone tablet that reads "ENTER THE PAUSE MENU" in Nuish.
- (The Enter key opens the pause menu, so Enter serves double-duty here.)
- Give that room a special "ANTI-CUBE" menu option that spawns an Anti-Cube the first time it is selected.
- Identify places in the world where I can create clear environmental clues and place Nuish text nearby
- Each piece of text should reveal the meanings of some new characters.
- There should be a few base Clue Phrases that are each possible to decipher from context alone without prior Nuish knowledge.
- There should be character overlap between phrases to create a sense of progression.
- Where possible, include additional pieces of text that aren't puzzle-critical but add to the lore or offer clues for other puzzles.
The first two steps were straightforwards. Step 3, of course, is where this got complicated.
My approach to constructing this puzzle was to start by making a table listing out the Nuish alphabet in English. I marked all of the letters that were required to decode the solution phrase ("ENTER THE PAUSE MENU"), then got to work devising Clue Phrases.
The first and most obvious phrase to go with was "WARP GATE", as by this time I had already planned for that the game to start with Gomez arriving through a warp gate. Conveniently, it would actually make sense for a warp gate to be labeled as such, and Dot even specifically calls it that, too. Because the phrase would fit best in two columns, this would also be crucial for teaching the peculiar reading order of Nuish. As such, this was a no-brainer to include. It also had good required letter coverage, namely checking off A, E, P, R, and T.
One feature that was sorely missing from FUZ at this point was critters. The original FEZ is jam packed with all sorts of cute little animals, but due to rendering and space constraints I didn't have a single one yet. If I could make them recognizable enough they'd make perfect candidates for environmental clues (see: FEZ's pangram puzzle). However, I had almost no sprite space left (literally about an 8x4 pixel strip), so for most things that wouldn't be an option (especially if I wanted it animated, which I did).
Fortunately for me, butterflies (a FEZ staple) met all the requirements. It took a few tries to refine them to the point where they're recognizable and readable (in motion, anyways) but I eventually found a way:
The ideal place for the butterflies was the second room, a very compact little hub. Adding a giant floating pillar that reads "BUTTERFLIES" and surrounding it with them might not be the most plausible thing from a worldbuilding perspective, but FEZ already outdid that with the absurdity of the pangram anyways. It's also worth noting that, like the previous Clue Phrase, this one is found directly on the main path of the game, which ensures that all players will have been able to find it by the time they reach the Nuish puzzle room. "BUTTERFLIES" as a phrase was also a useful addition, as beyond providing the symbols for S and U it also:
- laid the groundwork for establishing that U and V are the same character in Nuish.
- fleshed out some additional optional alphabet letters (B, F, and L).
- had shared characters with the previous Clue Phrase.
- had a double-T in the word, which serves as anchor point by greatly narrowing the range of possible translations when initially deciphering it.
I was now in the odd place of having to find a clear, simple (no sprites necessary) environmental prop that could clue players into a phrase that incorporates M and N, and that ideally would also cover the letters V and O, as those are useful but were currently undefined. H was less of a concern, as it was only present in the word "THE" which is notoriously easy to deduce. Eventually, the phrase clicked: "MOON VIEW". I could use rectangles to draw a simple blocky moon in the sky of the twin towers room (placed so it's framed between them), darken that room's sky to look like night, and then rely on the information from the previous clues to carry the rest.
The only sticking point would be the V character, which would clash with the player's prior understanding of the U in "BUTTERFLIES" (or vice versa). However, like the other Phrase Clues this one was also on the main path, and by this point the player would have seen all of the six Nuish characters. By observing the patterns in their shape they could reasonably deduce that the alphabet should only have 24 characters (six symbols in four orientations each), and by extension determine that some letters share characters. Plus, if they'd gotten the previous two clues first they'd have "_IEW" as the second word, which really can't go many other ways besides VIEW. As such, "MOON VIEW" was the perfect candidate.
With all of these in place, the Nuish puzzle was now completely solvable. But it'd be a waste to have a whole decodeable language only for the purpose of solving a single puzzle, so I wanted to incorporate more pieces of Nuish text into the world. I also still hadn't included the characters for C, D, G, H, J, K/Q, X, Y, or Z.
The most obvious place to add something was the Constellation room, as that area had a large blocky structure and a puzzle that players could potentially be stuck on (and could thus use a vague hint for). The phrase I came up with was "THE SKIES OBSERVE US TOO". This managed to do quite a lot, even if examined before all of the main clues:
- It allowed players to deduce the K character.
- It could offer clues for the H character thanks to containing "THE".
- It could offer clues for the O character due to having the visually-distinct "TOO".
- It emphatically demonstrated that U and V use the same character.
- It could vaguely clue players (on the off chance they somehow just did not get it) into the fact that their specific actions were causing the constellation to change.
- It also just sounds like a very FEZ-branded phrase to me, based on the text I'd decoded from the original game.
The remaining characters were fleshed out in text from the more hidden late-game areas. If the player reached the Chamber of the Fez (found by collecting all eight Cube Bits and three Anti-Cubes, then using them to travel through the 4-Cube Door) they are presented with "THE CHAMBER OF THE FEZ WELCOMES YOU", which left only D, G, J, Q, and X undefined. After then collecting the Giant Fez and using the Warp Gate, the player is greeted by Nuish text reading "THX FOR PLAYING" and "MADE BY JUSIV", leaving Q the only letter technically unaccounted for (although it's mapped to the same character as K, just like in Zuish).
There was even a (mostly-unintentional) clue that I offered players who got the lame ending: if the player uses the warp gate without collecting the Giant Fez they get a (thoroughly unsatisfying) black screen with Nuish text in the corner reading "END." I've heard of players who got this and actually deduced what it meant and used it to help them progress on subsequent playthroughs, which honestly is pretty cool.
I did what I could to make this as unsatisfying as possible: it's dead silent,
and the only thing besides a blank void is a tiny snippet of text in a language
that a player reaching this point likely hasn't decoded.
One downside of using PICO-8 when it comes to making language-based puzzles is that people playing a game directly from the fantasy console application or from the forums have the ability to look at the full contents of the cart, including all text. This poses a problem, as people could just go look up the answers as text strings inside the cart. My solution to this was to store the text encoded with a simple cipher and decode it at runtime. Sure, someone could still look through the code and crack it, but it'd take significantly more effort than just reading the text lines directly. I even included space and / (which I treated as my newline character) in the set of characters shifted by the cipher to make it a little less obvious.
As it stands, I believe the Nuish puzzle is simultaneously the most impressive and most breakable puzzle in the game. I'm genuinely proud of the fact that I was able to construct it, and do so well enough that many players have worked it out on their own. FEZ is very much a game that drives you to whip out a pad of paper for notes, and I'm very pleased that I was able to create the same type of experience in FUZ. I honestly even prefer my approach to teaching the Nuish language to the way FEZ handled Zuish text, as I believe it turns the process into a much more interestingly-involved puzzle.
Still, once you know what to do (or if you just stumble across the solution) it takes all of three button presses to solve. Ah well. At least there's still the irony of having to decipher an entire language for something that simple.
Speaking of messing with the fourth wall, if you've played FEZ you're likely well acquainted with the game's fake crash early on. It smashes the fourth wall in a jarring and off-putting but respectably great way. Partway through developing FUZ, I was struck with the idea to make a callback to this and immediately got incredibly excited by the prospect.
PICO-8 itself actually has a very distinctive bootup screen. While I have no idea how to go about reverse-engineering the the initial rainbow effect it uses, the actual bootup screen is mostly just text and thus would be pretty trivial to recreate through code.
This concept also tied in well with how I wanted to handle the game's narrative, too. The premise I was planning was that Gomez and Dot travel through a warp gate to the area the game is set in, but it promptly breaks and leaves them stranded. Thus, they must explore this new area in search of a way to repair the warp gate and return home. FEZ itself already had toyed with the concept of the world appearing to "crash" and then "reboot" after a powerful enough event occurred, so I decided to make an abstract relic that causes a "reboot" and repairs the portal when interacted with.
I was able to get the reboot screen working remarkably well from just careful observation of the reboot sequence, and even made it come complete with a fake hang "glitch" beforehand. You can't hear it in the .gif of course but JWinslow23 (a fellow PICO-8 dev) helped me make a spot-on recreation of the PICO-8 startup jingle to fully sell the effect.
Fun Fact: The "glitched" texture that appears over everything is actually a sprite taken
directly from the room voxel data section of the spritesheet. I just found whichever one
looked the most glitch-like to me and told it to tile it over the screen.
I did have to pull a bit of trickery to get this fully operational, however. I needed to recreate the special PICO-8 logo and unique text shown on the bootup sequence, but as you can see in the editor pics below I didn't exactly have enough spritesheet space available for both the text and icon parts of the logo (sprite 0 is off-limits for other reasons). Instead, what I ended up doing is hiding the symbol in the room data in an area that the player can never collide with: inside the bottom slice of the Warp Gate room.
Incidentally, the relic itself does actually have a vague, obscure basis in FEZ: it's loosely inspired by the gold stand-like decorations in one specific later-game room. Come to think of it, it's also a bit reminiscent of a power button, which fits for its function but I'm honestly not sure I'd considered that angle when I drew it.
Oh, and if you're wondering what the RUN text in my fake reboot is about, that's the PICO-8 command to start running a cart. What I was trying to go for was to have it appear as if someone commanded the game to run again after the reboot. I realize in retrospect that making the word RUN slowly appear on screen might accidentally give an unintended horror vibe, but I'm not sure there's much that can be done about that without making the sequence excessively long by having it pretend to load the game's cart file first.
And sure, having a random relic cause a glitchy reboot that magically solves your problems is a bit of a deus ex machina moment, but it was too good of an opportunity to pass up as a reference to the original, as a fun way to play with PICO-8's quirks as a fantasy console, and honestly as a way to give the game an ending. I'm really not sure how else I could have cleanly made Gomez repair a warp gate. I suppose I could have just made him find another one to exit through, but I like the full circle ending and it feels more plausible to me that he'd actually get back home travelling through the one he arrived at instead of some random other one.
At the end of the day, the relic's reboot effect helped the game ship and it definitely amused fans of the original FEZ, so I call it a win.
One Final Secret
Towards the end of development, I realized that I had barely used the cart's map data. For a demake of a game packed with secrets that doesn't shy away from 4th-wall breaking puzzles (see: the still-unsolved soundtrack images puzzle), this was a simply unacceptable waste.
It occurred to me that I had so much space there, in fact, that I could actually write something in Nuish text. It would never get seen in-game, but if someone happened to pull up the cart in the PICO-8 application and examined the map data they'd stumble across it. It also just so happens that FEZ already had a special secret collectible - the Heart Cube. Although I've encountered them in-game I don't even know their whole significance yet since I've been stubbornly avoiding looking up hints. I just know that they seemed to appear spontaneously and didn't show up in my inventory. At any rate, this combination provided a perfect opportunity for a special secret.
The input pattern listening feature of the Etched Pillar objects didn't actually depend on their position in the room. And with the way my engine was set up, I could literally just spawn one without placing a color 15 pixel (the ones that trigger an actor to be drawn) at the corresponding coordinate and have it never visually appear. This way, I could have an invisible object listen for an obscure input pattern and spawn a special Heart Cube object when it detects it.
Due to the way I'd programmed object spawning in response to puzzle completion, each room could only have a single puzzle. But as it turns out, the Moon View room actually didn't have any special puzzle implemented, and had a prime central open spot where the Heart Cube could be placed.
Putting all of this together, I had a plan: I would write a clue in Nuish out of map tiles and set up a Heart Cube object to spawn in the Moon View room when the clue is followed. At this stage in development I didn't have the space to do anything really fancy as a reward for tracking down the Heart Cube, and I didn't want to lock players who didn't own PICO-8 out of anything too meaningful. As such, I decided to make the end result of finding the Heart Cube and all the other items be to just see the Best Ending screen, which is identical to the Good Ending screen but with an added heart ring effect.
I was able to free up enough code space to incorporate all this and give Dot custom dialogue for acquiring the Heart Cube without too much trouble. However, I had to resort to some trickery to actually draw the Heart Cube in-game. I was basically completely out of spritesheet space, so I had to find a creative approach. Heart Cubes are about the same size as an Anti-Cube, so I could get most of the way there by just re-using the same sprite but palette swapping it to be red. Unfortunately the shape wouldn't be quite right, so I needed something else.
The solution I came to was to borrow from the shenanigans I pulled with hiding the PICO-8 logo to hide another tiny sprite within the map data and over draw it over the Heart Cube to complete its look. By making parts of this sprite navy (color 1), I took advantage of the Moon View room's solid navy background to give the impression of selectively erasing the top part of the recolored Anti-Cube. It worked out that there was even a perfect candidate place to hide the necessary sprite in: the second slice of the Warp Gate room. It already used mostly just navy and purple (colors 1 and 2, the exact two I needed) and had a wide area where the inner contents didn't matter and couldn't be seen.
(Also yes, this means that there are actually two secret sprites
hidden in the voxel model of the first room of the game.)
Altogether, I'd say the effect works pretty perfectly in-game:
The Heart Cube unfortunately ended up being the final, deepest secret I put in FUZ. I literally couldn't fit in more if I wanted to. But there was still one thing left to do: make the game actually sound like FEZ (or at the very least, somewhere vaguely close to it).
I essentially ended up saving audio for last. (True to form, I guess I did that when writing this, too.) It's not that I don't think it's important, but it's generally one of my weaker areas and games tend to feel weirdly empty when they only have some of their audio in place. Plus, I was working solo so no one else was depending on me (or vice versa) to get it in at a certain time and there could be no conflicts of vision.
For the most part I don't think there was much of special note regarding the game's sound effects. I did my best to recreate distinctive FEZ sounds like the Cube Bit pickup tones that increase in pitch, the "Secret Found" jingle, and the portal warp sound. I believe the trickiest bit to get right was actually Dot's dialogue sound, as it's very much outside the usual range of PICO-8. I ended up making a set of three odd little chirping noises that somewhat approximated Dot's voice and playing them rapid-fire in a random order while he talks.
As far as music goes, that's another story. I knew going into this that I'd have no hope of making anything remotely close to the quality of Disasterpeace's phenomenal FEZ score. I've got basically 0 musical training, and really have no idea what I'm doing when I'm making music. It doesn't help that the more ambient, ethereal, and dynamically-shifting sounds that make much of the FEZ soundtrack so special are simply not suited to PICO-8's limited soundchip. As such, even attempting to make covers of FEZ songs wasn't really a practical option. Couple all that with the fact I was making this game on zero budget, and I simply decided to take matters into my own hands and just try to make something passable.
I ended up making all of the music in the 24-or-so hours before release. Perhaps not the best plan but I'm not convinced it'd have come out significantly better with more time, anyways. I just listened to a ton of FEZ music and did my best to try to channel a bit of its feeling. I also made one of the sound channels have reverb to try to add a little more to the ethereal effect.
In total I made three tracks for the game:
- Main Theme (plays on the title screen and in the Relic Room)
- Outdoors (plays in most outdoor areas)
- Mysterious Place (plays in the Floating Tablet Room and the Chamber of the Fez)
I'd just like to apologize to any FEZ fans who were disappointed by my mediocre music. You have to make sacrifices when demaking things, and in this case FUZ's music unfortunately got the worst of it.
The End Result
In total, the final game used up:
- 8191/8192 Tokens
- 38729/65535 Characters
- 99.96% Compressed Size
- 4 full spritesheets (except sprite 0)
- ~25% of the map
- ~40 sound effects
- 16 music patterns
I also made a slightly modified mobile-friendly version, which stacked up at:
- 8192/8192 Tokens
- 38629/65535 Characters
- 99.98% Compressed Size
- 4 full spritesheets
The final content, layout, and structure of FUZ is pretty much exactly how I wanted it. There are a total of 8 areas, with 8 Cube Bits, 3 Anti-Cubes, the unnamed relic, a special Giant Fez, and the secret Heart Cube to find. It rather faithfully recreates two puzzle types from the original and presents its own more unique ones using Nuish and FEZ-style thinking. It stays true to the core mechanics of the original, makes numerous nods and references to it, and yet still functions as a completely standalone experience. It also takes unique advantage of being a PICO-8 game to mess with the menu in a puzzle and to create effects like the fake reboot.
Mind you, I don't consider the game to be flawless. While I don't think they're critical to address, looking back I can spot some issues with the game. For instance:
- There's so little overlap between the puzzle portion and the Cube Bit collecting aspect that the one point where they do interlink (the second cube bit in the Constellation room) is jarring to many players, and repeatedly reported as a place where they get stuck. If there was somehow a way to lock more Cube Bits behind puzzles to normalize that I think it would make that section would go more smoothly.
- It's unfortunate that the biggest puzzle in the game is so easily bypassed, but I don't really know how to avoid that given PICO-8's limitations.
- Some of Dot's dialogue, while (in my opinion) important, is a bit awkwardly long and suffers from the Pokémon Center effect of accidentally getting stuck re-listening to it after trying to skip through it.
- The Outdoors music plays in too many places, and while it is the longest song in the game the loop can still get grating for some people.
Overall, I'm still very happy with the end result, especially considering it was only about a month of total work.
That whole last week or so of development was an blur, but I was completely in the zone. Every waking hour was poured into cranking out content for FUZ, crunching down on tokens, and keeping the compressed size in check while trying to preserve human readability as best as I could.
I ended up having to learn a number of tricks I'd never tried before to get it to all fit. Things like condensing many variable assignments down to one line with multiple assignment (ex. a,b,c = 1,2,3), replacing single-argument function call arguments with a string (ex. btn"0"), and writing my own function to split data stored in strings so I could crunch down my token count.
The rest of the summer, unlike in 2017, unfortunately wasn't nearly so productive. In terms of game dev I wound up mostly stuck in the idea stage, with nothing sticking strongly enough to get me fully back into development. I don't doubt that I'd overexerted myself a bit creatively making FUZ, but I don't really regret it. I was thoroughly enjoying the process, and I'm still quite happy with what I achieved. It's a great feeling to get to make the most of the creative spark when you have it.
Especially given its origins as little more than a thought experiment, FUZ has performed far better than I could have hoped. It's currently sitting at a firm 4.7/5 stars on itch.io. The tweet about its release got a flood of positive responses, passing 1K likes in the first 9 days. There's been multiple articles written about the game, including one I was even interviewed for (in Wireframe #17). A few people recorded gameplay videos, even in different languages. It's frankly been amazing to see.
FUZ, my PICO-8 demake of FEZ, is finally released!— Henry Stadolnik (@Jusiv_) May 12, 2019
You can find it here:https://t.co/rDKdKf5efLhttps://t.co/rfPHkyHqUb#FUZ #FEZ #Pico8 #Demake #GameDev #IndieDev #PixelArt @lexaloffle pic.twitter.com/DQWSsWc7gG
Even to this day, FUZ is still my most popular and actively-engaged with game. At one point (May 15th) it was even in the top three most popular free browser games on itch.io!
Considering I never actually playtested the game's puzzles with other people prior to release (not a good look, I know), it sounds like I got the puzzle difficulty surprisingly nailed from my intuition alone. Even with some known sticking points many people reported that they got to experience the full game. I imagine part of this was from borrowing some puzzles and the way they're presented closely from the original, but it's definitely not just that. I got plenty of comments from people showing they'd successfully deduced how to decode the language and discovered the endgame secrets. Someone even managed to 100% clear the game (Heart Cube and all) in just the first 6-7 hours of the game's release, which was a remarkable feat (and 100% on-brand for the FEZ community, given how quickly things like the soundtrack puzzle were discovered).
(And yes, for future major games I will definitely plan to run some proper playtesting prior to the full release. I got stupid-lucky here.)
From what people have said, FUZ achieved everything it set out to do and then some. The overwhelming consensus from comments is that FUZ successfully scratched the FEZ itch that many fans of the original had been missing since the cancellation of FEZ II. The game has been substantially praised for how closely it captures the look and feel of FEZ, and people clearly appreciated the callbacks to the original (especially the fake reboot screen). Someone even went out of their way to write a haiku in Nuish for me after they beat it. I've even had multiple people compare me to Phil Fish (minus the problematic parts) or say things to the effect of wanting Polytron to put me in charge of FEZ II, which is incredibly flattering.
Making this game, watching it come together, and seeing the overwhelmingly positive response it has gotten has been an amazing experience. But as much as I'm proud of what I achieved with FUZ and thrilled with what it's done for me, I don't plan to be making more fangames in the near future. It's great for reaching an audience, and especially with a game like FUZ requires some interesting problem-solving and reverse engineering, but at the end of the day it's never something you can really completely claim as your own. You're always working to achieve or adapt someone else's vision. While there is a time and place for that, I'd like to focus on other areas for the time being.
To those of you who've stuck with me through this whole article, thank you! Hopefully you found it informative, or at least interesting. While I know I've been quiet regarding my own game development lately, hopefully this makes up for that in some small way.
To be perfectly honest I haven't had time for personal work outside of classes these past few months. I've also been taking a break from PICO-8 work to focus on learning other engines like Unity and Unreal. I can't promise exactly what's coming next or when it will arrive, but I do have a summer ahead of me and at the very least I'm going to be making a game with folks at the MassDIGI SIP. We'll see what the future holds!
And with that, I take my leave (for now).
Thanks again for everything!
- Henry "Jusiv" Stadolnik