Project WAM Part 2: Getting Farther, Planning my Proof of Concept Interactive Demo, and Staying Strong

Hello! My name is Earvin Ramos and I’m an amateur independent developer looking for work. I’m currently taking ideas and trying to expand my portfolio with more works, with this project being the first.

The project is swimming along, with me spending a few burst of hours at a time programming new features and refining old ones. Since my last post, I’ve worked on quite a bit to get the survival horror aesthetic further in the project, and finished the rough workings of the biggest key features: ENVIRONMENT INSPECTION! INVENTORY SYSTEMS! OPENING LOCKED DOORS!

Cue the trumpets and laud the coding spirits that pushed me to finish: I now have a working and easily customizable way to let users inspect and examine items in the environment a la Resident Evil. I set an array of strings that represent the different lines of text, and UI widget comes up and displays them in order. Users can press the interaction button to speed through text and end it quickly.

Another key feature! Cue more trumpets and laud the sleep deprivation spirits that pushed me to finish:  I now have a working and easily customizable inventory system that allows me to place models in the space and attach a component to whatever Actor I choose. Inventory is kept on a persistent actor called the “Inventory Handler,” and has a UI attached to Use, Examine and in a future update combine compatible items.

An unbelievable THIRD FEATURE! Cue even more trumpets and laud the caffeine spirits that pushed me to finish: You can now keep items in your inventory and use them in specific places. On the case of the test map, this is using the specific keys on the main “door” in the area. Once the key is registered as “used,” it checks if it has any more potential use (controlled by an integer variable on a persistent actor). If it is no longer relevant, it prompts you to discard.

A lot of features have gone into this build, enough so that I’m going to only show off a few in this post. On top of that if I explain the entire BP for all of them I’ll spend days writing this, so I’ll just share screens of the BPs and give general explanations of them. All of them I’ve, again, implemented myself using Unreal’s official documentation and training on Youtube, as well as a mix of other tutorials on Youtube from various content creators.

Expanding Features, Making a Game

Expanding past movement and cameras was a huge deal towards actually giving the player something to do. Being able to interact with them instantly turns them game from just a walking simulator to something a bit meatier. Part of this is being able to walk up to an object and inspect it. This is controlled through UE’s Slate/Widget system in my game. All text is displayed in what I like to call a “typewriter” style, in which the message is displayed character by character until the message is complete. This is a classic portion of the overall survival horror experience I’m looking it, with it, of course, being a reference to Resident Evil. Here’s what it looks like in-game:

ENVIRONMENT INSPECTION DAY

4e4b857818d5b6ae9694337f39f95ea6

Not too fancy, not too shabby! The game of course pauses while you inspect as I’m planning combat gameplay into the game and don’t want to punish players for accidentally inspecting things.

Aside from the programming of the widget itself, here’s the BP behind what is powering this. You can’t see it in the above screen, but each of the towers has its own inspection pattern with different inspection text (one has 1 line, one has 2, and the one has 4). The character presses the interaction button (Left Mouse in my case) and a raycast happens. If the raycast hits an object, it polls it for anything that is a child of a custom “Master Interaction” actor component class and executes the Master Interaction event coded into it. If it doesn’t have one, it doesn’t do anything. Thus, all interactions that will require a click will be an addable component that is a child of Master Interaction. Thus, the tower’s Inspection Interaction component is pulled up and it pulls a Master Interact event in its BP that creates the widget and controls the display of text. Here’s what that BP looks like:

efd4cdcfcca3f47505d4200c3c06f0a0

Investigation Start is the function on the Investigation Handler that generates text. The String Array that contains all the inspection text, in line-by-line array format, is housed on the component. Current Array is the line it is displaying. I also used interfaces to allow the player to interrupt the typewriter text widget and skip to the end, then a finish function to allow them to stop the text, continue to the next line, etc. Most noteable is that each line becomes its own widget, it clears from the parent when it is finished, and a new line is a new widget.

ITEMS and INVENTORY

Of course, one of the largest and most important defining characteristics of Survival Horror is inventory management. This puts the pressure on the player to pick and choose the items they pick up: Do they take more healing items? Do their take key items with them to progress in the setting? Do they pack on the weapons and ammo to take down enemies? Balancing all 3 is pivotal to the Survival Horror experience, and I’ve taken steps to capture that!

a6d1e430ffa64806ea695ec6381de777

All items in the game again use the same parent-child system that I implemented into the interaction components. The same objective exists: all items will contain similar properties, and I don’t want to have to recreate each property for each item. All item interactions will have the same expectations for each class, so having them all be children of a Master Item (at the bottom of that screen) means that they all have the same expectations and I can code their interactions easily instead of having to do them on a per-item basis.

The Inventory Actor contains everything needed to run an inventory system. It has functions to add, remove, search for empty slots, and update inventory. What’s even better is that the inventory is an array of item slots, so all of the features of older inventory systems (using an item and having other items go up a slot, adding items to slots at the end, etc.) work without having to force functionality.

Another beauty is of course, the Item Interaction Component. As another child of the Master Interaction, it allows me to add a blip that brings the player to the menu, asking them if they want to put an item into their inventory. It ends up looking like this:

1b5ed56596d492d92fdac0167406d93e

Once the player clicks yes, the item is added to the inventory and the world actor is destroyed, allowing me to place items and control how the user gets future ammo, healing items, key items, etc. Once I have art assets and data, I can implement items rapidly and quickly, and use them meaningfully in the environment.

REAL FAKE DOORS

Next is one of the most pivotal parts: doors. Locking off doors helps control pacing in a Survival Horror game, and controls the overall flow and route of the game. Locking a door and having its key be all the way on the other side of the building is powerful, and encourages the player to explore. Encountering a locked door signals to the player that they need to actively search the environment for a key, which adds to their immersion.

Doors work two-fold in my implementation. First, there is the Door itself which is part of a Door Component. Again, anything that will be interactive in the game will have a component that will guide Unreal in what to execute off that interaction. An interacted unlocked door will (after implementation) lead to a door transition and lead to a new area. An interacted locked door, however, is the beauty of the system. After checking if the door is locked or not, the system checks against a list of “Key Items” that unlock it. In the case of the door in my Test Map, it requires 3 keys. It scans the player’s inventory and checks each slot to see if it matches any of the key items. If it doesn’t find a match, it will create a UI widget that will show text as to what is needed to unlock the door. If it does, it auto-uses the key (Again, important to Survival Horror smooth gameplay). Also, something implemented that ISN’T in Resident Evil, you can directly select a key from your inventory and use it. If the system recognizes an object in front of you with a door component, it allows you to use it. Here’s what it looks like in action:

010db146478d99d7b1499acb09a70973

One the key is used, it removed the key from the inventory AND from the door’s list of needed keys. After the keys are all used, the door is considered “unlocked.” Another persistent actor controls all of this: the Door Handler. The Door Handler has a list of doors that are in the game (expandable) and their locked/unlocked status. Beyond this, I need to implement a list of each key required by locked doors (most likely a clone of its needed keys array), and I can pave the way for multi-room settings and door sharing the same data on both sides of the door. Key also have a usage counter, and when key uses are met it will prompt the user to choose to discard or keep the key.

What It Looks Like All Together

Although from a few builds back, here’s what this looks like implemented and working:

This should cover in-game play of all the features above! The only thing I forgot to show off was the locked door message that states what keys the door needs.

It’s been a long road, but so far I’m proud of the features I’ve implemented! A lot of the BPs need to be cleaned up and made legible to people who aren’t me, but I feel comfortable in my implementations and am ready to move forward.

Planning the Proof of Concept

Next is turning this all into a Proof of Concept that I’m using as both a portfolio piece and as a way to push the game to key people and those who might want to volunteer some help in the development process. The POC is going to cover a few concepts I want to push:

  1. The distinct artstyle: Though all assets are so far in prototype quality stages, the artstyle I’m planning is quite distinct. Put simply, it’s going to be a live-rendered version of the pre-rendered games of yore. The foreground characters, items, and player/enemy models are all going to be low poly (sub500 quads most likely) with well-painted textures. Background scenery is going completely high poly (within reason) and flush with detail. This will create a distinct background-foreground contrast that made old Survival Horror so unique
  2. The time-tested gameplay: Again, old Survival Horror has a unique playstyle and feel that is basically gone from modern game development. Searching for items, deciding what to keep and what not to keep in your inventory, navigating tight areas filled with dangerous monsters, these concepts are considered dry and hard to plan. We’re lucky we got RE7 to do it as much as it did, but even then it feels “new.” I want this game to feel “old”
  3. Sound design and music: I have plans for a concept style of sound that hopefully will be an improvement on old Survival Horror, but I also want to compose music that will be evocative of past titles. Less nostalgia than the other concepts though, I want the music to be familiar but entirely unique. This will explore using FMOD further and will prep me for complete middleware mastery.
  4. Making a statement: I want the game’s storylines to be powerful and meaningful, that pushes boundaries and brings up philosophical and moral issues that trouble us.

So far the POC itself will be 4 rooms, 1 being the main hub with 3 puzzle rooms. All items, puzzles, and environment and design will be evocative of the first planned Act of the game. The next strides I need to make will be

  1. Finishing Push-Block puzzle functionality (not too hard)
  2. Finishing Switch puzzle functionality (it’s there, just gotta implement and test it)
  3. Finishing save data and recordkeeping functionality (a bit more difficult, I have to implement a few things)
  4. Make rough prototype assets for all puzzles (the biggest chunk of work)

After I get the POC going with prototype assets, I’m going to focus on getting some first-pass assets done and will open up the demo to more people and will be a decent portfolio piece.

Staying Strong

My life is starting to spin again, and over the next couple of months I’m going to focus on finishing this as much as possible and trying to push more applications out for positions. Though the horizon seems a bit uncertain for me, I need to focus on staying strong and pushing to finish more work to show off my abilities more and more.

Also, bonus! Here’s a sneak peak of a first-pass asset I made that I may implement into the first-pass POC:

It’s a door! With HANDLES! It’s a nostalgia bomb to Resident Evil, and I hope it’s one of the core visual keys that will guide the overall style of the game. Seeing these assets, which of course I modeled, UV’d, and painted myself, is helping me stay strong. Seeing what I’m creating come to life is a wonderful feeling, one I wouldn’t trade for the world.