AI Test #1123
Genre: Puzzle, Adventure
Project Role: Solo Developer
Engine: Unreal 4.25.3
What is it?
“AI Test #1123” is a 3D puzzle game where the player plays as a robot navigating a test facility for artificial intelligence.
The robot’s goal is to reach the final chamber in the facility successfully.
This project is available as a free download here.
Thanks to my research into the previously mentioned references, I went into this project knowing that I wanted to make a 3D puzzle game, with a tone between Portal 2 and a standard dungeon like you might find in Legend of Zelda.
To that end, I utilized the “Advanced Puzzle Constructor” kit available on the Epic Store, made by Andrey Harchenko to develop the puzzles and the environment itself. I also used the animations that were already in this kit. However, I didn’t want to use “Manny”, but, instead, wanted the character to be less interesting so the player could focus on the environment and the puzzles more. With that in mind, I used the “Sci Fi Robot” asset, also available on the Epic Store, but made by Dspazio.
Another reason for my using the assets is that, when I got them, they were on the Epic Store’s “Free for the Month” list, so I didn’t need to spend any money to create this project.
When I started planning out the cadences and pacing of the project, it originally had 5 test chambers. However, I cut two of them to keep in line with the traditional “rule of threes” commonly found in adventure games. Another reason for cutting the two chambers is that I realized that would make the difficulty curve either too shallow or the endgame would be far too difficult and time consuming to test with playtesters. My goal for this project was to make sure that the tone of each room would be darker and more intense as the player progressed through the dungeon, and if there were 5 rooms, then the last room would be too dark. On the other hand, it’s possible that the change wouldn’t be as obvious as I would have liked.
While I was still planning each section, I only whiteboxed the structure, and didn’t actually bring the puzzles into the respective sections until the actual structure was completed. Once the structure was completed, I brought the puzzles that had been prototyped on paper up to this point, into the level and tested it again to make sure that the puzzles were both interesting and possible.
As I progressed through the project, I only planned one section ahead, to make sure that if I needed to do a total redesign, it would be less overall work, and much easier to rethink the current progress of the project. This also made it much easier to cut content or completely reformat sections of the project to accommodate various changes to the level architecture.
Because my main goal for this project was to create a “dungeon” for an adventure game, I focused my puzzle designs around what is typically found in adventure games: block puzzles, switches, and different types of doors. With that in mind, I designed all of the puzzles around blocks of different types, corresponding buttons for those blocks, switches, and different types of doors (laser walls and doors).
One of my biggest considerations for this project was to give the player the controls, but not explicitly tell them how to solve the various puzzles. Because I didn’t tell the players how to solve the puzzles, I needed to make sure that, at least while they’re learning the various components, failure was as impossible as possible. To accommodate that, I started with a single block, and a matching button, then progressed from there. Whenever I introduced a new component, I worked to make sure that it could be used on its own, without requiring the player to use it in tandem with another previously introduced component.
As you can see to the left, the various components come together in a complementary fashion. With each new component adding a new layer of complexity, the player isn't overloaded with new content at any one time.
I followed this same pattern throughout the rest of the section, and after this, everything that the player needed to know has been introduced and they have successfully completed the various objectives. At that point, I increased the difficulty level per section, to further test and reinforce the various concepts, and to force the player to be more flexible in their thinking.
During my work on this project, I found that the kit I was using for the mechanics themselves had several issues, that I needed to either fix because they didn’t work correctly, or that I wanted to behave differently. Because of this, I spent a great deal of time in the beginning delving into the blueprints to learn how everything was put together, so I could at least have an idea of where to look for various things later.
As time went on, there were various things about the project that I needed to change, such as the behaviours of some of the platforms, as well as fixing inefficiencies in the blueprints themselves to improve the framerate and gameplay experience.
Most of the fixes that were needed were either on the player character itself, or on the extra pieces that served as part of the environment. I removed the telekinetic gun that the player character had initially, as well as improved the efficiency of the function calls, as there was a lot more redundancy than was needed that was just never reached under any circumstance. The fans were also a major drain on the efficiency of the project as well, as they were calling the same function 10-30 times a second, when it was only needed once, when the project was actually started.
Light as Guidance
One of my primary goals in this project was to learn more and experiment with utilizing light as a form of guidance for players, the results of which can be seen to the right. To effectively guide the player, I primarily used three methods:
Spotlighting: shining a spotlight on the target object or in a target direction
Teasing: putting a light around a corner so the shadow points to where the target object is located
Guiding: lights on the side of the path to further encourage the player to move in the target direction
I used spotlighting to highlight a goal, a door, for example, and to use the sight lines formed by the edge of the light’s cone to guide the player in a target direction, as can be seen in the images below.
I used teasing to great effect several times throughout the project, with players just moving in that direction, driven by their reported curiosity about what was around the corner. Having the light around a corner from the player’s location created a clear line between the light and the shadow, which served as another guiding line for the player.
Guiding lights were used throughout the project to enforce the player moving in a given direction, and keeping focused on whatever the task at hand was.
Each time I finished a section of the project, I started a new playtesting session to test that iteration of the project. The goal of each session was to determine what, if any, bugs were present, how the difficulty curve was moving along, and to determine what, if any, quality of life adjustments needed to be made.
One aspect that is, and was, important to me during these sessions was the accessibility of the game, and so, I kept the gameplay controls as simple as I possibly could, while keeping them intuitive for new and experienced players alike.
Another aspect that is, and was, important to me is ensuring that the feeling and tone of the project progressed in a way that made sense, with it getting darker and more intense as the player progressed through the game. With the shift in tone, I also increased the difficulty of the game, to match where I expected the player to be skill and knowledge-wise.
If I had any doubts about either of those aspects, I made sure to make a note of it and paid extra attention while the player was in those sections to check whether or not my doubts were well-founded.
Quality of Life Adjustments
There were four major quality of life notes from my playtesting sessions: climbing ladders was slow, the charge blocks charged way too slowly, some of the noises were really loud (especially when there were multiple sources near each other), and it was too dark sometimes.
The speed of climbing ladders was controlled through the speed of the associated animations, so I ended up doing a lot of experimentation on the speed of each of the animations. Through this, I was able to learn a bit more about the animation systems, which was very helpful in debugging some of the bugs that ended up popping up in playtesting. By the time I was satisfied, I had tripled the character’s climbing speed from its original value, to be more in line with what you would find in an adventure game.
The charge block’s charge speed was controlled through a value in its blueprint, and was done in a way that the block would charge a set value over X time, so I ended up drastically increasing that speed as well. In hindsight, I probably could have just removed it from the project entirely, as it was only used once, and was more of a mild inconvenience than an actual puzzle element.
As far as the sound effect volumes were concerned, I reduced their volumes through the cues, and added modulators to the sound effects that were particularly repetitive to decrease the fatigue the player experienced from hearing the same sound over and over.
To address the darkness issue, I added ambient lighting to the world through the post process volume, and added a slight blue-green tint to add more flavor to the player’s experience, instead of everything just being lit with a default white.
Second, Third, Polish Passes
As I went through each playtest session, I made sure to take note of whatever bugs, difficulty spikes, or spots where players reported being bored or that the puzzle felt tedious. After I had completed a satisfactory number of playtests for that iteration, I dived back into the project to attempt to resolve each issue to the best of my ability.
If the issue was a bug, I would attempt to recreate the bug, and research similar issues. If I could fix it myself, I did; if not, I asked for help from programmers who were skilled in that particular field, and they would help me fix it and understand why it would happen, so I could avoid the issue in the future, or fix it myself in the future.
For difficulty spikes, I re-evaluated the area where the spike occurred, and would redesign it to have a simpler solution, or, as was the case several times, design it to have more possible solutions.
I followed a similar tack when resolving spots where players reported being bored or feeling that the puzzle was tedious. Sometimes, the solution was just to remove a block or two from the puzzle; however, sometimes it required me to completely redesign the puzzle, and try a different style of puzzle altogether.
Once each issue was addressed, I made a note of it, and marked it for my next playtest session to make sure that the issue was actually resolved, and that I didn’t introduce a new issue. If the issue was resolved, and that area could be deemed “complete”, then I went through and added in props and other polishing touches, such as finishing the lighting and reflection builds for that area.
What went wrong?
Because I was limited to what textures I could use, some areas of the project show that it is the same or similar textures tiled next to each other, making the environment look repetitive and less interesting in those areas as a result. Additionally, there were still some bugs that were beyond my technical ability to fix or work around, but they’re not consistent, which makes it difficult to track down the causes of each bug.
What went right?
I was able to create an interesting and engaging environment, with limited resources and intuitive mechanics that quickly and easily build on each other in an interesting but logical way. The architecture of the space added to the puzzle’s interest, and focused the player’s attention, as well as attaining the effect I was aiming for: a “dungeon” that could be found in a much larger game, but can also stand alone as its own entity.