(No Longer) UnderWraps

Certain aspects of a developed game stay under wraps. The bad and ugly have to be hidden so that the good is what the public sees. Brutal crunch times, unpolished implementations, and personal tribulations don’t make it on the back of the box and for good reason. The first two items do pop up now and again in a post-mortem but personal tribulations are… personal. One of our team’s personal tribulations was that we had some conflicts releasing a game we didn’t think was perfect. We wanted everything perfect. This didn’t seem practical, so we had to make a decision to release and dismiss our concerns as us trying to reach an unobtainable goal of completed perfection or being our own worst critics. It didn’t take long for us to see some videos online that sent us reaching for our collars. We jumped to fixing anything we caught as possible, serious issues, and then hoped the rest would be overlooked. Our game hasn’t yet gotten its 15 seconds in the spotlight and yet early reviews revealed rough edges. These wear away at a developer’s serenity. We thought as long as there was no game breaking bugs, we could move on to the next thing, but we still have some anxieties about someone not enjoying our game or feeling like we were trying to pull a fast one, only showing our best and hiding our weaknesses. So, in the spirit of solidarity, we will highlight our game’s weaknesses to add a (albeit strange) footnote to the press releases, websites and Steam updates. 1.)

Too many cooks

Some models lack continuity (a handful of 3rd party models with varying resolutions, incorrect lightmaps, switched lead artists a year in, etc.) 2.) Lack of consistent player feedback loops (during multi-layered puzzles, new navigation points, etc.) 3.) VR compatibility with newer runtimes 4.) Poor planning lead to a huge crunch time which lead to a flawed release (had to rush to fix post release bugs) 5.) Sound design was not taken seriously (“I know how to do sound design!”-Joseph Wilhems) 6.)

Physics

“Physics are a hell of a drug. You'll feel real good at first using them, and then things start to get real twitchy, frustrated and bummed out the more involved you get.” –Joseph Marin Last.) In certain areas, we just didn’t know what we were doing. We knew how to design and develop the product but we didn’t entirely understand how to distribute it through steam or how to end the game… not gameplay/story wise, but what happens at the end of the game. How do we roll credits? Do we just reset the game? Do we boot the players to their desktop/force close the application? It has to end… right? Then came the need to update our VR code to work with the current Oculus runtime (still haven’t fixed as of this posting) because without it we have to downgrade our “Works with Oculus!” to “Functions on Oculus* *Oculus DK2 with 5.0 runtime installed and in Extend Mode.” And then the unanswered questions: Why were we able to make a Mac demo that functions but can’t make a full release package that doesn’t crash during its load in? What about a Linux build? Did we handle immersion correctly… we wanted a game that left, as much as possible, the fourth wall intact. We stood on the shoulders of giants and then wanted to look down on them. “We can make the most immersive experience that any game has! …and now, with VR!” It was a struggle to use the fundamentals set forth by the games we loved and borrowed from while also trying to reimagine them so we could use in our game. “Figure it out as you go” gameplay can be challenging even if (or especially if) the player has experienced loads of games in the last decade. The end result is UnderEarth. All that it is and everything it isn’t. We approached development of UE as obsessed parents; we were trying to give it every advantage possible while also trying to be progressive enough to generate no downsides and release on time. Now that UE has graduated from our care and guidance, we have to let it stand on its own and hope that we raised a solid member of the gaming industry. -CJ Team