• 🚧 THIS DOCUMENT IS A WORK IN PROGRESS ⚠️
• Overview
• What went well
• Mind Mapping
• Prototyping
• Player
• Functional Blocks
• Player Tools
• Item Crafting
• WorldSpace UI
• Item Pickers
• NPCs
• Ship Building
• Saving and Loading
• Better Unity Hierarchy
• Custom Animator
• Project Organization
• What Didn't Go So Well
• What did We Learn?
• Soundtrack
• Gestalt Ambient
• An Explorers Soul in an Engineer’s Body: Phrase 2
• 30 Minute Trial
• Things That Got Left Out
• Known Bugs
• Action Item / Takeaways
• The Demo

—

🚧 THIS DOCUMENT IS A WORK IN PROGRESS ⚠️

Overview

Gestalt: Scavenger is a Sci-Fi top down game with ship interior block building similar to Minecraft where it is done by snapping blocks with various functions together, and the exterior of the ship is done in a kit-bash style with exterior ship hull segments snapping together to define the total volume of the interior space.

Some of the game design was inspired by what the team loved from games like Dungeon Siege, Space Engineers, MineCraft, and Avorion.

This project was started with the hope to build a complete game to ship, but we also had a handful of other goals in mind as we setup the project.

1. To give our team a chance to try out some ideas on content pipelines such as animations, art assets, and music in our games
2. To give us the time to dive deep into one stack of tech (Unity 2020 LTS + C# + URP + and at least one asset as a core framework)
3. To explore the capabilities and limitations of the entire Unity asset and system (importing, updating, and possibly exporting to create our own assets)
4. To take an game design document and experience the process end to end of putting the game together, releasing it to others, and gathering feedback.
5. To allow us to explore how to extend an existing framework to add a handful of our favorite game mechanics (pro tip, its harder than it looks)
6. And finally, to be a portfolio piece for Digital Dragon Slayers to show our progress as a team.

What went well

We started off the game’s prototype stage by evaluating multiple frameworks.

1. More Mountains: TopDown Engine
2. Sci Fi Top Down Game Template from PolygonR (which we had used for our previous POC)
3. Third Person Controller - Shooter Template framework from Invector
4. Game Kit Controller from Two Cubes.

We were super impressed with all of the frameworks, and if the team had the time to build a game based on each, we would, but as we learned in this project, just understanding and extended one engine was going to take more time than we expected, and at the end of the day, we did want to ship a game and not just do research.

We went with the TopDown Engine from More Mountains, and a big part of the reason why was because Renaud Forestié and The More Mountains team write great code, Renaud is very active on multiple support forums, and the Top Down Engine baked in almost everything we needed for our initial Character, Camera, and Control. It also helped that the Gestalt team had built a previous prototype based on the More Mountains 2D platformer named Corgi Engine, and the learning from that project directly applied to our work with TopDown Engine.

The More Mountain’s assets are a proper tech framework, similar to how React or NodeJS are mature Javascript tech frameworks in the web space. The TopDown Engine provides a simple scaffolding and many examples to support prototyping and building of your game, but it also makes clear and well thought out decisions on best practices around core game design and code architecture choices.

Best practice based decisions like the following are already baked into both of the More Mountain Frameworks that we’ve used:

• How do you deal with keyboard/mouse, joystick, and touch inputs all in the same project?
• More Mountains abstracted it away into their framework.
• How do you give the player the ability to jump or climb?
• The ability system is built into the in the TopDownEngine Framework.
• How do you collect, use, manage, and persist inventory?
• The framework also include an inventory system for all of the basics, and we extend it to handle inventory for all of the objects in our game.

Mind Mapping

We did multiple drafts of the mind map, each one more and more complex adding more and more detail to each core game mechanic. When we finally arrived at our first Alpha release, these are the primary items which we had completed in the game.

If you’d like to see a larger and more detailed version with some of the features that we moved to our future alphas, take a look at our original bubbl.us link here:

• http://go.bubbl.us/c997e7/95ef?/Gestalt:-Scavenger

Prototyping

Thanks to the More Mountains TopDown Engine and the author’s addiction of purchasing any and all sci-fi art assets when they go on sale, we were able to get a fun little prototype going relatively quickly.

Player

Control and Camera

Hotbar

We extended More Mountain’s abilities on the player, we started with the most basic ones, but later moved many of the player abilities into the tools themselves.

• collect drop items ability
• place block ability
• weld block ability
• grind block ability
• interact with grid block ability
• transfer inventory with grid block ability

Functional Blocks

Every block can placed, welded up, or ground down in the scene is called a functional block.

Each functional block has at least 1 type of inventory for its on recipe of components required to make the block active. Many blocks have a second inventory for interior cargo space where the player can store arbitrary items inside of the functional block.

Within the game design, functional blocks can expose game loop abilities such as our first two blocks:

• A Cryogenic Tube which functions as a save point for respawning the player

• A Ship Builder which activates the exterior ship hull editor.
TODO: Get ship builder table screenshot

Functional Blocks are built using the Unity Scriptable Object system and the top level of the functional block is edited with a custom Odin inspector. We extended the More Mountains Inventory system to add multiple types of inventory for each block and the player. We added the ability to disable functions and parts of a block when it didn’t have all of its components filled up.

Player Tools

MultiTool for Welding and Grinding

EBS Block Placement Tool

Item Crafting

Blocks are made of components, components are made of ingots and alloys, ingots and allows are made of ores. The chain is designed to be reversible so that if you have a component made of 10 ingots of a particular type, you can melt that component down and recover the 10 ingots so as to then use the ingots to make another component.

WorldSpace UI

In Gestalt: Scavenger, I started experimenting with User Interfaces that don’t take over the players whole screen by placing the primary user interface for functional blocks directly over the blog in the game world. In Unity's game engine, this is called a worldspace UI.

Item Pickers

NPCs

Loot Tables

Roaming

Stationary

Weapons

Sensors

Ship Building

Saving and Loading

Better Unity Hierarchy

This is also the first time I started optimizing my workflow and presentation on feature branches and their hierarchy

Custom Animator

First time building a custom animator in Unity. This uses the older state engine instead of the newer blend trees, but I knew that a lot of assets which I would be importing in the future might still use this animation system, so I wanted to get experience building one from scratch.

Project Organization

First time organizing this much content a Unity:

What Didn't Go So Well

We based a lot of our [ CC&C ] on the TDE, but we learned the hard way that simple changes aren’t simple when we don’t understand a system end to end.

• Though we were able to extend the More Mountains Inventory system so that each block has multiple types of inventory, when we went to enable the built in inventory saving system we ran into the trouble that each block (and each inventory) does not have a unique identifier in the scene.
What did we learn?
1. Learned: unity serialization doesn't natively serialize all data types to disk
2. Learned: using Odin serialization to disk is possible, but less performant and risks creating very large data structures that the game doesn't need to be able to recreate the scene.
3. Learned: spending time evaluating other assets to do our saving for us was likely just as time consuming as learning how to build a custom serialization to disk saving function, and though we learned lots about various save methods, we didn't go with any of them and we still don't have a unified save code path.
• Functional Blocks placed into the scene as a prefab, functional blocks placed by the player, or modified functional blocks all had different code paths to deal with initialization on the world load.
What did we learn?
1. Learned: The whole world save should exist as a singular save file. Any user interactive block should be placed in game and then saved to a world save for the first time the player sees the world.
2. Learned: any future modifications and interactions with functional blocks within a world are all saved to the players save file which is then used instead of the pristine initial game save file.

More text and pictures.

Some occasional text in blocks:

I just found this in the "instructions" object in the PlayerCamera_TopDown camera.  

Might be useful for others ....

What did We Learn?

[ DRAW ARCHITECTURE OF MM TDE + Gestalt ]

Next project:

• Understand data architecture & serialization of all of my types of data before writing code around it.
• Break all of my work down until the maxium I spend on a particular “card” or task is 1 week
• Build Unit and Play mode testing for all of my prefabs and scenes
• GET CI/CD setup for our develop and main branches and ship a build for every successful PR!

Soundtrack

I (Mark McCorkle) built a handful of tracks specific for this game. Though we did dive into a quick research into FMod and how to do layering that would be responsive to game elements, we didn’t get to implement any of this into this game as of this writing.

Gestalt Ambient

An Explorers Soul in an Engineer’s Body: Phrase 2

30 Minute Trial

Things That Got Left Out

When everyone on the team has lives outside of working on this game, we have to make some

• true level and ship building with persistence
• roaming and stationary enemies
• puzzles where building certain blocks from certain materials solves the puzzle
• the whole mining, refining, and assembling game mechanic where we take ore and refine it to ingots and allows, then use those to make component which are then used to place and weld up blocks the game
• mining asteroids
• ship flying
• complex interactions with the blocks functions
• ability to drag & drop inventory from one block to player or other blocks

Known Bugs

[TODO]

Action Item / Takeaways

The Demo