Into the ei'tu
-
Project Status: Completed
-
Project Type: Personal
-
Project Duration: 1 week
-
Software Used: Unreal
-
Languages Used: Blueprints
-
Primary Role(s): Designer / Scripter
About into the ei'tu
Into The Ei'tu is a third person puzzle narrative game that was made for a game development class I took in university called Game Level Design. This particular assignment was quite interesting as we were given level builds and themes from other designers in our class and had use their themes and build to make a level that fits their game's original themes and intention. The one I got was a game that had the theme of love and season which made me go the narrative puzzle route. This project helped teach me not only how to be adaptive when it comes to designing and coming up with compelling gameplay with a pre-existing game/ prototype but also made me learn how to be able use an existing piece of code and expand upon it to fit my needs
gameplay mechanics
Narrative puzzles
The player could press the E key to interact with puzzle pieces through the game level/ environment in order to solve them or clear them. The game also included internal monologue by the character when he's near a puzzle piece to let player's now that something might be worth checking out:
The intent of the game's puzzle was to not only be a fun challenge that players would need to solve in order to advance, but I also wanted to tell the game's story and world that they were in without the use of long lines of text. My solution was to include them in the puzzles. The puzzles had elements that showed the alien language that the world the character was in had with internal monologue that helped enforce that sense of unfamiliarity and fear of the current environment the character was in. Each puzzle had a clue to what the player was somewhat supposed to do in order to help solve it.
The idea for that came in playtesting the game where previously I just had the item be highlighted by using a blueprint to make them glow which didn't really help with how the level was structured. Most of the playtesters didn't know what needs to be picked up in which order in order to solve a puzzle they want and it became a mess. So, I decided to just program in a simple monologue that pops up on screen that hints at the solution for the players, alongside the narrative elements like a video player as a placeholder for flashbacks, that I wanted into the simple puzzle blueprint the level build already had.
​
(P.S. the video player thing is at the Memory 2 part. I had to black out the video cause I used a placeholder from a popular tv show and got in trouble for it when I first posted it here. My apologies for that)
Player Inventory
The player is able to interact and pick up items in the game environment and it would store in their inventory. This would then later allow for certain puzzles to activate as it needs a particular item to do so. This was implemented and programmed from a basic interact with item function the build given to me already had:
Originally, I did not even think that the game needed an inventory system. I felt like it was necessary in the beginning cause the puzzles were simple enough at first and there were very few items that the players need to pick up and interact with. But, after playing the level myself and playtesting it, the first iteration of the game without an inventory system made for a very basic and boring player and gameplay experience as puzzles are doomed to just be as simple as possible to avoid the need for it. I wanted the game to be engaging and the puzzles to be complex with the need for players to go back and forth to complete one thing first and then coming back here to complete a puzzle. I also wanted the game to allow for players to explore the level and interact with whatever item first and do certain puzzles in whichever order they want, as this was massive feedback that I also received from playtesting. By having the game just have simple puzzles that need to be solved in a particular order, the game was very short and boring to play after a while.
With that in mind, I got to work on expanding the Interact function the game already had and just implement a very rudimentary inventory system into the game that would be able to keep track of items well and not conflict with one another when they are multiple items on a player at one time which caused errors where some puzzles would not work because an item had to be in a particular order on the list for it all to work, back with the old basic item interact function. This was a bit complicated for me to figure out how to do but I managed it and even put in a simple UI list inventory thing on the side of their HUD as a placeholder for a inventory UI to let players know that item has indeed been added into their inventory.
Event sequences
The game has a event manager (all though not perfect) that keep tracks and enables certain puzzles and interactions for the player when they have either completed a particular puzzle or picked up a certain item:
This event sequence manager was expanded from a simple and rudimentary IF ELSE check that the build already had programmed into the item interaction and base puzzles. I decided to make it into a manager and more global to the game because I had a lot of puzzles and checks to do. Doing it all in each individual puzzle got real confusing and complicated for real quick. A lot things did not respond with weird errors popping up during runtime. Therefore, I decided to just make a very basic event manager that just looks for the item in the player inventory and check if it's there.
I decided to put the manager in the player controller blueprint instead of the level blueprint because of time as I was running out of time and my class deadline was fast approaching. I could put it into the level blueprint and make it work that way, but since I'm not a programmer by trade, it would take me quite long to figure out how to do that and I already knew how to put that manager into the player controller and make it properly work the way I want from previous projects I did. So, I just decided to go with that solution for this game as I just needed to show a working prototype for the class that gets the idea of what I want the game to be across well.