Screen Shot Saturday & Devlog - October 10, 2020

Welcome to the very first Republic Sniper: Resurrection Screenshot Saturday post!

Considering that Republic Sniper: Resurrection is a side project with only a couple people actively working on it, and those only in their spare time, we’ve made some surprising progress recently. Even though we have six maps in various states of completion from the original project, we’re focusing on a new map at the moment. This new map started out as an extension of the original starting map from the old game: a training range, where players would be taught the basic movement and combat mechanics.

For the new version, we decided to add some gameplay before the training range to do some story setup and to get the player invested in the universe so some of the later events have more impact. In the new version, the player starts right at the point when the main character, Liliya, arrives to the ship. We’ve also divided the tutorial into two parts, with the non-combat training happening down in the ship’s barracks instead of the training range.

After some discussion, we realized that a good ending point for our first development milestone would be the point where you unlock the elevator that connects the barracks to the training range. So, we split off the new part of the map into a new map, and are focusing our efforts on expanding and polishing the game mechanics using that environment. We are planning to add a smaller practice range near the barracks so you can at least test out guns and do some practice before you have to go up to the main range to take your qualification test.

Dialog and complex quests were not part of the original game, but we’ve now got a fairly robust systems in place for those. The first few story and side quests are playable and we have grown the barracks map to the point where it’s actually bigger than the original first map in terms of navigable space. The original range map was huge, but a lot of it was there for visual impact and was inaccessible to the player.

We still have a lot of work to do before we get to our first milestone, even with cutting the scope back to exclude the range, but this week, it started to feel like a game, despite the large amount of gray box assets, proxy characters, and engineering UI.

That was a good feeling.

We’re tentatively looking to have the first milestone in demo-able condition before the end of the year, with Thanksgiving as a stretch goal. We’re trying to keep this low stress for everyone involved, though, so those dates could easily slip.

Unfortunately, we currently have no game artists actively working on the project. A few of us have some okay art chops, but we’ve really got nobody to do the heavy lifting on art assets right now. We’ve used some freelancers for a few tasks, but don’t have the budget to pay for significant art work right now. In some cases, we’ve even removed existing assets that were created for the original game because the mobile assets actually looked worse on a 27” monitor than just using the stock mannequin. We still hope to find the original high resolution Zbrush character files so we can create higher fidelity versions of the characters we do have. We are also using some marketplace assets for some of the NPCs, but even those, like the mannequin, are just placeholders. The vast, vast majority of the assets are either unfinished or proxies right now.

The current map starting point. Still a lot of gray, but there’s stuff to do!

Just in case it wasn’t clear that we’re near Mars…

A marketplace asset standing in for the Admin Officer.

The current state of the Barracks map.

The underbelly of the ship will be accessible in a few places.

Instead of focusing on fine-grained quality like we would have when someone was paying the bills, we’ve decided to focus on going as broad with our implementation strategy as possible. This means implementing systems that can be reused and “wired-in” really quickly to serve as many different masters as possible.

When you pick something up, or acquire a new directive (quest) the receiving player has a very simple “Message” that displays at the bottom of the screen. The current placeholder design is displayed with a background blur to help with readability; you can either send in an explicit configuration, or if the string coming into the function matches an id in the database it will pull a localized version. This means we can iterate on quest and item pickups quickly without worrying about how to convey this information to the player.

Any number of “Messages” can be pushed onto a stack and they’ll display for an amount of time based on the word length inside of the final output string.

Another huge aspect of the meta-game that we never had to consider as part of a mobile game was how to manage inventory. The original plan for the game was that at the outset of a level you’d have a “Gear-Up” phase where you had to plan your loadout based on the objectives of the next mission. We did this for a bunch of reasons that no longer really apply to either modern games, nor desktop games so we decided to pivot to something more conventional. While boring, its telling, that we focused on building an infrustructure that supports controllers and keyboards equally, to display a realtime inventory, character sheet, and a system menu.

This handles all of the statefullness of the UI and allows us to quickly implement new panels in a non-headsup UI to manage the player’s inventory, display a character sheet for levelling up and so forth, or a system menu for configuration game options and restarting the current level or leaving the game. Our intention is that when we get our first vertical slice; all of the meta-game items you’d expect are present so that there is as little discomfort as possible in playtesting.

As part of the quest system we wanted to ensure that the player always knows what’s expected of them “next.” To this aim, we implemented a quest-lines UI that sits inside of the heads-up display. Items animate in and out as you acquire and complete them nicely.

All of our quest and inventory data is pulled from data tables, so many quests can be implemented with no coding, by just populating data tables and dialogue trees and using generic blueprint actors to start and finish quests (e.g. BP_QuestEndMarker allows the player to end a specified quest by walking to a specific point or interacting with a specific console). This greatly speeds up the process of designing and implementing quests. Some quests do need custom actors, but even those are relatively easy to create on top of the infrastructure we’ve built.