Screen Shot Saturday & Devlog - October 17, 2020

This was a challenging week. Several team members had personal and/or work issues that made it difficult to spend much time working on the game. We still managed to get some important infrastructure work done, though.

Tutorial System

Probably the biggest feature we’ve added since our last DevLog is a tutorial system driven by a data table. Tutorial steps are displayed in the HUD, prompted either by trigger volumes inside the level, dialogue choices, or other actions, such as completing quests.

Much like the message system we discussed last week, the tutorial system works off of a message queue, but it’s a simpler implementation. One of the nice features we worked into the tutorial system is customization based on the input type you’re using. Whether you’re using keyboard and mouse, or a gamepad, you’ll get appropriate icons and instructions for the way you’re playing. If you pick up a game pad while the tutorial message is on screen, it will automatically update and replace the existing keyboard and mouse icon and instructions with gamepad icons and instructions.

Mannequin Replacement for the Player

As you can see from the screenshots above, we also replaced the Epic Mannequin for the player character. This isn’t the final model — it’s a marketplace asset we’re using — but it’s closer to what we hope to have in the final game and helps a bit with immersion. The model is somewhat customizable and has several hair options, so we’re also using the same model as a proxy for the female NPCs.

Cheat Manager

A cheat manager may not seem like an important bit of early infrastructure, but it really is. When playtesting and debugging, you end up re-playing the same portions of the game over and over. If you have a bug in the third or fourth quest in a quest chain, that means you have to do all of them each time to reproduce the bug and test your fix.

Enter the cheat manager. We added the ability to assign, complete, and fail quests, and also to give and remove inventory items, and give or take away hit points. These speed up testing and debugging quests by giving us a shortcut to where the problem is.

This also allows us to force dialogue options that require specific items without running all over the map to pick up loot or convince NPCs to give us items.

Map Expansion

We continued expanding the interior of the ship. We’re still mostly gray boxing and not building with final assets, but the shape of the level is starting to come together. We expect the final level for the first demo to be considerably bigger than what we have now, but it’s significantly bigger than what we had last week. It is starting to become possible to get lost on the level.

Some of the expansion we did was to add more enlisted and ensign barracks which are virtually identical to the barracks we already had. These extra rooms exist partially to convey the sheer size of the ship (it’s supposed to be enormous), but also to provide more area to explore and more room for quests, NPCs, and exploration.

We also added the first small training range. The next level after this is the cavernous training range that you can see in one of the screenshots on our landing page, but now that we’re having the player spend a lot more time on the ship before going there, we didn’t want to wait until we got to the range to let the player try out some guns and teach them some combat mechanics. So, we’re creating a few smaller ranges down near the barracks. This week, we added a pistol range. Ironically, it currently lets you shoot every weapon in the game except pistols, but that’s only because we haven’t added pistol animations to the player’s animation state machine yet.

We hope to soon have some quests and tutorial using the range, but for now, there’s just a holographic target constructed using one of our old mobile models. It gives you can shoot at, but nothing more yet.

One last minor change we made to the map is the way most of the doors function. Our old automatic doors slid apart horizontally, similar to doors in the original Star Trek series. This presented a problem, however. The doors need to go somewhere. With the old doors, we needed to leave an equal amount of space on each side of a door, meaning we couldn’t put doors next to each other and couldn’t put doors near corners. That wasn’t a problem when we were building out larger rooms like the barracks and shower room, but became an issue when we started adding smaller spaces.

We talked through a few ways of dealing with it. At first, we considered some slight of hand, like scaling the doors as they opened, or using a material dissolve to make them disappear. Eventually, we opted to make them open vertically, which completely eliminates the problem very simply. We do have multiple levels to our map, but there’s a gap between each floor that’s big enough to accommodate the door when open. Eventually, we may go for another option, such as garage-style doors that roll up or more traditional hinged doors, but for now, this solves the immediate problem, and lets us build out things like this corridor of small rooms we added this week.

The purpose of these rooms has not been decided, but they might be quarters for officers or NCOs, or they might be some kind of offices, supply rooms, or maybe even some kind of meditation or privacy room. There’s not much privacy on a ship, so having a place soldiers can go sometimes to get away when they’re off duty probably makes sense from a psychological perspective.

Some Unfinished Tasks

We also made some headway on a few tasks that we’re not ready to show off yet. We started work on a mini-map display to help players navigate, and have done some work on a male proxy model so we can finally get rid of the Epic Mannequin completely, hopefully within the next few weeks. We also started work on save games. We’ll hopefully have a quicksave/quickload feature implemented shortly. While we don’t need a full saving and loading system yet, being able to quickly save and load the state of the game will be a huge benefit while debugging and testing.

There was also a lot of discussion this week about gamepads, and specifically about whether we should detect the type of gamepad the player is using and customize the display graphics based on that. For most controls, that’s not really important — left analog stick is left analog stick — but the labeling of face buttons is different between Xbox-style controllers and Playstation-style controllers, the two most common types of controllers people are likely to use. Telling the user to press the X button, specifically, can cause confusion because both styles of controller have an X button, but they’re different buttons. On Playstation, X is the “face button bottom” but on Xbox-style controllers, X is “face button left”.

Unfortunately, Unreal Engine doesn’t surface that information to us. It tells us whether the player is using a gamepad, but the make and model of controller is currently only available using platform-specific USB or IODevice calls. The only way to easily surface that information to where we need it would be to use a custom engine build. We actually used a custom engine build for the original mobile version of Republic Sniper, and it’s a huge pain in the ass for a small team to maintain, so we’re hesitant to go that route again.

For now, we put a pin in it. It’s really a polish issue that’s premature to spend much time on (even though we did 😬), so we put the issue in the backlog as a nice-to-have.

That’s about all we have for this week.