Capital Gains

A corporate doomsday management simulator with rage game controls.

Project Summary

Capital Gains was created as an entry for Grads in Games' Search for a Star competition. 

The project brief was to design and prototype a game/mechanic that combines two different ideas that don't usually go together. I liked the idea of combining calm with chaos, so I designed a game that is both a management simulator (calming) and a rage game (chaotic).

My inspirations for this game included games like Surgeon Simulator, Cooking Simulator, and Slime Rancher. 

My submission video can be found to the left. This video explores the prototyped mechanics and how these interact with each other. 

Concepting

After defining my two core ideas (management sims and rage games), I started exploring different theming options.

I created the mind map shown to the left (top) to help generate ideas, highlighting my top 3 ideas in green. I then conducted a quick analysis of these three ideas, evaluating the pros and cons of each. From this, I chose to take forward the "Jeff Bezos sim" idea.

I made sure to document my design limitations and pillars based on this concept. My design pillars were as follows:

Following this, I started to explore different theming options to apply some narrative and context to my proposed mechanics. I did this by generating ideas for what resources the player is managing. The mind map exploring this can be seen to the left (bottom).

Out of each idea, I listed the potential mechanics that could be present to allow the player to manage said resources. The mechanics that I liked were highlighted in green, and the mechanics I disliked were highlighted in red. This left me with 3 resource ideas with all-green mechanics which I once again evaluated and listed the pros and cons of each.

I finally decided on the "Factory Bosses" idea, as I felt that this had the most opportunity for in-game interaction that did not rely on 2D UI elements. This was what was best in line with my design pillars, as I had specifically established that I wanted to focus on first-person interaction (like Slime Rancher), rather than using 2D UI elements to communicate and facilitate the management interactions. I felt that this would create a more immersive experience, and lent itself much better to the integration of the rage controls.

Mechanics Design

The image above shows the basic game loop.

Players will receive a goal, then complete tasks relating to this goal. This will then affect their profits, and they will have to pause the loop to balance profits by completing more tasks, this will then improve pollution, and they will complete their goal.

The image to the right shows my Mechanics Diagram. This diagram presents every mechanic in the design and shows the relationships between these. These relationships have been labelled "conflicting" and "complimentary", drawing attention to how these mechanics push and pull to balance each other out.

Each of the mechanics works well internally (eg, the management tasks), but, the other mechanics (rage controls and timer) are a conflicting point of stress, pulling the player away from management gameplay. This helps to round out the experience by creating necessary stress between cohesive mechanics.

Level Design

The image to the right shows the level layout for this design. I purposefully chose to confine this game to one room to ensure that I kept a small scope, which also allowed me to go more in-depth with my level layout.

Prior to creating this diagram, I generated ideas for potential tasks and listed these out in a table (noting down neccessary task objects and interactions in the process). This left me with a long list of items that needed to be inside this room, each of which is labeled in black.

I also created a moodboard of images to inform my layout (photos of similar offices, etc).

When creating this layout, I made sure to spread the interaction points evenly throughout the room. I wanted the player to make full use of this office, and wanted to avoid them simply walking back and forth between the same two areas. I then mapped out the paths of travel in red to confirm this layout.

Prototyping

For my prototype, I focused on conveying an experience, rather than creating a fully fleshed-out game demo. I am not a programmer and my design involved some complex systems that I knew I did not have the skills to implement (such as the character controller and management gameplay), so I felt like this was the best use of my time.

I implemented a block out of the level with basic textures, a simple shader, one task, and a simplified version of the character controller. I would have loved to have implemented a few more tasks, however, this just was not in my scope. The task that I implemented, however, showed off the character controller well and, as it affected the pollution metrics, did a sufficient job of explaining how the management gameplay would work.

SFAS Entry.pdf

Submission

The document to the left is the PDF version of my design development log for submission. My submission video can also be found here.

This is quite a lengthy document as it details all of my design decisions from concept to prototype, including a reflection and breakdown of how long I spent on each aspect of this project. This document goes into much more detail on specific aspects of the design and includes much more information that is not included on this page.