Tag Archives: devlog

Derelict 54 Devlog

Intro

I started kicking around the idea for Derelict 54 probably during the development of Terminal 2.  I made Terminal 2 for a class that required it be in HTML, and even though I didn’t have any substantive experience with 3D engines at the time, I wanted to see how the concept would translate to 3D on the budget I had to work with (namely, $0).  At first glance, Derelict does not seem like a straight port of Terminal 2 (aside from my habit of using arbitrary numbers in game titles). Its closest inspirations are Frictional Games’ Soma and Orthogonal Games’ Near Death, games that use computer terminals sparingly, if at all. The first section is a hallway with a simple keycard puzzle.  But the aspect of Terminal 2 I wanted to expand on the most wasn’t, well, the terminal, it was the tone. This is a bit obvious since I even use the same track as background music in both games: the main theme from Soma. So, the core inspiration was more aesthetic than literal; I wanted to take the feeling that Terminal 2 evoked through text, and translate that into the immediacy of a 3D world that the player interacts with from the first-person perspective.

Visuals

I’ll get to the actual mechanics in a bit, but probably the most important part of creating that tone was the non-interactive bits: the sound design, the environment design, the lighting, etc.  I really like how the music sets up this tone, and its importance to establishing that tone is why I could never release this on Steam: I’d have to remove it. So, weirdly, I ended up crafting the visuals around the tone that music created, instead of Capturethe other way around.  I knew there was a space station. I knew it was mostly abandoned. And…that was pretty much it. So, I pulled up one of Epic’s free Unreal Engine packs, Sci-Fi Bunk, where I pulled nearly all of my assets from. The tone of Sci-Fi Bunk was laser-focused, despite not having any actual lore.  It’s cozy but lonely. I wanted Derelict to feel a bit more imposing than that, so I borrowed the orange tones of the lighting but spent a great deal of time tweaking it to be just a bit darker and slightly more blue. Lighting and color in general are absolutely not my area of expertise, so I don’t quite have the language to explain why I made these decisions, it just “looked better”.

Mechanics

That first hallway was mostly where I figured out most of the tone of the game, but when I reached the end of it and created the first keycard puzzle, I realized that I still didn’t have any real mechanics for the game.  Like, keycard puzzles are all well and good, but they’re not exactly new gameplay. So, while building the next room, I started to figure out how I wanted to convey the tone I established while building the first hallway

near_death_01-1024x576.jpg

I literally cannot stop writing about Near Death

mechanically.  I ended up taking an idea I briefly used in Terminal 2, powering up unpowered systems, and expanding upon that. I can’t completely explain why, but the act of restoring power to unpowered sections of stations is deeply satisfying to me.  And yes, I realize that this is a stupidly specific thing to enjoy. But that is part of why Near Death was so compelling to me, because it’s entirely about fixing up old buildings to complete objectives. To explain why I enjoy this, I have to tangent a bit into, like, the fundamental nature of designing non-combat gameplay.

There’s an episode of Errant Signal that describes this in way more detail than I could, but basically, games are really good at simulating things that are spatial, and combat is a really simple spatial thing to simulate.  Problem is, when you move outside the realm of combat and platforming…there aren’t a ton of ways to simulate things. So, a lot of indie, combat-free games run into this problem where they’re either simulating really complicated spreadsheet things, like Cities Skylines, or they aren’t really simulating much at all, like Dear Esther.  Now, I love Cities Skylines and Dear Esther, but they both have a pretty limited possibility space, at least in my opinion, for future games to expand on. As great as it is, you probably aren’t going to replay Gone Home over and over toe experience its rich mechanics. But Near Death, Soma, and other games like it, do find a way to do non-combat spatial simulation.  I write more about the tone of this in my post on the genre I’ve named Will and Wits, but the core idea of some of its gameplay is basically struggling against the very space you exist in: fixing breaking systems, avoiding hostile ones, and generally trying to use your brain to stay alive.  Near Death has this wonderful gameplay loop where you get to a building cold and low on resources, and its power is out, so you have to spend more resources to keep yourself alive. But, after some work, you can get the power back on, and the space goes from feeling hostile to feeling cozy.

I adapted this idea into Derelict by making the player’s primary goal to get enough power to open the final door on the ship.  They do this by finding repair kits scattered throughout the ship and using them to fix broken power stations. They can then redirect that power to the doors they want to enter using the power screen in the game’s hub room.  This leads to a lot of backtracking, something that is often derided in game spaces, but I personally enjoy, and gets the player familiar with the space. They feel like an engineer, patching up a dying ship. In fact, the only real survival system I added to the game was a result of trying to communicate the slow hostility of the environment, and that’s the oxygen meter.  When the player starts the game, they have an oxygen readout at the top of their screen which slowly ticks down to zero. They can replenish it by collecting oxygen tanks scattered throughout the environment. Thing is, the player’s

Capture3

I may have gone a bit overboard on the sparks

oxygen will basically never hit 0. In earlier builds of the game, the oxygen ticked down pretty fast, which made playtesters scramble from objective to objective.  But this wasn’t really the tone I was trying to create, so I decreased the oxygen to a point where, unless the player just stands in one place for a few minutes, it will never reasonably hit 0. I’ve never had a playtester die from hitting 0 oxygen. So, the oxygen system doesn’t really serve much of a mechanical purpose, technically, but the player doesn’t know that. It’s deadly enough that it does create some tension, but slow enough that they player feels okay lingering in areas.  The tension is ambient, not intense. So, the end result of these systems, hopefully, puts the player into the headspace of an engineer working under time pressure.

Story

It was around this point in development that I realized I didn’t actually have a reason for the player to be on the ship.  Honestly, I still don’t, and if you actually put some thought into it, it doesn’t really make much sense. So, the player’s there to rescue the crew?  But the crew is (mostly) evacuated. Did they get stranded on it? Are they one of the crew? No answer really works. And, honestly, I’m okay with it.  The point is that the player is trying to escape the environment; they don’t really have a purpose beyond that. The protagonist is so loosely defined that it’s just not important.  But, I needed some sort of story, so I tried adapting what I made in Terminal 2, but with one major change: an actual ending. I had to stop halfway through my expected story for Terminal 2 because I just ran out of time before the assignment was due.  So, for Derelict, I wanted something a bit more complete. Weirdly, I came up with the ending first, and built the rest of the story around that. I had a specific moment in mind, where the player walks to the airlock to leave the ship, and looks at the door to the engine room, knowing that the person they’ve slowly come to know is locked on the other side, and that they have to leave her there.  That specific moment of just a few seconds was what the entire experience was crafted around. Every system and narrative element had to be tuned around that.

So, I took the idea from Terminal 2 of this absent mechanic communicating with the player in a way they couldn’t respond to, and iterated on it.  This was partially by

Capture5

The site of one of my at least ten blatant thefts of sound assets from Ridley Scott’s Alien

necessity, I didn’t want to implement a branching dialog system, and I like the idea of that one-sided communication for thematic reasons anyways.  So, this lead to me designing the HUD to support these messages, but also forced me to do something I’m really bad at: writing dialog. I cannot write good dialog to save my life.  Everything I write just sounds awkward and clunky. So, I tried to minimize it, revise what I did write a lot, and keep things brief and to the point. Problem was, when I came back to revise some of it, I realized the player didn’t really have a connection to Conrad.  She spoke like…twice? And, yeah, that makes the ending gut-punch difficult to pull off. There needed to be a relationship for that to work. So, I started finding more moments to add in bits of dialog, one at each major checkpoint. I tried to add more personality to the dialog, because that’s also something I’m not great at, and I changed up the ending a bit to add more emotion to the gut-punch.  In earlier builds, Conrad was pretty much dead by the time the player arrived. She had been exposed to radiation, and had made the decision to permanently lock the door to the room she was in, removing any possibility of escape. That works fine, but I wanted the player to be complicit in her ultimate fate somehow. So, I mixed up the ending so that the player would have to unknowingly push the button that doomed Conrad, and she would have to mislead them into doing so.  Even though the actual gameplay is the same, the end result is the player feeling at least somewhat responsible for Conrad’s death, even though there really was no other option. I kept the moment quiet, because I like it when games give the player space to think and feel through the implications of their actions without comment. And the player then gets to leave the ship, hopefully, with a sense of uncertainty.

Virtual Reality

That was pretty much where I left Derelict when I finished the 1.0 build, but I recently revisited it with the idea of porting it to VR.  I had been itching to make a VR game ever since I got my Vive, but hadn’t found a good project. Derelict ended up working wonderfully.  Originally, it was going to be a quick and dirty port, slapping a VR controller on and calling it a day; a logical transition taking the game idea from HTML, to 3D, to VR.  But, the more time I spent with the game in VR, the more changes I wanted to make. Let’s start with the basics. Just swapping out a regular monitor for a VR headset already changes the way the player interacts with the space.  They feel more present, obviously, and gives me even greater returns on the tone I was trying to create. But then you add in motion controllers, and things get a little more complicated. This took a lot of work from a technical perspective, mostly because the Unreal VR blueprint, while wonderfully made, is still fairly new and thus poorly documented.  So, figuring out how to do things like stop the player from teleporting through doors was a big concern. But once I had that in place, I noticed that the levels felt barren and empty, especially compared to the tightly-packed, detail-focused level design stylings of contemporary AAA games. So, I shrunk the entire station by about 25%, which did end up solving the problem as best I could without adding a ton of new assets.  I was still limited by the assets that Epic had made for free and the few I contracted from a friend (they keycard

Capture2

Thanks, Chris, for the beautiful repair kit models

and the repair kit), but by this point I had found the Sci-Fi hallway demo, which gave me many more assets to work with. I added better texturing to the walls and floors, I had actual static meshes to use, examples of better post-processing effects, it was great! And, to make it even better, these changes made the first-person version of the game work even better, because it encouraged me to design with a closer attention to detail.  However, there was one bit of design in VR that was fundamentally different from the first-person version, and that was the HUD.

HUDs aren’t really a thing in VR.  Or, rather, they are, but no one has figured out a way to do it that isn’t incredibly clunky.  So, if you want to communicate information in a similar style to a HUD, the best option so far is the wrist watch communicator thing that a lot of games, such as Rec Room, use.  Basically, you look at your arm, and a little screen pops up, showing you information that would be on a HUD. This only works for information that isn’t urgent, so you couldn’t put something like a health bar on there.  Fortunately, Derelict didn’t have any information that needed to be communicated that quickly, so I was free to offload basically the entire HUD onto the player’s arm communicator. Whenever the player gets a message from Conrad, picks up a useful item, or needs to see a tutorial prompt, their controller vibrates and beeps, and they can open up the screen to see the message.  Now, I could have done the same thing with the power management screen, which, in the flat version of the game, pops up on the HUD, but I was interested to try out 3D HUDs, so I moved that into the world itself. Instead of an extra page on the player’s wrist communicator, the power screen is an actual actor in the game world,

Capture1.PNG

I probably should have hired an artist for this one

interacted with using motion controllers. While the screen does look a little awkward and out of place, since it’s basically just a cube with buttons, I think it adds more to the immersion by removing what could have been yet another HUD element.

Final Notes

So, what started as a HTML puzzle game ended up as a VR adventure game fully designed to work with motion controllers.  And even though those two games are pretty far removed from each other, they still share a lot of formal similarities. Even the dialog itself is still delivered in much the same way, with the player reading from a dark screen.  In the latest version of the game, that screen is attached to a motion controller on the player’s arm, but it’s still fundamentally the same idea. I’m not sure how I can further iterate on the idea from here without just expanding the budget and hiring actual artists, but I’m happy with having followed this thread of design through to what I think is a nice endpoint.

Capture4