Unannounced Survival Game

Under Construction…

Game Description

A 3d person magical fantasy survival live service game. Developed as “console first”

Development

Role: Systems Designer

Game Type: 3rd person survival GaaS game

Editor: Unreal 5,

I was  responsible for;

• Game economy including resource generation and how materials related to craftable items
• In-game itemization and how it linked to crafting and enchanting
• Inventory, paper doll, and tooltips design and spec work
• Various incubation prototypes – Gameplay, puzzles, and UI
• Leading and designing world object interaction efforts

In addition I was actively engaged with defining and iterating on our core loops and core philosophies with our CD. I worked diligently to improve my visual and verbal communication skills in order to effectively communicate ideas and concepts to the team.

Below is just a small selection of the things I was able to work on during this project.

Things I’m proud of:

The Vortex

Worked closely with our CD to develop “the vortex” theory for bring non-core players into a hardcore genre game. Which simply states that if you are creating a genre game that needs to bring in non-genre players you must have unique selling points and approachable onboarding paths to the core genre experience with deep investment potential.

As part of this I developed a mission statement and visuals to illustrate the concepts.

Mission Statement: “Our mission is to create appealing games that are systemically deep enough for core players to invest in, approachable enough to convert non-core players into core players, and extensible enough to be supported for years to come.”

Content Delivery Methodology Theory

As part of my economy work I had to develop a theory of content delivery that would serve as the framework that we could design around and inform our content and production pipeline. I pulled deeply from my own experience working on live ops products in collaboration with experts on the team.

I did not need to break new ground here but I needed to come up with a solution that was solid enough that we could refine it as we moved into production and live ops. As part of this I pulled on genre standards and visualized our content breakdown and delivery and coined the very professional term “bucketizaton” to help standardize communication around the concept.

Extensible Content Delivery Framework

In order to be a live service game over a number of years we must build our game so that it can grow, evolve, and be added to on a regular cadence. That means where possible our strategy will be to utilize siloed content “buckets”.

Bucketization is a system where the atomic units of content can added to the game independent of other content and made accessible to the player without significant developer support. That means that expressive content can be made with common ingredients available at their time of release.

• An example of this is Nooks Cranny in Animal Crossing (AC) which can seamlessly offer you new items when ever the developers push them. The items sold are pulled from a bucket of furniture content and can be purchased for a unified currency.
• Similarly DIY recipes in AC can be added to the game and delivered to the player from many different places. New recipes are pulled from a bucket of recipe content and can be created with any item that has shipped with the game.

Experiential content delivery systems must be in place that allows the content to be selected and displayed to the player when appropriate.

• An example of this is new islands or NPC’s in AC which can be added to the game and delivered by leveraging the existing nook ticket and island visitor systems respectively.

Larger releases will package up themed pieces of content from these different buckets. These larger releases can include, new biomes, special events, holidays, or quest lines.

• An example is Seasons in AC which include new art content, events, harvestables, and recipes for furniture and clothes.

Typical Work: Systems design, prototyping, feature and content work

What makes something sandboxy?

During my time at PM I was tasked with all manner of systems and feature work tasks. During our reboot phase I spent a lot of time doing market research and developing prototypes for what makes a sandbox game mechanic “sandboxy”.

Sandboxy– The characteristic of an object that makes it more conductive for player experimentation. That is a “sandboxy” object has a gameplay output that can impact many other objects.

Prototyping

During incubation I created several prototypes in UE4. These were used as tool to validate design theories and test out mechanics.

• Moment to moment “sandboxy” mechanics
• Skill based mini-game
• NPC “Favor” system and UI

Content Pipeline (Ingredients to Items)

I worked closely with our art department to define how our resources like wood and stone would impact the visuals of our items. This was a very contentious issue but I feel that we came up with an excellent compromise that allowed our art team to create amazing iconic art and meet our MTX business goals. After establishing how our resources and items would interact I was able to maintain an MVP content manifest to the store tuning numbers and be the basis for any content tooling we came up with.

Feature Management

I worked closely with other discipline team members to list out and understand feature and content requirements and then bring them across the finish line for milestone deadlines.

• Including Interactable objects with engineering, environment art, and tech art
• Tree harvesting with tech art and environment art
• Encahnting station visual performacne
• UI requirements and iteration

Selected Content

Loops and Journeys

Data Tool

During incubation I put together a small editor tool to help me manage items, ingredients and status effects. The goal was to create an at a glance THE source of truth for what was in engine. I was the primary user but QA was able to leverage it to good success.

Skill based mini-game prototyping

I put this together as an answer to the question of – how can we make an extensible skill based interaction that will slot into many different interaction. I took inspiration from arcade mini games and bioshock “waterworks” mechanics.

Players would spend a resource to play the game – if they completed the task they would then perform whatever the action was. The extensibility of this minigame was one of the many things that made it palatable. Ultimately the game vision moved in another direction however.

Enchanting Items

I put together some infographics to describe how enchanting items would work in our game. This was delivered as a document to the design team and a presentation to the team.

The intent of this system was that weapons and armor would define a play style, spells would provide a high impact tool, and mods would provide a power chase for players.

Roughly speaking player could select items which had a certain subset of valid spells that could be added to them. Those spells were the “first order” powers that were easy to understand and immediately recognizable. Depending on the world state (where, when, weather, etc.) a spell was enchanted could give the item additional modifications.