Euclidean Header Top

Euclidean is a simple game – you sink into an otherworldly abyss and struggle to avoid the Lovecraftian horrors revealed by brief flashes of light – but making it with a tiny budget in just under six months was anything but simple. Here Ryan Span (Creative Director) and Lars Simkins (Producer, Programmer) dissect what went right and what went wrong during the development of Alpha Wave’s first VR title.

8 Things That Went Right

1. (Lars) We made the first truly ‘Lovecraftian’ game

A bold claim! But as a longtime reader of Lovecraft I’ve always felt a bit disappointed with ‘Lovecraftian’ games. I enjoy most of them on their own terms but my experience of Lovecraft doesn’t have much to do with squishy tentacles and giant beasts. It’s a state of mind that no game has managed to put me in before. Lovecraft himself said it best:

“The true weird tale has something more than secret murder, bloody bones, or a sheeted form clanking chains according to rule. A certain atmosphere of breathless and unexplainable dread of outer, unknown forces must be present, and there must be a hint, expressed with a seriousness and portentousness becoming its subject, of that most terrible conception of the human brain – a malign and particular suspension or defeat of those fixed laws of Nature which are our only safeguard against the assaults of chaos and the daemons of unplumbed space.”
H.P. Lovecraft, Supernatural Horror in Literature

Capturing that feeling was the team’s primary goal, and it turned out to be a tricky one. Games are designed around the power a player has over their fate. Without that power it’s just a passive experience, not really a game at all. But for the Lovecraftian mood to take hold the player must be made to feel utterly powerless! Finding the right balance between passivity & control required a lot of experimentation, but based on the reactions we’ve seen from Lovecraft fans we managed to pull it off. (This is actually the first time I’ve been able to say something like that about a project I’ve worked on. Normally I can’t see them as more than ‘not a total disaster.’)

2. (Ryan) We created something memorable


In a market of clones and minor variations on a theme, we tried our very best to make something that nobody had seen before. Not so much in gameplay — infinite running/falling is not a new concept — but in atmosphere. A different kind of horror, like Lovecraft’s own stories. Feedback and reviews have been very interesting to see. Some players spoke out against the game, even seemed offended at classifying it as ‘horror’ at all because it doesn’t feature any familiar tropes or jumpscares. Other reviewers and Let’s Players have emerged from the game visibly shaken by the experience, especially on the Oculus Rift. If nothing else, for those players, Euclidean is exactly what we wanted it to be: a game that’s not easy to forget.

3. (Lars) We kept it short and cheap

When we started Euclidean most of the team was still reeling from developing the open-world game FRONTIERS (which is still on Early Access as of writing this). We knew we didn’t want to deal with another expensive time sink, so our first step was to settle on one gameplay mechanic- falling – and one tone – Lovecraftian. Every ounce of effort was spent on making those two elements work. When we sensed that our ideas were drifting into territory outside these goals, we cut them. The short length was also something we decided early on. After experimenting with stage design we found we could keep our falling mechanic varied & interesting for about one hour. We were a bit nervous about this length – at one point I even considering delaying the game to create an additional ten stages. But upon release we found that nobody really minded, mostly due to the low price ($3.99). People seemed to sense that we had explored every possibility by the end and appreciated that we didn’t bore them with unnecessary padding.

4. (Ryan) We let player feedback bend the design without breaking it

When our beta playtesting data came in, the message was very clear. The game was interesting, but it lacked something. Multiple people said the exact same thing: They kept waiting for a new mechanic to be introduced besides movement, but at the time we didn’t have anything. This resulted in a lot of panicky design discussions. Many ideas were brainstormed — time reversal, teleportation, and more — but we couldn’t afford to add anything that would make our development time balloon out of control or undermine the game’s core premise of helplessness. It needed to strike a balance between giving the player more control over their own fate without making them feel powerful. Ultimately we settled on the Phasing concept, an idea that both enhanced gameplay by affording the player more agency and allowing us to design more fiendish levels, and fit into our dev cycle. For an almost last-minute addition it surprisingly didn’t disrupt things much.

5. (Lars) We weren’t afraid to alienate players outside our niche


Ryan insisted that the game should be difficult on every level – difficult to play, difficult to understand, even difficult to start! Notice that I’ve stopped saying ‘we’ – that’s because these choices made the team very nervous and there were times when I argued strongly against them. I understood how difficulty supported the goal to make the player feel powerless. But I was also seeing playtest after playtest end in disaster as players would rage quit in frustration.

This was a point of contention for months but Ryan defended his choices persuasively and the team eventually shifted our attention from reducing the difficulty to preparing players for the difficulty. For instance, the game offers three difficulty levels – Hard, Nightmarish & Impossible – and on-screen tips in the opening stage taunt you with your fragility. Touches like these didn’t keep us from alienating players who weren’t sold on our Lovecraftian premise, but those that were embraced the difficulty as an essential part of the experience. Finally seeing players respond to the challenge in the way that Ryan had hoped was a relief for everyone. Our target audience benefited from his willingness to piss everyone else off.

6. (Ryan) We did a lot with a little

From conception to completion, the project took less than 6 months. The first inklings of an idea came out in a discussion on 2 April 2015. On 25 September, with a team of 5 people working in their spare time, we released a full-fledged and largely stable 3d game. Short, but sweet. We worked hard to get the most mileage out of every asset and every useful skill on our team (this was my first proper stab at voice acting, and Lars’s VFX experience came in handy multiple times) and occasionally stepped out of our comfort zone to acquire new skills when they were needed. Difficult, nerve-wracking, but ultimately worth it. We’ve even had requests to release the game’s soundtrack, which was almost entirely assembled from bought royalty-free assets and Creative Commons stuff from

Really, any indie project has to face a trade-off between time, quality and money. Our budget was almost nonexistent. Our projected time-frame was tight. Compromising on quality is always an easy position to be forced into by deadlines and circumstance, but by keeping the core idea small and simple, we managed to polish what we did have to a level where the look and sound became a genuine draw for players. Without that audiovisual atmosphere, the game would’ve been dead in the water.

7. (Lars) We used the Unity engine

Custom stage editor in the Unity engine

I have a love-hate relationship with the Unity engine, but most of the hate comes from trying to push it in directions it was never meant to go. The engine has a large number of unwritten, undocumented ‘rules’ and if you try to get clever & work around them you do so at your own peril. For Euclidean we chose to stay on their garden path and design something that played to the engine’s strengths. Whenever a concept broke the ‘rules’ we would cut or modify it it. We used PlayerPrefs instead of using a custom save game solution (ugh). We followed the guidelines for static & dynamic batching religiously. We avoided third-party tools except when absolutely necessary. And when third party tools were absolutely necessary we used only the most robust, well-tested options (eg InControl, 3DCeption). The result was a mostly painless experience with the engine. And most importantly for a VR focused title, performance issues were easy to nail down and fix – the game can hit 120fps in VR on a GTX 660ti.

8. (Ryan) We came together as a team.

This was my first project as team lead, a position I always wanted, and it was a very satisfying experience. It also made me realise I knew nothing about team management or truly effective communication. I’d written design documents before, had plenty of discussions with team members on other projects, and thought I was prepared. I wasn’t. This one could have easily gone in the ‘What went wrong’ category if not for the team’s grit and dedication, which allowed us to ultimately unite behind one vision of what the game should be.

8 Things That Went Wrong

1. (Lars) We didn’t do nearly enough external playtesting

The game’s extreme strangeness / difficulty made it very hard to find willing playtesters – I burned through my core ‘go-to’ team within a few weeks and scheduled only a handful of additional sessions towards the end of development. When we sent out preview copies to let’s players we thought the game was totally stable, but we watched in horror as the streams revealed bugs we had never encountered before. We were able to fix most of them before the final release but we couldn’t do anything about the bugs on record. We should have paid a handful of playtesters for sessions leading up to release. The cost would have been worth avoiding that last-minute panic.

2. (Ryan) We used the Unity engine

There were pros about using Unity. And oh, there were cons. Unexplained letterboxing and flickering at certain resolutions. Controller support that took weeks to debug. But the one I will always remember was the adventure of updating to Unity 5.2. Lars nearly had a nervous breakdown when, about two weeks before we were supposed to launch, we ran into a big problem where the game was being shoved into one corner of the screen in fullscreen mode. It resisted our every effort to fix it. He was convinced that it must’ve been something we did, though, because “Unity would never let a bug that huge into one of their major releases.” (You can see where this is going.) Through some ridiculous testing we confirmed that the bug had been introduced in Unity 5.2 and they ultimately hotfixed it before our release. Even now there are engine bugs in Euclidean that I don’t believe we’ll ever be able to fix. I shudder to think what kind of nightmares we would’ve run into with a more expansive game.

3. (Lars) We made Direct3D 11 a system requirement

We chose to rely on Direct3D 11 shaders to render several environments and creatures. This choice ended up cutting us off from a large number of potential players. We probably could have achieved the same look with custom solutions but we were running out of time and needed a way to render thousands of geometric shapes at 90 frames per second. This requirement has led to a great deal of confusion about system requirements – many players use graphics cards that claim to support D3D 11 but in truth merely support Direct3D 10.1. This will become less of a problem as the old cards become less common but I regret not setting aside more time to create a D3D 9 compatible solution.

4. (Ryan) We were overconfident about our timeframe

We thought we’d learned our lesson with Frontiers. We came up with optimistic estimates of work and time requirements for Euclidean, and threw them away entirely. We were going to be realistic about this one. We went with a timeline that we considered very conservative. Well, our worst-case scenario came and went. Development ran two months longer than intended, half again what we were planning to spend. It came down to a choice between that and releasing a shoddy, unfinished and substandard game on time. It was not a good place to be.

For one thing, next time we won’t be so quick about announcing release dates. Nothing makes you look worse than setting your own release date and then missing it by a mile.

5. (Lars) We targeted the wrong crowd with our marketing


I actually enjoy the marketing side of development but our marketing budget for Euclidean was nonexistent. We decided to spend what little we had on a small marketing firm to help us distribute the game to lets players before release. Unfortunately we did a poor job of communicating with this firm about what the game was – they honestly didn’t know what to make of it – and their confusion was passed along to lets players. Many knew nothing of what to expect beyond ‘it’s difficult’ and while most had positive things to say the game didn’t seem to appeal to their viewers. Awareness in our core audience has continued to grow since launch, but mostly through word of mouth, not via YouTube. In retrospect it seems obvious that we should have put that money towards targeting our core audience directly – for instance, when we reached out to a small Lovecraft fan site it resulted in more sales than a Lets Play with 10k views.

6. (Ryan) I wasted time resisting jobs I didn’t want to do

I’m not a natural with programming or complicated tools. The Unity editor was daunting to me. Photoshop still makes my head spin. The act of designing levels or balancing game mechanics makes me lie awake at night wondering how many people will hate me or how my game is going to fail miserably if I don’t get it exactly right. There’s huge chunks of the game development process that still fill me with dread, and I was hoping I could avoid them on Euclidean.

Unfortunately reality doesn’t work that way.

It’s easy to imagine oneself as an auteur designer calling the shots and shining a pure vision down from on high, and letting those lower down on the totem pole worry about the nuts and bolts. However, every bit of grunt work you pass off to someone else is subject to a kind of Chinese whispers effect, where things get lost in translation or the other person just doesn’t quite ‘get it.’ Even when talking in real-time, it wastes a ton of time passing screenshots, videos or SVN commits back and forth. We lost whole days to tweaking and trying to communicate when the best solution was ultimately to come down off the high horse and get my own hands dirty.

7. (Lars) We didn’t make the seated VR experience more comfortable

Euclidean is comfortable to play in 2D and equally comfortable to play in VR if you’re standing up. However as a seated experience it can be uncomfortable for some players. The way we set up our environments combined with Unity’s native VR implementation left us unable to take advantage of the trick used in early VR games like AaaaaAAaaaAAAaaAAAAaAAAAA!!! for the Awesome, which is to tilt the camera down by 45 degrees. In the end we had to choose between the significant performance gains of native VR support vs rotating the camera, and since judder is less comfortable by far we opted to go with native support. We hope to change this in a future update but until then our low comfort rating stands to cost us a lot of potential VR sales. The sad part is if we’d discovered the problem at the very start we probably could have avoided this.

8. (Ryan) I still thought like a solo designer

I’d been in leadership roles before, but only for people in my own discipline. I knew my part in the process, but lacked understanding and appreciation for some of the big challenges in programming, art and sound. That caused some completely unnecessary friction and miscommunication which could’ve been avoided.

In future I’ll be making sure I know how long it’ll take to do something that’s not technically necessary before asking for it, whether it’s a feature, a piece of art, or anything else.


Despite typical development headaches we’re pleased with how Euclidean turned out. Awareness has grown steadily thanks to word of mouth and we hope its audience will grow further once consumer HMDs hit the market. It took a lot of discipline to keep our goals simple and stick to our low budget but it paid off with a unique and tightly focused game that does one thing well and doesn’t overstay its welcome. Alpha Wave’s future VR titles will be handled in the same way.

If you want experience the world’s first truly Lovecraftian game you can find it here on Steam.

Thanks for reading!