Neon City
ABOUT
Neon City is a VR City Building Sandbox Toy. In this experience, players embark on a playful and meaningful experience of building a digital city for millions of lost AI citizens. It's a wooden block toy that can be dynamically zoomed in on and an emergent building experience akin to Townscaper.
DESIGN CHALLENGES
-
Haven't designed for any VR games before.
-
Set up amusing rules for cubic building blocks and communicate them to players during their playthrough.
GENRE: City-Building Sandbox Toy
TEAM SIZE: 25 students
DURATION: May 2022 - May 2023
TOOLS: Unity/Houdini/FMOD/Miro/Notion
PLATFORM: Oculus Rift, Oculus Rift S
MY ROLE(As one of the 2 game designers):
Gameplay Design
-
Starting with physical toys then many iterations of digital prototypes, designing the core game loop and the emergent city system.
-
Concepted an intertwined experience of playing and narrative moments.
System Design
-
Designed and prototyped for fundamental city blocks and systematic districts.
-
Concepted the city blocks with various types and sizes and their relationships to create a context for players to experiment and build.
-
Tweak numbers for the stats of building blocks and conditions for players to trigger a moment.
Technical Design
-
Work with the writer to collectively prototype the emergent narrative system for moments supporting different system outcomes.
Gameplay Walkthrough
Gameplay Design Process
Premise
When I joined this project, a demo with certain features the director desired was already in place: Through a VR headset, players construct a city using their own hands, achieved by placing colorful cubic blocks on a board. The city can then be zoomed in, allowing players to take a look or marvel at their creation on a true-to-life scale. As a designer, my primary challenge was to address the following questions: Beyond the immediate gratification of VR, what’s the fun part about the game? Additionally, how can we keep players engaged and entertained by the gameplay?
Circuit Connecting & Quests
physical prototype v.1
Taking a step back from the digital realm to the physical, we initiated ideation using toy wooden blocks and paper pieces. For the building blocks, I devised a puzzle-based gameplay featuring distinct circuit layouts on each facet. Players strategically placed blocks to connect circuits, with "energy spots"(orange squares in the picture) preventing clustering because the first blocks had to connect to energy spots. For progression, I wanted a different experience from Townscaper by introducing quest cards for both short term goals and narrative guidance. These cards set targeted positions of blocks, block constraints, and bonuses—increasing residents and reputation.
While the initial design successfully added fun and motivation, concerns arose about predictability as a simple building game, and hidden circuits with more blocks.
Relationship System & Streets
physical prototype v.2
This iteration revolves around simplifying surface-level rules while maintaining emergent gameplay—centered on expanding the city by connecting blocks. Drawing inspiration from chess, we pursued a streamlined approach, discarding the quest system in favor of guiding players directly through the gameplay. Additionally, we replaced the circuit-based mechanics with a block relationship system. Blocks of varying types needed specific adjacent blocks to trigger bonuses for the whole city. While energy spots were eliminated, streets(marked by blue squares in the picture) were introduced for building connections. This addition enabled easier district-based city building and easy camera placement for the upcoming zooming in feature, and it aligned better with the city-building settings.
Concurrently, I started on designing distinct building blocks with varying features and rules. A visual representation of this design process is presented in the mind map on the right.
Density, Requirements, and Satisfaction
digital prototypes
Encouraged by the relationship system and streets, and recognizing the limitations of physical prototypes – such as the inability to test diverse block sizes and floating buildings – we transitioned to digital prototypes. A drawback of the direct connection feature was that players could create pipe-shaped buildings without limit, reminiscent of piling up random LEGO parts forever. After multiple iterations where I both designed and coded, we revised the relationship system with a detection range feature: Starting from itself as a referencing point, each block assessed its surrounding space of several cubes. The satisfaction value of a block was influenced not only by the quantity of other distinct blocks detected but also by the density of all neighboring blocks. This adjustment aligned better with the narrative, as living in a congested area is less enjoyable than in a more spacious area.
Subsequently, we introduced a block info panel, allowing players to access specific data for each block. This feature facilitated players’ rapid comprehension and effective planning within the dynamic emergent scenarios. Given the prolonged time required for art asset creation and the absence of placeholder assets for block differentiation, I also set up type name displays for each block as a development feature.
System Design Process
Once the gameplay system was established, my role shifted to fine-tuning numerical values and engaging in extensive playtesting, aimed at translating concealed mechanics into a numerical framework. This transition allowed players to progressively uncover the methods for building either a prosperous metropolis or a crowded ruin.
District Ruleset
This aspect revolved around setting a resource limit. And I adjusted how the city responded to the average satisfaction value of individual blocks or the cumulative satisfaction value of all blocks.
General Block Ruleset
This aspect revolved around setting a resource limit. And I adjusted how the city responded to the average satisfaction value of individual blocks or the cumulative satisfaction value of all blocks.
Residential/Retail/Office Ruleset
Here, I stipulated density requirements for various block types, along with the ideal quantities of different block types.
For instance, combined with the picture on the right, if Residential Blocks favored other Residential Blocks and a few Retail Blocks nearby, but disliked Office Blocks, I had to pinpoint precise numbers for terms like "more" and "several." "4-6" might represent "more" and "2-4" indicated "several." However, playtests might tell me that I blew up the density value for having high base values of Res Residential Block Needed or Res Retail Block Needed. Additionally, it also might be too challenging because Office Block likes Residential Block… I got feedback from QA and playtesters, changed numbers, and kept playtesting…
Notes
The iterative process of balancing these interconnected numerical values proved a constant challenge. However, I improved my intuition for numbers by closely collaborating with QA and analyzing playtest feedback. Both descriptive observations and survey data from playtest sessions enabled me to refine and modify the numerical framework for optimal system balance.
Emergent Narrative Design Process
Premise
Designing the emergent narrative system for triggered moments in the game was another significant aspect of my work. During the "moments", players receive comments from their bot friend, V1. The design goal was to create immersive barks from V1, reflecting its unique characteristics while naturally reviewing the player's achievements during the city-building phase. Collaborating with one of our writers, I developed a feature prototype by categorizing them into two types: happy and sad.
Bark Breakdown - Happy Moments
In "Happy Moments", we aimed to provide players with both a sense of accomplishment and improvement directions. Initially, the bark comprised three sentences, addressing the total happiness value, the dominant block type reminder, and block variety. The first sentence generated a random statement based on an ecstatic or happy value. The second sentence offered compliments on the current dominant block type. The third sentence evaluated whether the dominant block type significantly outweighed others. If it did, V1 reminded the player to diversify; if not, it assessed the happiness of other block types and commented accordingly. The structure was well-received during internal testing, although we later scaled down the third sentence due to time constraints.
I constructed the condition nodes and action nodes, while the dialogue nodes were the writer's responsibility. This collaborative approach resulted in a balanced and engaging narrative system that complemented the gameplay experience.
Bark Breakdown - Sad Moments
In the "Sad Moments", the aim was to evoke sympathy for residents' pool lives without direct criticism on players, with a slightly humorous tone. Similar to "Happy Moments", this bark featured three sentences, arranged differently to avoid immediate discouragement. The first sentence reacted to the dominant block type, followed by sentences based on non-dominant block types. The third sentence concluded with a comment on the low total happiness value. We also scaled down the comments related to non-dominant block types.
A Prototype in Unity
Building upon the logic outlined in the mind maps, I translated the concepts into a prototype within the Unity Editor. This prototype allowed for the simulation of various numerical scenarios within the city, generating comments as output. The prototype consisted of three components:
-
Parameter Controller: This module processed parameters provided by designers to determine the overall satisfaction state of the city and different block types. It made decisions about whether a happy bark or a sad bark should be triggered based on these calculated states.
-
Happy&Sad Moment Dialogue Database: This database contained the logic for arriving at specific comments, along with placeholder comment options that could be displayed at any time.
This prototype served as a helpful tool for efficiently designing juicy dialogues. Designers could adjust parameters in real-time during runtime and instantly obtain textual output, enabling rapid verification of the branching structure of each sentence. This tool facilitated the creation of well-aligned dialogue that both implied potential goals during mid-game and reinforced the narrative immersion for players.