Game Developer at quicktequila On Creating the Arcade-Style Tamashika Game

TAMASHIKA blends arcade-style FPS mechanics with a surreal, psychedelic, retro presentation. What were the core design pillars that guided the project from the beginning?

The visions started to drip in from my subconscious when I first played Post Void. Before Tamashika, I worked on an array of first-person shooter games that blended fast-paced action and platforming that rewarded precision aiming and speedrunning. An amalgam of those influences informed the feel and mechanics that finally made their way into this game.

I took a long, hard look at the kinds of games I've made and the ones I like to play to identify the core pillars that went on to inform all the design decisions for Tamashika. Games are extremely diverse and deliver a spectrum of different kinds of experiences. With this game, I wanted to double down on the kind of style and gameplay that grabs my attention. Not just in the mechanics of the actual game, but the whole experience, from the moment you boot up the program through into the depths of the fast-paced action.

I knew how I wanted all of it to feel and pursued that feeling to the best of my ability. Rhythm and flow are at the core of the gameplay experience, but moments into the tutorial, you'll know she's not playing by the rules of the traditional FPS at all. She breaks a lot of conventions and isn't shy about it. Behind that, the general aesthetic, the abstract visuals, and the intentional exclusion of exposition, narrative, and cutscenes point to the focus on simplicity. Games these days pack too much content, features, unlocks, currencies, etc., which leaves me intimidated.

Tamashika doesn't expect you to give her so much time. It's procedurally generated, but you don't get a new level every run. She won't reward you for playing long hours; in fact, she'll discourage it. I play games to tune out the world simulation by bringing my eyes, ears, and hands into rhythm with the moving pixels and sounds as a respite from the chaos. That's why young me played games too, so I made Tamashika to deliver on exactly that. Your daily dance with the machine.

The game's shifting, procedurally generated corridors are central to the experience. How is your procedural generation system structured, and how do you ensure levels remain both readable and engaging?

The level generator went through multiple iterations before I arrived at the version we have today. I don't start working on my games with a grand vision, but instead I try to lead with what feeling I want to capture, from there I keep my fingers crossed and hope the pieces fall into place. It's a kitchen sink strategy turned up to eleven, but it's served me well so far. This reflected in the number of iterations I made with the level generator.

The first version combined a simple DSL with rules to arrange blocks in sequence, but it was too simple. The next version did away with the DSL and instead followed strict rules to mix corridors and rooms at regular intervals. This system worked out quite well for a long time. She would just hallucinate fresh encounters following a simple script as the player moved further into the level. I struggled to figure out a way to introduce more variety, but I was throttled by the pipeline I had set up, which involved exporting prefabricated blocks from Blender.

The current version blends procedural elements with fixed prefabricated pieces that are hand-designed in a custom tool that's much faster than working in 3D software. This allows me to quickly design and export individual segments and encounters with ease. Levels are broken, separate blueprints, each with codes that point to pools of those same segments, which are shuffled daily. These blueprints follow a rhythmic order to ensure hard encounters remain evenly spread out between faster segments.

With the right amount of twists, straights, and turns connecting larger open rooms, the overall structure makes sure to deliver the right mix of different styles of tight corridor action sequences. We have a sizable number of segments that are shuffled daily, which gives the daily roll a healthy amount of variety compared to what I was able to achieve with the older iteration of the generator.

Fast-paced movement and mechanics like blinking, parrying, and shooting require tight responsiveness. How did you approach designing and tuning these systems to feel precise and satisfying?

A lot of the mechanics in the game inform the structure and level design to make sure they support each other. The levels are designed to ensure there's a best line for players to follow without breaking flow. The parrying and melee systems run counter to this, which is where Tamashika stands out. I feel a lot of shooters lack defensive actions, which makes the overall feel and motion too unidirectional and monotonous.

While Tamashika is all about flow and continuous movement too, the rhythm is set to alternate between the regular strafing, turning, and shooting motion and quick-time events where the whole thing comes to a stop for you to press the right button at the right time. The rhythm Tamashika wants you to find lies in being able to balance between the two.

From a technical standpoint, what engine are you using, and what made it the right fit for a game built around speed and procedural content?

I'm using a game development library called Monogame. I didn't want to use an engine because I wanted to handcraft the systems myself. There's a lot of debate about using engines vs. hard-coding your game, and it appears from my time on internet forums that it's become a sort of status symbol to avoid using engines altogether. I'm not taking any sides in that debate, and I don't judge. Use whatever you want, just make cool games.

I personally went back to using a library because I wanted to re-live the good old days when I would come back home from high school and hack on small demos in C++ and DirectX. It's more of an aesthetic choice for me. In terms of speed and performance, it's a wide spectrum. I'm still in a managed environment, so programming gurus would not approve of my setup. While it's possible to use an engine more efficiently for a game like this, I figured most of that work would involve trimming away all the features that are provided, so I did away with it entirely.

I like the learner dev environment, it feels right in the hand, which makes working on it more interesting. It's about how it feels to boot up your project, watching pages of code, asset files, and shaders doing their tango to produce the magic on-screen when you hit F5. Vibes, that's my secret captain, I was always vibe-coding.

Can you walk us through your typical level creation workflow—how much is handcrafted versus system-driven, and how do those elements come together in-engine?

This system has come a long way since its inception, so I'll describe how it works in its latest iteration. I vibe-coded a node server that manages a simple frontend where I can draw a set of rectangles to define a level segment, together with entities like enemies, props, and traps, etc. The backend manages a database of these segments, each labelled and categorized into different pools that are exported into the game directly every time I hit save.

It's a simple, straightforward setup that's allowed me to reduce my iteration time exponentially. These handcrafted segments also ship with blueprints that allow me to define compound segments where each element points to a pool of level segments. The game arranges these blueprints in order to define a "timeline" that shuffles through each of them with a daily seed to prepare the run for the day.

I would say it's definitely more handcrafted than procedural, so I wouldn't say it sports the kind of emergent properties one would expect from a rule-based generator. I tried that before, but didn't love it, so this solution works a lot better for the experience I wanted to deliver. Also, this makes the system very extensible, and I look forward to throwing in more surprises after the game comes out.

The game's visual style is highly stylized and abstract. How did you define the art direction, and what references or inspirations shaped its look?

Seeing the slew of military FPS games and the annual churn of realistic AAA games that keep hitting the market on queue, my visual design philosophy hasn't changed all that much since Lovely Planet. I just like colors, I like looking at colors, and a lot of them. I don't want to point fingers or single out any one game, and I don't know if I'm getting old, but some shooters I played recently, too, just remind me why I make the games I do.

I want the world to pop out. If I wanted realism, I'd just go outside. I don't want realism, I want hyper-realism if anything. Show me something I don't see elsewhere, surprise me! That's basically my motivation behind the art style and aesthetic of Tamashika, and a lot of it just came from trying out a lot of different combinations of shaders and assets. Retro games were limited by the technology of their times, which forced developers to think outside the box, and their creativity showed in the games from that era.

The pixelated frames in Tamashika are an ode to the golden era, which I miss a lot. On the other hand, she's also confident of her psychedelic undertones. That's where the rainbow aesthetic and warping visual effects slip in. Videogames as "Digital Drugs", every frame engineered with precision, programmed to enter your visual cortex and hit the correct notes to modulate your cognitive apparatus into flow with the ghost in the machine. While I'm limited by the technology of my times, the aesthetic at least tries to point to the future of video games and neuroadaptive brain-computer interfaces. Let a guy dream.

What does your art pipeline look like for creating environments, enemies, and VFX within such a dynamic, procedurally driven system?

Very early on in the project, I found my artist, Ilyse, who was somehow able to produce the most stunning animations with very little direction from my side. It's like she knew what Tamashika needed, and I had no choice but to just run with it. I was juggling a retro 3D art style before with models for the enemies and player, but after seeing the hand-drawn animations dance with the gameplay, I decided to go with the blend of 3D environments and 2D enemies in the vein of Doom and Wolfenstein, but with higher resolution and framerate, of course.

The environment materials are all pure shader programming. Simple patterns that blend a mix of colors, which respond to the music and some player actions, give the world a feeling of being alive and responsive, which was a core pillar informing the design. I like playing with shaders and mixing variables into equations to produce a cocktail of effects, so other than a few textures in some sections, most of the graphics are pure equations and code.

The on-screen VFX follow the same script, but the backgrounds are all animated by Weirdcore. The psychedelic trance of moving colors in the foreground with hand-drawn animations layered on top of a blanket of magical starry skies gently throbbing in the backdrop gives every frame the energy of the dreamscape I want players to experience.

Procedural games often rely heavily on modular assets. How did you design your asset library to support variety while maintaining a cohesive visual identity?

We're pretty light on asset variety, so this was a challenge I overcame by cutting corners I felt weren't necessary for the experience. Other than the modular level system we discussed before, all the environment art, props, and models are organized into pools that each level segment can spawn on demand, which distributes the assets into the level. It's really simple, and the visual identity, an abstract psychedelic Tokyo subway, is only hinted at in parts, but the game doesn't hold onto it too strongly or force it on the aesthetic.

The visual identity of the game is its own unique amalgamation of random assets that don't bend over backwards to make it cohesive or recognizable in any artistic way. I didn't want the visual design to have that cohesion. I wanted it to be somewhere in the middle, its own thing that's not easy to put into words or explain any kind of meaning behind it. I want to discourage that mental move altogether. Don't try to make sense of it, or do and come up with whatever you feel it means to you.

Are there any custom tools or internal systems your team developed to support procedural generation, iteration, or testing?

Am I counting five iterations of the level editor? Obviously, I took the scenic route! It wasn't until after the Steam Next Fest demo last year that I really started to develop, iterate, and test the modular level sections properly. We had prefabricated sections that were baked in Blender with custom scripts exporting a complex JSON describing the level models and entities. I used that system for a while, but it wasn't allowing me to iterate quickly, so it bothered me.

The new system we have now, which I described above, accelerated the process exponentially. I could retouch levels, hit save, alt-tab into the game, and pull in the new data at the press of a button and replay the section to test it instantly. This was the core design-test-iterate process I employed for the level design process. Testing the generator that would place these segments into longer arrangements was tricky.

I would manually re-run arrangements for hours to check for discrepancies in the blueprints, but that wasn't a scalable solution to the problem. Eventually, I wrote an auto-runner that would allow me to leave the game running through levels and log any errors for me to check later. Altogether, this made for a design and testing pipeline that served me well.

Performance can be a challenge in fast-paced FPS titles with lots of effects and dynamic content. What strategies or optimizations were key during development?

I'm no Jon Blow, but I like writing code that's lean. Efficient or performant? Well, it depends on who you ask. The extent to which I was able to achieve that is debatable, of course, but I've made sure to the best of my abilities that the game runs smoothly. All the assets in the game are pooled and stored in memory for the generator to shuffle around without having to load in or free up anything during gameplay.

A handful of enemies are recycled and replaced throughout the run since they all share the same assets. Most of the smaller props that repeat often are being instanced on the GPU. The world geometry is prepared on the fly, which is a little bit expensive, but with a flood fill humming in the background informing the renderer to lift and place new blocks in sequence, it's pretty optimized to accommodate the simple environments it paints.

That said, despite having tested on low-performance hardware, I'm not making any promises because issues like this can emerge after a lot of players with different setups jump in on release. There are a few instances where she might buckle under pressure or drop frames, which, for a game about flow, isn't the best look, so I'm standing by to address them as soon as they show up.

Looking back, what were the biggest technical or creative challenges you encountered while building TAMASHIKA?

I think of myself as technically minded, for the most part. I have an affinity for numbers, functions, and equations with what feels like a somewhat rigid systems-thinking approach to everything. But somehow, when I'm working on games, that muscle just wants to relax completely. Looking back at all the games I've made, I started to notice a throughline that informs a lot of my taste, style, and aesthetic that finally made its way into Tamashika more intentionally.

I speak to game designers and often find myself completely stumped by all the technicalities and systems they discuss so passionately, so many rules, which make sense, but don't always align with the way I like to create. To me, a game is always first about how it feels, with everything else being secondary to that. Trusting my style and preference and staying true to the feeling I wanted to deliver, especially in cases where it would otherwise go against design trends or offend user expectations, was the one challenge I overcame with Tamashika.

A lot of fighting with the voices in my head telling me she should be this way or that way, and coming to learn they're not mine. Regardless of how she's received, I'll know on release that I stayed true to what experience I wanted to create, and I'm grateful to have had a team of talented people that's pushed me to explore my creativity and help realise my vision.

Vidhvat Madan, Game Developer at quicktequila

Interview conducted by David Jagneaux