One* Night at Miku's (2026)

GitHub | Download

Platforms: Windows | Linux
Project Length: 6 months
Engine and Tools: C# | Monogame

About

One* Night at Miku's is a rogue-like action spin on classic Five Nights at Freddy's sit-and-survive gameplay. Study, learn, and master the machinations of the various nightly threats that stand between you and 6 AM.

Features

  • Fast-paced and addictive management gameplay where the most important resource is information, and the most costly action is hesitation.
  • 10+ gameplay modifiers (rogue-like style upgrades).
  • Compelling enemy AI.
  • Interesting(?) story.
  • 3 difficulty modes.
  • Lots and lots of easter eggs.
  • All the extras you'd expect of a FNaF style game (Custom night, etc.)

Development History

The idea for One* Night at Miku's came similarly to that of Sha's Tetris and Undertale Battle Engine. I was playing through the Five Nights at Frickbear's games (a series of Five Nights at Freddy's fan games) and thought, "Hey, I could probably make something like this!"

While Frickbear's 3 is a well-renowned, polished, and expansive game, the first two in the series are scrappy Scratch games which reuse and reference many ideas. Having spent the previous two years of my life developing large-scale projects that now lie in varying states of immaterial, I was inspired by the games' unabashed silliness and wanted to carry such an approach into my own work. This methodology is what guided my work on One* Night at Miku's.

Starting with its…

Design

In the spirit of low-stakes development, I made various scope cutting decisions early on:

  1. The majority of assets would be reused, specifically from various games in the FNaF series.
  2. The base gameplay loop will take heavy inspiration from that of FNaF 1.
  3. The game will aim to have high replayability in order to maximize playtime per development time.
  4. And most importantly,

  5. The codebase will be messy, hacky, and spaghetti-y. And that WILL be ok.

With ground rules in place, work began on planning out the game's systems and mechanics. Continuing to take inspiration from Frickbear's, I wanted to create a frantic and fast-paced gameplay loop where players feel like they're constantly "patting their head and rubbing their belly." Normally this effect is achieved by introducing new threats after each night, but I had decided (for more scope reasons) that the actual nighttime gameplay would be fixed. Instead, the use of modifiers would add new folds to the pre-existing nightly structure, maintaining a difficulty curve and placing more agency in the hands of players (as well as upping replayability.)

Due to this structure, development was split into a series of phases. First I would build the core nightly gameplay. Then I would move to the game's menus and settings. After that, I would expand on top of the base that had been created with modifiers. Finally I would wrap it all together with a system of meta-progression. By layering work on the game in this way, my focus could move mostly linearly through a tangled web of interlocking systems.

To start, I prototyped a recreation of the FNaF 1 office, along with its camera movement and doors.

When testing the cameras, I needed an image to act as a placeholder for what would eventually become some variation of animatronics. And so, as is tradition at this point, I used an image of a Miku plush.

I sent this prototype to a few friends to get their reactions and found it hilarious when they would tense up at the sight of a FNaF game, only to then open the cameras and see Miku's silly little face staring back at them. This juxtaposition, when struck across my commitment to unseriousness, sparked what would become the core of the project in my mind.

However, while I was excited to stoke the flames of comedic juxtaposition, I was still deeply interested in making an engaging game. I wanted players to get in the door thinking, "what a joke, this is hilarious!" and leave, "I can't believe I got hooked on such a goofy game. That was surprisingly compelling." As such, I took the time to interrogate the design of FNaF-style games. Having grown up with the series and its fangames, I had my own opinions about what made a FNaF game "fun." And to me, that was its moment to moment decision making.

With each game comes a new set of rules to learn and threats to keep track of. The trial and error of figuring out how everything works playfully invites players to view the game's world with wonder and excitement. Curiosity is rewarded and complacency is stamped out as mastery is tested. Whereas most games primarily challenge players executionally, FNaF-style experiences encourage players to attempt to understand the things around them. By immersing players in this way they form personal relationships with the game as a whole, which manifests in their unique approach and strategies. The magic, then, is when this connection between player and game is reciprocated. By night 2 the game expects players to know how to do X, but only by also doing Y. Performing Y grows to conflict with X as a new wrinkle is introduced. Players then respond by readjusting their approach, gaining deeper knowledge of the system as a whole in the process.

Those were the feelings I wanted to capture with my design, and I wanted to explore them through the lens of a much more action-oriented take on the genre. Much closer to FNaF 2 or UCN than FNaF 1 or 6.

Early exploration document.
Design document for the vent system.

And with that, we had…

One Night at Miku's

Implementing the features outlined in the design document was relatively straightforward. I first started with the three main Mikus.

Then I added the vents and Green.

And finally the Mikulings.

New to my workflow on this project, I regularly sent updated builds to friends as they were completed. This not only gave me a constant stream of feedback, but also helped to build forward momentum on the project as a whole. This also aided in avoiding technical debt as the need for systems to be semi-presentable incentivized their implementations to be more complete than that of a controlled prototype.

All the versions of ONAM through development.

Many changes were made early on in response to the feedback gathered. For example, many playtesters found the initial learning curve too punishing to climb. One* Night at Miku's was developed from the start with fans of not only FNaF, but its fangames as well and so a basic level of familiarity was expected. However, the unchanging nightly structure did leave onboarding extremely harsh for those completely unfamiliar with FNaF conventions in a way that other games of this type do not face. So in order to make the game more accessible, I implemented a difficulty select which ended up making it all the way to the final release.

Feedback from playtests also helped in the refining of the Mikus' ai. Some examples include:

By this point I had spent some time working on the games menus and UI, leaving the overall package feeling relatively complete. It was around this time that I created a demo which I shared alongside a feedback form to further gather players' thoughts on the game. Seeing people enjoy the experience made me confident that I was making something worthwhile.

But it was still missing…

The Asterisk

With the base game in a somewhat complete state, I was able to shift my attention to developing the modifiers. For their design, I took inspiration from real life game modding. I wanted the changes they brought to feel coherent to the game as a whole, but just janky enough as to still be a little out of place. To this end, prioritizing the development of the base gameplay was a large boon. Not only did having a pre-existing framework to slot ideas in and out of help when designing new mods, but it also allowed their existence, down to the programming, to mimic that of a real game mod.

Modifier ideas I kept in my notes app throughout development (listed backwards.)

While each mod is made up of a pro and con, their attributes were developed individually. This allowed me to explore an idea to its fullest, and then see where it fit in later. Developing this way also made it easy to mix and match attributes in attempts to ideate and find interesting combinations.

Attributes being sorted into pros and cons and then organized into modifiers as pairs.

Naturally a few modifiers were left on the cutting room floor, but I am quite proud of the selection in the game today.

Beta custom night menu with an older selection of modifiers.
Unused modifier ideas from the above mentioned notes app list.

With mods to make each night feel new, it was time to implement meta-progression. This was around the time that the run system was implemented along with its accompanying menus.

By this point I was feeling pretty good about the project and was hopeful that it would release only a little while later. But you know what they say…

The Last Twenty Percent

…is always 80% of the work. I would repeat this phrase over, and over, and over, and over again for the ensuing 4 months it took to release One* Night at Miku's. Despite having a mostly complete game by this point, it was far from polished enough to be publicly facing. Modifiers needed to be balanced (both individually and as a whole), placeholder assets needed to be replaced, bugs needed to be fixed, menus needed to be polished, and all those cute little ideas I had for fun inclusions throughout development needed to be evaluated and either implemented or tossed.

This was a grueling process.

Not helped by the lack of motivation that comes with doing the game dev equivalent of paper work. Nor helped by the start of a very transitionary time in my life. Either way I made it through and I'm here to tell the tale. So here's the few interesting bits:

Momentum slowed to the point that work on the game only happened once a month.

Throughout development, work on a tutorial loomed over me like a white whale. So much of what I enjoy about FNaF games is their sense of self-guided discovery and I struggled to preserve that while still ensuring first time players knew enough going in to have a fighting chance. Initially I outlined a guided tour of the game which would be delivered by a character on the phone (as is tradition.) However, it felt too restrictive and honestly reminded me of forceful mobile game onboarding. Thinking maybe I wouldn't reinvent the wheel for once, I then played around with having a classic nightly phone call that would explain the basics to players as they were playing. While this did technically work, players' attention was split between so many new things to learn that they struggled to retain much of use. Beyond this, the unchanging nature of nights in One* Night at Miku's meant that the Mikus became active far too soon for any explanation to not feel rushed.

Eventually, I settled on a mix of the two concepts. By having a self contained introduction to the game's systems, players were able to learn the ropes without distraction. But by limiting information to the operation of the game's systems, players still got to discover the Mikus on their own. Adding a few nightly calls throughout the run also provided more forward movement to the game's pacing, as well as maintaining the modifiers' surprise introduction. This approach felt the most like teaching players how to fish, without doing it for them, or telling them just what kind of fish they might find…

For the phone character itself, I went through various drafts of its script. Finding the right balance of vague but informative was surprisingly difficult, and it wasn't made any easier by my constantly changing character concepts. First it was an uninterested part-time worker, then a bumbling intern, then a well-meaning manager, then an asshole coworker, then the friend whose shift you're covering, then,,, like,, Joel Last of Us???? I was all over the place and couldn't land on one thing. Partly because I couldn't get the voice right, but also because I (wanting to do the voice) couldn't get the voice right. The final version is the result of me reaching my breaking point and falling back on the safe idea I had from the start. The tutorial voice being a little quirky with it came naturally because I'm just like that I guess.

Assorted dialogue from early phone call scripts.

With a tutorial finally in place, and a semblance of a narrative forming in the nightly calls, I realized I would probably need a more definitive ending than just a results screen. I'm not going to explain the joke, I'm just gonna leave this here…

One of the last hurdles I had to get through in this phase of development were the Shadows. Both Office and Camera Shadow were originally modifier attributes, but they felt too substantial of a change to sit alongside the other mods. For a while they sat unused but as the game's undertones grew darker, I thought it might be fun if they were semi-random encounters. Like entities outside of the game making their way in. At first there was no way to tell if a modifier was cursed, but in the spirit of interesting decision making based on ever-growing game knowledge, I made sure to add a way to tell. The hang up, then, was balancing their inclusion into the already stuffed gameplay loop.

The biggest struggle was deciding how present I wanted the shadows to be. I wanted them to be more like a haunting than a constant threat, and I liked how they could throw an unexpected wrench into players' flow. The best example of this interplay was the late redesign of Camera Shadow. From first inclusion, it would appear on either cam 3 or 4 and then need to be stared at like in the final game. However, when it disappeared it would then move to another camera farther from the office, totaling three times the player needed to stare at it for it to finally go away. I enjoyed the sense of place that this mechanic gave to the location, but felt it reached outside of a supporting role.

Beta Camera Shadow interaction.

Then, one day, I sat down to work on the game and, after months of slowly chipping away at it, found that I had nothing new to do. The game felt polished, bug-free, and, like, fun???

It was finally time for…

Release

I have no idea how to promote myself or my work. Despite this, I attempted to give One* Night at Miku's a proper public release.

For the game's storepage, I followed conventional wisdom you'd get from any GDC talk. Include kinetic and varied screenshots, have an eye-catching layout, make sure your description is informative but punchy, etc… New for me though, was the creation of a trailer. I had cut together simple showcases for my projects before, but never in attempts to market them. So I decided to keep it simple.

When making the trailer, I focused less on showcasing direct gameplay (it's not flashy and the interesting bit is what's going on inside players' heads anyway) and instead attempted to communicate the overall feel of the experience. As such, I turned to frantic cuts, bold text (mimicking that found in the game itself), and an air of mystique. Banking on the silly premise to get people in the door, I hoped to capture viewers' curiosity by overwhelming them with so many tastes of what the game has in store that they'd just have to give it a try.

In the week leading up to release, I would also post a short clip or screenshot to Twitter. I hoped that by teasing off some of the game's unique twists, it would build anticipation. Social media doesn't really make sense to me, so I produced said materials all together and scheduled their uploads ahead of time. Luckily a few people engaged with the posts (specifically the early ones) which vindicated my approach. Of course, One* Night at Miku's was not some runaway success, but I'm just happy anyone played it at all. And while this was a good exercise in promotion, I hope that my next project will be able to carry itself more so on premise alone.

Postmortem

As much as development of One* Night at Miku's was drawn out and sloppy, I am very proud of the final product. It is by far the most polished and complete package I had released at the time and I'd like to think it's even pretty fun. Somehow there's still things I didn't get to talk about above, so I'd like to take the time to cover them now:

About half way through work on the modifiers, I experienced what can only be described as psychosis. I was convinced that players would always choose easier modifiers in order to make it to the end. So I experimented with awarding tokens when performing various actions which could be spent on temporary upgrades. The idea was that harder modifiers would give more tokens so players would challenge themselves more in order to get tokens. But, of course, this was a stupid idea as it made more daring players have an easier time while leaving struggling players behind. Plus, this whole thing was just the result of poor modifier balancing which got refined naturally over time anyways so…

Shop prototype demonstration (no upgrades are functional.)

For as much as One* Night at Miku's has an artstyle, it was inspired by early FNaF fangames from around the time of FNaF 1 through 3. Specifically, those that edited pre-existing assets and made something new with them. I've always enjoyed creators who remix works into something coherent yet distinct and wanted to capture that in this project. The slapped together look was furthered by my commitment to doing things simply if they made me laugh. For example, when designing the different Mikus, I laughed so hard and for so long when I just used the paint bucket tool to change the color of the png that I couldn't not lean into it.

With the easter eggs and secrets in the game, I wanted to include them not only because they're fun, but also as to help each playthrough feel more varied. I really enjoy surprising players and I was literally kicking my feet while laying in bed watching playtesters' reactions to some of the random events I included. Even though the game at its core is very simple, small additions like those go a long way in encouraging and rewarding attentive play. Plus it hopefully gives people something to discuss about the game.