next »

[RbdJellyfish]

About the Game

The game has finally been released! :D https://store.steampowered.com/app/1307870/Sensorium/

Sensorium is an open-world puzzle game in which you solve puzzles that revolve around the 5 senses: touch, taste, sight, smell, and hearing. Staying true to the Myst-vania genre, nothing in the game is outright explained to you; a big part of the game is about exploring, learning, and piecing together clues about what's going on and how everything works.

The gameplay is simple and consistent without being dumbed-down. Despite the main game mechanics being fairly different from one another, you'll always know exactly what you can interact with and when. (i.e. no pixel hunting, which is a problem that plagues many adventure games!)

Inspirations include Myst, The Witness, Portal, and Antichamber. I'm a big fan of games that present their stories and themes through gameplay and the environment rather than through cutscenes or long-winded text. Sensorium will have some central themes, but it will probably not have a traditional story (at least not a clear-cut one).

Development

This is a solo project; as of now, I'm handling all the design, programming, sound, art, and marketing. In the future, I may see if I can find an artist, since I'm really not great at 3D modeling, but right now I might be able to scrape by without one due to how simple the game's art style is. This is also my first Unreal Engine 4 project, AND my first 3D project, so it's going to be a learning experience for sure! (In fact, it already has been.)

Screenshots

Here are a couple early screenshots of the game (see later posts for more up-to-date screenshots!)

[RbdJellyfish]

Update 1 (10/2/16): Taste, Tutorials, and Portals

I've been totally slacking on the devlog front. The biggest reason for this was that I couldn't think of anything to talk about; I was thinking about what mechanics I could write about without spoiling them, or some kind of tech thing, but I was drawing a blank. But then I remembered that I originally just made this to keep up with my progress. So here are some things I've been working on since my first post.

The taste mechanic

Since this game is about the 5 senses, I eventually had to tackle "taste", which is what I dedicated some time to recently. The taste puzzles in this game are all about tasting ingredients and mixing together the specific ones you need to reach a specific final taste, which will allow you to progress. It's kind of like reverse engineering a recipe. Unfortunately, you can't actually taste things in games, and I didn't want to add extra UI to represent taste, because that would clutter up the game. So I repurposed what I already had in the game and represented the sense of taste by changing the crosshair image.

Taste mechanic demo

Each of the taste puzzles are unique, though; a big part of the taste puzzles is figuring out exactly how the ingredients mix together; not only does each puzzle have different ingredients, but the ingredients themselves will mix together in different ways. Since they're all pretty unique, I spent a lot of time breaking the mixture types into categories and programming each category as a special case. I don't think the way I came up with is the best way of doing it, but it works pretty well for now.

The beginning area

I had my sister play the first area in the game. Basically, the goal of this area is to teach you how to move, how to jump, how to interact with things, and what these little logic gates do.



The logic gates are kind of a weird mechanic, in that they're going to appear throughout the entire game, but they're almost always going to come second to the main "sense" puzzle mechanics. So they're pretty central to how the game works, but also not. Still, I think it's important that people understand how they work in the game.

That said, when my sister played it, she did not understand how they work in the game. I did a bad job of introducing them, and they didn't reflect their function very well visually, so she ended up confused about what they were even for. So I spent some time the last couple weeks redesigning the puzzles in the entry area and refining the logic gate visuals so they provide more feedback about what they do.

Logic gate animations

Haven't had a chance to playtest and see whether or not the redesigned level is an improvement or not. Hopefully it is. Even if it isn't, though, I won't be surprised if I end up redoing this area again in the future. Because tutorials are important!

Portals

This is kind of a small part of the game that I finally figured out how to fix. Remaining vague to avoid spoilers, there's a part where you have to solve a maze with no walls. If you do it correctly, you can proceed. If not, you wrap back around to the beginning. I wanted to make the wrap-around seamless and non-euclidean, because that's cool and confusing. A simple teleportation wasn't seamless enough because of small differences in the lighting between the entry and exit tunnels, so I looked into rendering portals.

It didn't take long to figure out how to do simple portal rendering using a UE4 scene capture, but I hit a strange problem that I had a hard time finding a fix for where the portal would render a frame behind everything else, resulting in noticeable latency when you looked at it.

Portal with lag!

I was about to dive into UE4's rendering code to get something faster, but then a reddit user by the name of /u/Kazuja told me I could just change the tick group of the portal camera so it would update its position earlier. Now I have a lagless portal! There's probably only going to be one or two in the game, and I still need to mess with the color correction to make it more seamless, but it's still exciting.

Portal with no lag!



So that's it. Anyway, I'm gonna try to update this more often with my progress. Odds are most of my posts are going to be shorter than this one, but I hope it'll be more frequent at least.

EDIT: Un-embedded the gifs so the page doesn't lag so hard

[Thaumaturge]

That's an interesting way of handling taste, I think! As I understand it, it's essentially akin to games like Tangram: the player is required to compose an image using a variety of image-parts. That actually seems to me to fit quite nicely with the idea of flavours combining. ^_^

Hmm... Have you considered including some of the other human senses than the "traditional" five? Doing so might overload the player with puzzle mechanics, admittedly, and some might be less interesting than others (I'm not sure of what one would do with hot and cold, for example), but there may nevertheless be a few puzzle ideas to be had.

[RbdJellyfish]

Totally wasn't thinking about Tangram while making this, but that's a good comparison! I'm planning on adding some that are more than just combining shapes to keep it from getting stale though (for example, including colors or sounds to the taste).

I've thought a bit about the extra senses, and some of them seem interesting, but a lot of them seem like extensions of the sense of touch to me (like pain and temperature). You make some valid points, though, both about possibly interesting puzzle mechanics, but also about overloading the player with mechanics to learn. I'll probably think about it more in the future. Still have some stuff to figure out with the main senses first

[Thaumaturge]

... (for example, including colors or sounds to the taste).

I would suggest caution in making colour or sound a primary element in a puzzle (the former especially)--remember that colour-blindness is not all that uncommon, and not everyone has a good ear for sound. They're fine as secondary elements, or when combined with other elements, but used alone as primary elements they may make your puzzles far more difficult for some players.

... but a lot of them seem like extensions of the sense of touch to me (like pain and temperature).

My (admittedly inexpert) understanding is that they're distinct, but that the exact number and delineation of the senses is somewhat debated (especially as the definition of a "sense" is itself somewhat debated).

I'll probably think about it more in the future. Still have some stuff to figure out with the main senses first

This may be wise, indeed!

[RbdJellyfish]

I would suggest caution in making colour or sound a primary element in a puzzle (the former especially)--remember that colour-blindness is not all that uncommon, and not everyone has a good ear for sound. They're fine as secondary elements, or when combined with other elements, but used alone as primary elements they may make your puzzles far more difficult for some players.

I'm curious if this is even avoidable in the game I'm trying to make, considering there will be areas based on sight and hearing. I could probably avoid making color-based puzzles because there are plenty of other ways to twist the sense of sight, but making an entire area based on hearing where sound isn't the central mechanic would be kind of strange. But yeah, I'm well aware of how many people dislike sound puzzles, so I'm trying to figure out ways of making them not annoying. One thing I really don't want to do, though, is make the game easier just so more people can play it. I really would like it to be as accessible as possible, but I don't want to make it less interesting for the people who would enjoy it most. So I guess it's a bit of a trade-off.

Also, I'm mostly a hobbyist dev that works on this part-time, so commercial success isn't my primary goal

[Thaumaturge]

That's fair enough--although I might argue that accessibility isn't just a matter of commercial viability, but also of opening your game to players who might be interested in your game, but who might be tone-deaf, or colourblind, etc.

As to sound, you might be able to make it a little more accessible by marrying the sonic elements with others--having symbols or patterns associated with tones, or associating pitch with the size of some visual effect. Perhaps something might be done with text, similar to the use of images with taste. That said, I'll admit that it's a little synaesthetic in a game like this.

That said, if doing so does go against your design goals, then fair enough--I have no argument with a game that's designed for that specific niche. It might be worth mentioning the sensory requirements when you distribute your game, to reduce the probability of players going in unaware, and being frustrated.

[TonyManfredonia]

Interesting graphic aesthetic! It almost has a cel-shaded style a la Mirror's Edge with gameplay of The Witness or Myst. This is neat!

I'm staying tuned

[RbdJellyfish]

Update 2 (10/30/16): Taste Level

First instance of me getting myself to make a small progress update instead of wracking my head thinking of stuff to write about

Not a lot to update, since I took a bit of a break recently. Did more work on the taste mechanic, including starting the level itself. Here's what the building containing taste puzzles looks like right now:



The player starts at the bottom and works their way to the top, bouncing back and forth between buildings. I've been trying to think of ways to make this area more non-linear (maybe adding optional rooms could help?), but I'm starting to think a more linear progression for this mechanic would be best.

I also tweaked the tubes connected to the ingredient containers to show how everything is connected, hopefully to make learning the mixing mechanic more intuitive. The texture itself is probably temporary; the important part right now is the motion.



My plans right now are to finish at least a gameplay-complete (albeit rough) first-draft of the taste level and move on to a different area and work on other things. Hopefully before Thanksgiving? Maybe I can get family to playtest it

[Thaumaturge]

I've been trying to think of ways to make this area more non-linear (maybe adding optional rooms could help?), but I'm starting to think a more linear progression for this mechanic would be best.

Hmm... If you were to vary the puzzles a bit such that they could be grouped into distinct sets, you might be able to create multiple paths, allowing players to choose according to preference--to choose their preferred "flavour" of this puzzle, so to speak. Off the top of my head, you might have a set that relies heavily on colours, one that relies heavily on shapes, another that features lots of overlapping elements, etc.

[RbdJellyfish]

Update 3 (11/29/16): Baby Steps

Another small update! Mostly I've been spending the past month trying to figure out what to do next.

I made good headway on my taste area prototype, but not really feeling the result so far, so I'm probably going to go back to the drawing board. Right now I'm planning on keeping the taste mechanic itself, but rethinking the level layout and making the taste puzzles more "puzzly". Right now the hard part of the level is understanding what the puzzles are asking for, and actually solving them is way too easy; i.e. the way people need to interact with the mechanics is too confusing, but the puzzles are too obvious once you understand the mechanic. I think I need to think of more unique ways of making the ingredients mix together, as well as think of a better way of representing/teaching the mechanic. The way I teach the mechanic in the level currently doesn't feel right and feels too easy to brute force/breeze through without understanding them, so I have some more design work to do there.

I also revisited the beginning area. I had a couple people play it over Thanksgiving break, and as expected, it's certainly not perfect yet. So I spent the past few days tweaking some things and swapping out puzzles to try to make the logic gates more understandable. I'm still expecting that this iteration is far from perfect, but hopefully it's a step in the right direction

Here's a before and after shot (respectively) of part of the entry area from different angles. The main changes are spreading out and clearly separating the individual puzzles, and also reducing the number of logic gates at play to simplify things. (I also changed the angle of the sun, but don't worry about that)





As for what I'm doing next, I'm still leaning towards tackling the taste area, but if I get bored I'll probably end up somewhere else. The two I kinda feel like working on the most right now are sound and smell.

[RbdJellyfish]

Update 4 (12/17/16): Productivity Upgrade

On Cyber Monday I ordered a bunch of computer parts and built a new desktop! This is a huge step up for me considering I was doing all my dev on a laptop. It no longer takes forever for me to do simple tasks since my workstation is so much more powerful, and as a result I've gotten a huge boost in my motivation and productivity.


Automatically Connected Wires

Speaking of productivity, one of the things that has taken up a lot of my time in level design is connecting all the gates and switches together with wires. Each wire is essentially a bunch of rectangular prisms that are scaled, rotated, and placed to look like they're all connected together. The problem with this was that the wires weren't necessarily grid-aligned, so scaling the wires to connect to each other perfectly took forever (and wires are everywhere in this game). So I wrote some code that would do this for me. Rather than scaling each wire manually, I can place wire stubs at the corners of each wire path, and when the game starts, some math is done to adjust each stub's location and scale to connect itself to the next stub. This allows me to make electronics in levels so much faster.




Restarting the Taste Area

Like I said in my previous post, I wasn't happy with the direction the taste level was going. It felt repetitive and linear, so I started redesigning the level. The image below is what the new level looks like so far from the outside. It'll be growing quite a bit in the future, but so far it looks like it'll be a step in the right direction as far as those two problems are concerned.

The "tutorial" for the area seems like a step in the right direction as well. It's much more difficult to brute-force, and the layout of the puzzle elements telegraphs what you need to do much better than before, I think. We'll see when I have people test it out eventually.




The Hearing Area

The hearing-based area was the second area I prototyped. I had my sister play it, and she had a *really* rough time with it. It was clear I'd made it way too difficult, so I went back and started re-making this area as well. I toned down the difficulty of most of the puzzles, but I also added some variance to them so it doesn't feel like the same thing over and over.

A screenshot doesn't do this area much justice, since it's based on sound... but here's one anyway.




Live Streams

Due to me having a PC that can actually handle doing more than one intensive thing at a time, I started trying some game-dev live streaming. It's been really fun so far! Not only is it fun interacting with the chat, but it also helps with productivity, since I'm less likely to get distracted while people are watching what I'm doing. If you're interested in watching, you should follow me at https://www.twitch.tv/rbdjellyfish. I tend to stream mostly on weekends, but I also stream on weekday night (EST) every so often. Stop by say hi some time! ^{I also speedrun games though sometimes, so sorry if you stop by for game dev and I'm doing that instead...}


Goals

My immediate goals are to finish up the hearing area, fix a couple bugs in the player movement code, and possibly start the save system so I can start integrating the separate levels with the game's central hub. I'll probably also check back in with the taste level every so often, since I've already started it and like where it's going.

Looking at this objectively, I haven't made a ton of progress since the last post, especially not by the standards of people who do game dev full time, but I feel like the quicker rate I'm working at makes finishing this game seem less impossible. I just gotta keep at it bit by bit, and it'll be finished eventually Anyway, I probably won't be making another post until next month at least, so happy holidays!

[Thaumaturge]

Having programmatic generation of those wires seems like a rather good idea; I imagine that it may save quite a bit of time, and be rather less tiresome, too!

I'm curious, if I may: how does the "hearing" puzzle work, and what do you have in mind for the new "taste" level?

[RbdJellyfish]

Having programmatic generation of those wires seems like a rather good idea; I imagine that it may save quite a bit of time, and be rather less tiresome, too!

Yeah, I haven't been using the wire generation stuff for that long and I'm already really liking the results. Not only does it let me connect things faster, but I can make things more visually interesting too by wrapping the wires into different shapes and stuff if I want without it taking forever.

I'm curious, if I may: how does the "hearing" puzzle workand what do you have in mind for the new "taste" level?

In the beginning of the area, you encounter a bunch of devices with buttons and lights on them. A sequence of sounds play and the lights that match up with each sound blink at the same time, and you have to match the sequence by pressing the corresponding buttons in the correct order. After a couple of these, you start to encounter devices with broken lights, so you have to figure out the sequence based purely on the sound they make. There are a few twists on this along the way, but that's the main premise. The main difficulty changes I made in the new version of the level (other than just layout) included reducing the length of most of the sequences, changing the number of buttons/lights from 4 to 3 on a vast majority of them, and reducing the number of puzzles to make it less tedious. The main difficulty still probably lies in the fact that most of the puzzles are pitch-based, but I'm hoping make them less difficult in other ways (changing the number of pitches from 4 to 3 definitely helps that). If it's still too difficult I'll reduce the big pitch-recognition requirement.

and what do you have in mind for the new "taste" level?

For the taste area, I'm keeping the mechanic I'd introduced in an earlier post (for now, can't guarantee they'll be around forever) but making big changes to the level they're placed in, which you can probably see in the screenshots. In the original area, the outside of the structure looked interesting, but inside, every floor looked the same, and the only differences were the tastes that popped up when you interacted with the food. It all just felt the same visually, even as you got further and further in. So right now I've been building the puzzles first and sort of constructing the level around them, which is leading towards something that looks more varied both on the inside and the outside. Even if I keep the linear flow of the puzzles, the level itself should end up being more fun to explore. There's also a good chance I'll take your advice and give people the choice of which types of puzzles they want to finish to progress, especially if there's color involved at some point!

As for the tutorial that I mentioned: originally, everything was placed in the same room with equal importance; the food you're required to match, the current mixture, and the three ingredients were all placed front and center in the first room. Not to mention there were only 3 ingredients to choose from. After putting the tutorial together, I immediately envisioned people going straight for the buttons on the ingredient tubes, pressing a bunch randomly, and having the door open without even trying any ingredients. Which would be bad.

So first thing I did was add more ingredients. Now there are 6, which increases the number of food combinations from 8 to 64 (still brute-forcible, but not nearly as easy to get accidentally). I also placed the required food dead center in front of the doorway you walk through, such that it's the only thing you'll see as you walk in, because I want that to be the first thing people interact with. The next closest thing to you is the current mixture (which at the time will be empty), with a wire connected to the set of ingredients, which are kinda in a sub-room off to the right. Another thing I did was have the buttons on the ingredients pointing away from the player as they're approaching them, so they'll maybe be more likely to try clicking the food and seeing the effects instead of the buttons first.

That said, haven't actually tested its effectiveness yet. But here's a top-down view (with some notes).

[Thaumaturge]

Ah, I see--interesting, and thank you for elaborating. ^_^

I like the changes that you describe for the tutorial to your "taste" puzzles; while--as you say--testing is still called for, the reasoning that you give makes sense to me. (... Pun not intended, but gladly taken. ) I'm a little concerned about the interior wall obscuring line-of sight to the results of a given selection, and about players ending up going back and forth between "mixture" and "ingredients", which I imagine as potentially a little tedious.

Hmm... I suspect that, for myself and speaking as a player, I might avoid this game due to the sound puzzles--they seem like the sort that I'd find unpleasant and frustrating. ^^;

That said, I still find this project rather interesting as a developer, so I intend to stick around in this thread! ^_^

[RbdJellyfish]

Good points about the taste problems. Right now the inner window and the direction the buttons on the ingredients are facing fixes the line of sight problem, at least for the tutorial. If anything I'll probably make the window a little bigger so you can see what happens when you press the buttons. For the tedium, I'll probably fix this at least a little by putting the ingredients closer to the mixture in later puzzles. The tastes used in the tutorial are probably clear enough that once the player understands it, there won't be too much running back and forth required, so the distance/wall blocking the path between them shouldn't be too much of a problem.

As for the sound problems, that's fair! I hope you'll keep an open mind as time goes on, especially since this is still at a point where I'm willing to scrap major portions and start over. If I continue on this path and don't see any improvements, I'm still open to making it non-pitch based. I've just seen a lot of the negative criticism regarding sound puzzles in games like The Witness and Myst, and I'm doing my best to remove the annoyances people had with those while purely keeping sound as the main mechanic. For example, in The Witness (if you've played it), some of the problems included:
  - The pitch of bird chirping being unclear due to bird sounds not being completely tonal, or the pitches being too close together
  - The player not receiving any feedback from the solution they would input, other than it being "right" or "wrong" (e.g. the line they drew wasn't "played back" in any aural way, so it was hard to figure out why a wrong answer was wrong)
  - The one most people had trouble with was mostly due to 2 sounds playing at once, and one of them playing its pitches very fast. Pretty much, it was intentionally made unclear.

And in Myst:
  - Adjusting some sliders to change pitches with half-step resolution and trying to match that up with notes played on a piano was kinda crazy if you weren't musically trained
  - People brute-forced the sound maze because they didn't realize the sounds were relevant, not because they couldn't hear correctly

So yeah, hopefully I can figure out ways to fix all of those. I'm sure that's not all, though, so I'd appreciate hearing (oh god another pun) about any other difficulties people have with sound puzzles so I know what to try to avoid! Other than just being straight up tone-deaf, which I'm still considering the best way to address while maintaining my vision.

Also, thank you for the support I'm glad you find it interesting.

[Thaumaturge]

My pleasure! ^_^

Don't worry--while I doubt that the game is a fit for me as a player right now, I imagine that I'm not likely to simply ignore any changes that you make as you go.

I haven't played The Witness (although I have seen let's plays of at least part of it), but I have played Myst. I didn't like the "piano" puzzle that you described, although given what you've said, I don't know how much of that is because I'm simply not musically-trained, and how much because I'm generally not great at that sort of sound puzzle.

However, I seem to recall that I did like the sound puzzles in the region that it led to. In all fairness, it's been long enough since I first completed that section that I don't recall how I completed the maze that first time--perhaps I did brute-force it somehow. Still, the "tower" puzzles were fairly straightforward and enjoyable, I think, although they may have called for a bit of running around.

[RbdJellyfish]

Update 5 (1/18/17): Hearing area is almost done

Back from break. I've been working on the hearing area a whole lot lately, and I think it's pretty close to being gameplay complete. I tested it with family (some who are musically inclined and some who are not), and watching them play through it gave me a lot of faith in this iteration of the area. The flow and overall difficulty curve seemed pretty good, and the twists in the area seemed to be introduced at just the right intervals to give the best effect. Unfortunately, family is just a limited audience, but I'll be really happy if their experience is shared among others when I show the game to the general public

Sound Mazes

There were two somewhat technically intensive areas in the level, both being mazes that you work your way through by listening to audio cues. Like I mentioned in a previous post, one of the problems with Myst's sound maze puzzle was that people brute forced it before they could actually figure out the clues behind it. So to avoid this problem, one thing I did was telegraph that the sound corresponds to a direction in a more clear way by tying them to floor panels with arrows on them. Early in the maze, the correct direction lights up along with the sound, but after a few intersections, only the sound will play, so you have to trust your ears instead of your eyes.

But still, I felt the maze was too brute-forcible; if you choose the wrong direction and hit a dead end, it's so easy to just turn back and choose a different direction. Then I remembered I had that portal mechanic I worked on forever ago, and started placing those at the dead ends to link people back to the beginning of the maze. If I can tweak the effect and make it as subtle as possible, it's going to send people in circles unless they really know what they're doing :D

I hit a real snag in this area, because originally, I was trying to render every portal's camera to the same scene capture texture, so for the longest time I thought my portals were wrong because I had the camera's offset relative to the player wrong  or something. But nope, ended up just having to disable/re-enable portals that weren't/were nearby so they didn't all try to overwrite each other while rendering to the portal material. So now the maze is filled with a mess of trigger boxes that selectively activate/deactivate the portals in the maze, but that's okay by me if it works. Which it does. For now.

There's also another maze of similar nature in the area, but rather than using walls/dead-end portals, it takes place on a grid in a pitch black room. If you step on a tile out of order, the lights shut off and you teleport back to the beginning. To make this one non-brute forcible, I decided to make it procedurally generated, so you can't just iteratively memorize a good path through the maze. That one was actually pretty fun to implement.



Monthly Dose of Tutorial Woes

Big shocker, the updated tutorial was still bad. So I rearranged a good chunk of it again to place emphasis on the right things. Probably going to refrain from saying what I changed until I'm sure I have it right, so I can make a big post about all the different iterations of it, but here's a screenshot.



Anyway, with the hearing area nearing completion, I might start combining things into the same central map and start working on level streaming/the save system. Will be cool to start tying different pieces of the game together. See you later.

[Thaumaturge]

An interesting update!

I'm glad to read that the "hearing" section seems to be coming along well. ^_^

I rather like your ideas for prevention of brute-forcing; those portals seem particularly cunning! I also like that you're essentially providing a tutorial at the start of one of the mazes (the first, I presume): That should, hopefully, give players a bit of direction regarding what they're supposed to do.

[RbdJellyfish]

Update 6 (2/28/17): Tutorial Iteration

Long post incoming.

I may have finally done the tutorial right.

I did some play testing last weekend, and I learned that the latest iteration of the intro tutorial area finally seems promising. Only took, like, a million tries. So for this post, I'm going to do an analysis on each iteration of the tutorial area, and point out what works/doesn't work about each one.

Iteration 1: Not teaching enough. My first iteration of the tutorial area was super simplistic. Basically, it taught you how to run, jump, and press buttons to open doors. The problem wasn't necessarily that it was ineffective at teaching those things; in fact it was probably fine at the time. But this was before I decided to make logic gates a sort of universal thing throughout the game, so I realized setting the player loose without introducing them to those a bit would have been a mistake.
 
Iteration 2: Trying to teach too much. So, next iteration I added logic gate puzzles involving buttons wired through digital circuits to open doors. The problem was that I added all of them at once into a very small section (iirc, I was introducing 5 logic gates and 2 button types within the span of ~10 very small puzzles). The main problem here was that the player was overwhelmed with the amount of new things introduced, so they either didn't learn anything in the first place/brute forced their way through the area, or they failed to retain any knowledge gained once they'd actually left the area. Overall, I realized I needed to reduce the amount I was introducing to the player from the start.

Iteration 3: Not actually teaching. I went down from 5 gates/2 buttons to 3 gates/1 button in this iteration, and I made the puzzles smaller to focus on highlighting the function of each gate. I was hoping this way, the new knowledge would stick much better in the players' head. Well, this backfired, because making the puzzles smaller made brute forcing even easier. No one who I playtested with felt the need to understand how the gates worked; all they cared about was opening the door across the room by lighting up wires, and once they did that, they considered it solved, whether they understood why or not.

After these 3 iterations, it seemed the main problems were introducing too much too fast and allowing the player to progress despite not fully understanding why.

Iteration 4: Bingo. This iteration is the one that seems to work so far. I simplified the area even further and decided to only introduce two of the simplest logic gates: AND and NOT. The player is also pretty much required to pay attention to what's happening, otherwise they'll have a difficult time progressing. The tutorial plays like so:

1. First thing you learn is the controls. You start out in front of a button with a picture of a left mouse button; if you click the button, the door opens and you can walk outside. After opening another door, you learn how to jump, which you can use to get over a few boxes in the way.

2. Next, you're introduced to AND gates. These are pretty easy to understand; if you press all the buttons connected to them, the door they're connected to opens. After activating an AND gate to open a door, you're required to activate 3 AND gates chained together.



One of the inputs of one of these AND gates is actually on the other side of the wall, so you have to do some backtracking to fully activate it and open the door (assuming you haven't already explored the area and pressed the hidden button). This is meant to teach you that exploring can be beneficial when you can't proceed, and following wires is a good idea when you're trying to find the source of power for something.

3. Next is the NOT gate tutorial. My goal here was to make people focus on what the NOT gate is doing, instead of focusing purely on opening another door. So to do this, I try to trick people into turning a NOT gate off, blocking their progress, until they realize that they need to undo one of their button presses.

At this point, you have a 100% success rate with pressing buttons; every button you press leads at least partially to an open door. So, when you enter this area, if the first and only thing that is visible to you is a button, my guess is that most people will instinctively press it (the 4 people I playtested with did in fact do this). However, hidden behind a pillar is a NOT gate, which this button feeds into. So, if you press the button, you'll actually cut off power to the door you need to get past. In order to progress, you'll then need to find the source of the problem and realize you need to turn the button off to turn the NOT gate on. Here's a gif of the area in action.

4. This is followed by 3 other puzzles with 6-8 inputs each that include both NOT gates and AND gates. Unlike previous puzzles, these aren't so easy to brute force, and they do a good job of highlighting the functions of the two gates.

Overall, massive improvement over previous iterations. It forces you to pay attention to things, gives you puzzles that are actually fun to solve, and leaves you with a solid understanding of the game mechanics after you've made it through the area. I may return to this area and tweak it (might change the last two puzzles a bit, or add another for fun), but I'm happy that I've made a breakthrough with it.

One problem with the area is that it still leaves 3 gates and a button type un-taught. I have a couple theories about how this will play out - one is that I can just introduce these mechanics in the areas they're required a little later on in the game. One problem with this is that the game is open world, and I don't want to have to have multiple tutorial sequences of the same mechanics if the mechanics are required in more than one area, and I don't want to block off areas until you've found the one with the tutorial, because I want to encourage exploration. So this would be less than ideal.

My second theory is that I won't actually need to explicitly teach these mechanics. Some of the gates work intuitively enough that the function can be deduced just by looking at them. There's a good chance that the intro area will have taught people that paying attention to the gates themselves is a good idea, so if people encounter a new gate, they may be motivated to figure out what it does. I may be making some bad assumptions, though, considering iterations 2 and 3 of the intro area...

Anyway, that got pretty ramble-y. I did a bunch of other stuff since my last post, but I think I'll just wait until next time to post about it See you next time!