This is the second in a series of development updates that I'm going to be posting roughly monthly to keep everyone apprised on the game's progress, talk openly about how I'm trying to solve game design problems as a first time game designer, and hopefully elicit some feedback and excitement for things to come. This second entry covers my current work on level design.
If you've seen the trailer for The Technician, you may have seen a couple environments: one relatively plain/empty "Tutorial Room," and one more detailed "Server Room" location. The Tutorial Room is relatively straightforward and was easy enough to make (and may not even appear in the final game), so I won't bother talking about it too much here, but I do want to talk about my thought process behind the Server Room and how things have evolved since then.
The Server Room
My goal for The Technician has always been for it to invoke that under-pressure, keep-your-head-down, bullets-whizzing-by-while-you're-trying-to-focus feeling. Initially, I tried to do this in part by having all of the hacking take place very low to the ground, basically placing all of the circuitry underneath a "desk" of sorts. Through a series of play tests with friends, I observed that this forced the player to be crouching down almost constantly; not only to dodge incoming attacks, but even just to get to the puzzle. While this did cause some of the desired feeling of being under pressure, it also quickly became clear that crouching down so much was very uncomfortable and made the entire experience unpleasant. With this play-test feedback in mind, I decided to ditch the always-crouching idea and designed the new Server Room with a few new ideas:
In spite of these changes and improvements, it turned out there were a couple of things I didn't like about how the Server Room turned out:
Introspecting and Improving
It took time and introspection, but I finally realized that the static nature of the Server Room highlighted a major Real World limitation: that fact that I can really only do so much. Not only is this my first time attempting to make a game, it's also a completely solo endeavor, meaning that my biggest bottleneck is the amount of time it takes to generate content, particularly content that I'm not experienced at making (which is really just about anything that's not code.)
In a world where I had more time and money, I would love for The Technician to take place in a bunch of different spaces, each with their own unique environmental interactions and gimmicks. In this world though, I'm rapidly running out of time to make a 2018 release, so I decided to try making one more level that would hopefully fulfill some new requirements I had:
With these new goals defined, what did I do to try and fulfill them? The main point of this article is to introduce my new level, so let's finally get to it and take a look at:
The Space Elevator
Right away you might see the fairly obvious solution to my "multiple puzzles" requirement here: each floor has its own puzzle, and solving it will take you to the next floor (and thus the next set of puzzles). I needed a way to make this mechanic obvious to the player so I also added a few new puzzle pieces, including an elevator override control and elevator locks. The Technician finds the locks and disengages them to enable to elevator override, then hits the override to advance to the next level.
This new set-up also helps solve my iteration problem - I designed the cargo elevator to make it easy to try different permutations of cover, enemy approach vectors, and types of puzzles. The circuits themselves are located in compartments of varied layouts on the elevator's central column, and the tech's play area is now surrounded by numerous boxes and crates being transported up the shaft along with the player. The crates make for natural cover, and it's easy for me to move them around while I continue playing with the balance of "puzzle difficulty" versus "getting shot at." The layout also provides a handy place for all of the technician's tools and equipment.
In Conclusion
Landing on the right in-game play space for The Technician has required a lot of iteration (and will still require much more,) but it was interesting to uncover how real-world constraints like time and expertise influenced the type of levels I ended up having to design. Play-testing with real humans helped this process along, as did thinking about how to make my goals achievable as a solo developer via changes in design. I think the space elevator strikes a good balance between "visually interesting for the player" and "easy to play with permutations of game mechanics." Hopefully with a bit more iteration in this new layout, I'll be able to get a satisfying flow of pressure and problem solving, with natural spikes in tension and adrenaline, as well as resting/recovery points for the player.
Thanks for reading, make sure to drop me some comments and let me know what you think. Next time look out for a post about the various Technician tools and equipment that I created for the game.
Development Update: Simplifying Circuitry
This is the first in a series of development updates that I'm going to be posting roughly monthly to keep everyone apprised on the game's progress, talk openly about how I'm trying to solve game design problems as a first time game designer, and hopefully elicit some feedback and excitement for things to come. For this first entry, I want to talk about some new circuit components I've added to not only expand the types of puzzles in the game, but also to make the puzzles more interactive, more accessible, and simpler to design - without sacrificing challenge. I'm also going to talk about circuits and logic on a more rudimentary level in this post in the hopes that it will help people (who might be unfamiliar with things like logic circuits) understand and feel comfortable with The Technician's gameplay.
(This post also available with higher quality images over at the DGC website))
The Basics
If you've watched the announce trailer for The Technician, then you've seen a few of the basic components that circuit puzzles can be made out of. Power sources, switches, buttons, wires, logic gates like AND and OR, and so on. All of these behave like relatively 'traditional' bits of circuitry: they read an "on" signal from their inputs (or don't), maybe run some rudimentary logic, and send an "on" signal (or don't) to their outputs. On some level, that's all a logic circuit really needs; basic gates and the like will let you build all kinds of circuits provided you have the patience and board space. The problem is that complicated circuits are, obviously, complicated. Not everyone is the type of nerd that finds an endless field of boolean gates appealing, either. The bad news is that you'll probably have to be at least a *little* bit that kind of nerd to find The Technician appealing, but the good news is that since this isn't a "real" circuit simulator, we can fudge a lot of things to make complicated circuits simpler, allow for a wider range of interactions, and make it all around more accessible. At least, that's my hope! Let's take a look at some specific things that I'm trying in order to accomplish this.
Numbers
This update is all about numbers. Traditional circuitry represents numbers by breaking them down into a series of those "on" and "off" signals. I don't want to get into a primer on binary numbers here, so let's just say that this can quickly get very complicated, despite how much your friend with the Computer Science degree might insist otherwise. However, since we're fudging things, our circuits don't have to bother with this; they can just send a number directly. When you see a lit wire in The Technician, that "on" signal actually contains data. In this case, that data is a number ranging from 1 to 255, with an "off" signal having a value of 0. Easy! But what do we *do* with these numbers now that they're flying around? Let's start by just saving them.
Registers
If you wanted to build a circuit that stored a numeric value, you *could* do so with the basic logic gates that I mentioned earlier. This wouldn't be easy though, and for the player solving this type of puzzle it would be a harrowing experience, at best. Instead, let's just cheat some more and use these:
This is a basic register. Registers can receive information on their 'data' input, save it when they receive a 'load' signal, and continue to send it to their output until they receive a 'clear.' They come in a variety of flavors, too. Here's a quick look at the standard, secure, and readable registers:
Standard
The standard register has a display that handily shows whatever value it is currently holding. Very convenient for the endeavoring technician.
Secure
A secure register is just like a standard one, but decidedly less convenient for would-be hackers. Without a display, the number stored in these isn't plainly visible and can only be determined by figuring out the source or analyzing the output.
Readable
Some secure registers aren't *completely* secure. These models have 'maintenance' ports that a properly-equipped technician can exploit to read the values stored inside.
Now in addition to being able to move numbers from place to place, we can also hold on to them for future use. So what kind of uses do we have? Let's start with the obvious one: math!
ALUs
An Arithmetic Logic Unit, or ALU, is kind of like a calculator without a keypad. In keeping with my goal to make things simpler, ALUs in The Technician are simplified versions of the "real" ones. ALUs take up to three inputs (two operands and an operation), do whatever math their current operation dictates, and output the result. To further simplify, these ALUs also have a wider array of more complex operations than are traditionally present. I won't list all of them here, but let's take a look at a few notable ones:
Addition (+)
Doesn't get much simpler than this; the ALU reads inputs A and B, and outputs A+B. It may be worth noting that numeric values in The Technician only range from 0 to 255, so any operation that results in a value outside of these ranges "wraps around" to the other end of the range. This means *255+1=0*, *0-1=255*, *255+10=9*, etc.
Increment (A+1)
ALUs don't necessarily need both inputs to function. With the increment (or decrement) function, the ALU reads only one input, adds 1 to it, and send the output. When set up in a 'loop' with itself, this can effectively turn the ALU into a counter.
Equality (=)
When set to this operation, an ALU outputs the value that it reads from input A, but when it equals the value it reads from input B. In the case where B is 0, the ALU outputs the maximum value (255) when A is also 0.
Where does all this lead?
These are some basic building blocks that open up a whole lot of potential complexity for circuits, which means that the technician's job can be made a whole lot harder. It also, I hope, makes it *understanding* the technician's job a whole lot easier. Now there are secret numbers need to be ferreted out, values that need to be hacked and changed, and tricky new configurations of logic to be deciphered; not to mention the fact that trying to do math in your head while you're in a gunfight can be a bit challenging. This also means that the technician now needs tools that can read numbers from components, as well tools for injecting or overwriting values in the circuitry.
I'm hoping this continues to lead to more challenging and fun variations of gameplay in The Technician so keep an eye out for more updates soon and in the meantime leave a comment to let me know what you think!
Release announcement!
I quit my job over a year ago out of sheer boredom and decided to spend some time learning how to make video games instead of web services. It's been... interesting... so far, and now I get to announce this learning project of mine as an Actual Game! Not so "Actual" that you can *play* it, mind you, but still...
I'll hopefully be posting updates here and over at https://dumbgame.company a little more regularly now that this is announced, so make sure to keep checking in and letting me know what you think about how things are shaping up. It's been just me working in a bubble for the last year, so external feedback will be greatly appreciated!
