< < back
(2/18/2026)
I recently finished Remote Perception, a monthlong gamedev project. My goals with the project were threefold: One, to get back into the routine of gamedev after an eighteen-month hiatus. Two, to learn Godot. Three, as proof-of-concept for a larger game I've had in mind for a while now. The game is built to effectively feel like how one "level" would feel in the hypothetical larger game, and features most of the major mechanics I'd intend to use there.
Though there are some flaws with the final product and it's definitely not my best work, I'd say I succeeded in all three goals. I was pleasantly surprised by the development process: I did more in a shorter period than expected, and player reactions were overall positive. More details below.
(1) Mapping and Exploration
I was initially worried about mapping; it’s something I struggled the most getting back into in my failed earlier attempts to end the dev hiatus. Mapping is intimidating because it takes a while, is hard to predict well, and tends to be “sticky”, hard to change, once it’s done.
To my surprise, though, the map turned out just as I wanted on the first try. I drew a sketch of it in an hour, which was almost entirely improvised, and iterated minorly when it came to putting it in engine. Almost everything in my initial sketch made it into the final product. And somehow, the map felt coherent and engaging as a living, interconnected space, even though I wasn't optimizing for that. I love the sense that a location has emerged in the intersection of these individual challenge rooms, almost as though by itself. It has a recognizable structure with its own inner logic that takes time to disentangle, and I think this is the average player's favorite part of the game. In the future I’d like to lean much more into this, especially spread across more than one biome.
(2) Godot
I love Godot and I'm never, ever going back.
There are a billion problems with Unity. They make the Library an entire gigabyte for no good reason, initial project setup takes like ten minutes, it uses too much memory to be comfortable on small machines, costs money, is a pain in the ass to switch versions, and the company does scummy bullshit you can’t do anything about. There are so many little inconveniences, and becoming a Unity dev inevitably means becoming a walking encyclopedia of them.
Godot has none of this. The app itself is a smooth <100mb single executable that can be downloaded from anywhere and takes no setup. I can do everything important faster, smoother, and with less random bullshit. The environment is no longer cluttered with things I don’t need, yet somehow, all of my actual needs are covered perfectly. At one point I wanted to do a nitpicky transparency thing on the background, and searching turned out not one but two tools intended for exactly my use case. It is almost as though it is an engine built for making a video game, or something.
I think the biggest thing keeping people away from Godot is the switching costs, but these were minimal. The biggest difference from Unity is that there is no distinction made between a “scene” and a “prefab”; each object is itself a scene, and you nest scenes together to build a game. This is confusing at first, but it only takes a few days to get used to. The scripting is quick to pick up (though I’m lucky to already know Python) and the hooking up of different parts is so rapid to iterate on that small mistakes don’t matter much. I am very glad to have made the switch.
(3) Audio Integration
I was nervous about making a pseudo-rhythm game after my previous experience with Rhythm Hell. That game was horrible to build, and the final product is held together with duct tape and string. I remembered Zero Punctuation saying in his Dev Diary series that rhythm platformers were even harder than regular rhythm games, because you have to worry about a wider range of motion. On top of all this, I was trying to sync shaders to the music, even though I don’t know anything about shaders, and this would involve dealing with lots of scary low-level graphics things. It seemed like a recipe for long nights of painful debug-struggle.
To my shock and delight, it instead was a recipe for short evenings of easy iteration! The shaders only took a few hours and looked better than I’d hoped, and the audio syncing was just as smooth. I credit this success to a few factors: One, Godot being amazing. Two, my having more experience with rhythm after having already built one game around it. Three, the limited scope of the game (read: only one song). Still, this gives me renewed confidence that the highly rhythmic, distorted style of design I’m most interested in right now is not too difficult for independent developers
(1) Playtesting and Difficulty
This game is way too fucking hard.
The initial draft of anything I make is always too hard, because some things which are easy for me are not as intuitive for non-devs. However, most of the time, I am pretty good at smoothing this out over playtests. This time it seemed the opposite: the more testers I brought in, and the more I tried to ameliorate their stuck points, the more time it took the next tester to win. It could be selection bias: my lowest-hanging fruit of testers are very good at video games, and as I spread out, I was testing with gradually less and less expert players. But I suspect my well-meaning attempt to make the game easier by opening up the map actually made it much harder, because it is harder not to get lost.
I'm ambivalent about this - high difficulty was my intent, after all - but ultimately I've got to admit this was a major failure of intent. I started with a map that was slightly too hard and ended with a map that is much too hard, despite my attempts to mollify the difficulty. I think the only way to make it any easier at this point would be to remake the map from scratch, and I don't want to do that, because I like the map. Future maps will hopefully be made with much broader affordances in mind, and especially a less unforgiving timer.
(2) Scheduling and Collaboration
My biggest regret in development is that I did not reach out to anyone for help until roughly halfway through the development of the game, and the collaborative aspect didn't really kick into gear for another few days after that. As a result, the art pipeline -- the thing in dev I need the most help with -- was strongly backloaded, and several playtests happened while the game was still in a pure "programmer art" state. This meant there was very little time at the end for visual refinement and polish.
I tend to underestimate how deeply visual a medium gamedev is. Players strongly rely on tiling cues, effects, bits of map geometry, etc, to locate themselves in space. I was consistently surprised by how much visual changes would affect the actions the player would take, and where they would feel the map was 'directing' them. I was worried I wouldn't be able to get any artists interested if I didn't have a functional draft to share, which might have been true coming out of an 18 month hiatus, but probably won't be for the next game. In the future, I would like to try figuring out my team early on, so that they can be more involved in the initial art pass and style of the game.
None of this is to minimize the contribution of my team, who did a great job, on a painfully constricted schedule, for a hobby project they had no obligations to. They put in a lot more work much faster than I could've reasonably asked for, and the final product looks really polished in spite of the crunch.
(3) Game Architecture
The architecting of the game is a complete mess. The worst of it is a room manager: this was initially hacked together under the idea that there would only be one room active at a time, with a static camera, and when a new room loaded it would teleport the player to simulate motion. It quickly became apparent that this would not cut it with the timing system; I would need to re-simulate motion across the entire song every single load, which was not feasible.
I half-rebuilt the system to load the entire map at once. This works great from a gameplay perspective, but as a consequence, the backend is all garbled. Some chunks of the code from the earlier system are entirely redundant. Put together with my generally careless, rapid-fire approach to design, this game is absolutely not fit to scale directly as it stands. I think this rewrite could be done fairly quickly, and I probably will do so for the start of the next game. I think this aspect was a reasonable sacrifice to keep things flowing smoothly and get tangible work done - it just won’t be sustainable in the future.
(1) Player Movement
I’m not fully happy with this one, though there's nothing particularly wrong with it. My current system has a ~5-frame acceleration, ~3-frame decel, brief coyote time, slightly variable jump height on both jumps, and some small extra tweaks to work with the room system. This is a fairly basic 2D platformer movement set, roughly the same used in Connect the Apocalypse. It's a smooth, sane movement system, and that's precisely the problem, because I am not making a smooth, sane game.
I really want a character who can do some crazy out-of-control bullshit, a Celeste wavedash or Meat Boy’s wall antics or something similarly intense. Something that demands enough reaction time to not be trivially controlled, but powerful enough to give you a huge range of motion once it’s mastered. I also don’t just want to steal a skill from another game, nor pick something so dominant that it completely defines the movement set. I could do a Metroidvania thing and have different movement skills unlocked over time, but this would be a big ongoing commitment rather than a one-and-done. I could do something really wild like a spinning launch or a rocket jump, but I’m worried it would end up being gimmicky and annoying to design around. I could even center the mechanic in the environment, like The End is Nigh’s wall climb, but this feels limiting. Overall there may be no good solution, but it keeps bugging me.
(2) Vibe Coding
Some aspects of this game were partially vibe coded, which I'm ambivalent about. On the one hand, something about it seems deeply against the spirit of auteur, solo, experimental development, which is precisely the kind I’m most interested in. I love the precision and rigor demanded by a computer program: the fact that you need to specify exactly what you really mean by, say, a “double jump”, or else it won’t do what you want. Working through this process doubles as a way of figuring out what your vision actually looks like in practice, in a way that is impossible to replicate when Claude is writing the scripts for you. (This is also how I feel about enlisting other human programmers.)
On the other hand, much of programming, especially in a new language, is wrangling syntactic details that don’t actually matter for the final project. Normally I use Stack Overflow or YouTube for things like this, and asking Claude instead is hardly any different. It's just faster, more consistent, and with the option to ask follow-up questions. If vibe coding goes well, I can imagine it keeping all the rigor of ‘true’ decision making, while reducing the syntax puzzles to the basics of natural language. We would no longer need to worry about counting close-parens or managing the order of physics processes, just as we currently have no need to worry about memory management in Python. Maybe this is the future that would come from embracing vibe-coding wholeheartedly. I don't know, but my current plan is to vibe code little things, feel bad about it after, and try to build as much as possible myself.
(3) Where To Now?
Due to scope, something important was entirely skipped in this project: narrative. There are no NPCs, there is no plot or thematic motion, there is no sense of rising action or transformation. My last game, Evening, was all narrative, so it was nice to move away from this and indulge in a purely ludic experience. There’s a lot one doesn’t need to worry about when there’s no story, you don’t have to care whether the game is emotionally honest, or whether the tone is resonant with the gameplay, or whether there’s some spooky lurking ideology underneath the text. It is much easier to just let people have fun and not think too much.
But still, without a story, the game feels fundamentally incomplete. There is so much I want to say and so many interesting ways to say these things, and this game is not doing any of that. My goal for my next game is to try and integrate the things I’ve already worked on with a real story, with characters and a plot and shit. REAL thematic expression, with REAL risk of failure!! The details, of course, will be left as an exercise for the reader's imagination.