top of page

Unannounced Project
 

Unannounced Project is a multiplayer, open-world, survival-craft game mode set during a zombie outbreak. It is a limited-time seasonal experience made for a well known game franchise.

​​​

​

​​

​

​

Contributions

  • Base Building System (Feature Owner)

  • Item Crafting System (Feature Owner)

  • Economy and Resource Balance

  • UI/UX Design for Crafting & Building (Shared Ownership)

  • Deployable Combat Equipment Design

unannounced.png
Base Building System Case Study

- Base Building System -

Case Study

​

The Base Building System forms a key part of our Explore/Build/Defend game loop. It lets players spend resources to:

​

  • Construct Defensive structures to protect against enemy attacks

  • Construct Utility structures such as crafting workbenches and storage chests

  • Upgrade structures for improved defense/utility​

Rust (Modular Snap Building).gif

The final implementation closely resembled the snap-based construction style seen in Rust.

Development Process​

​

Leading Through Shared Ownership​

When leading a feature, I aim to create a sense of shared ownership across the team. Shared ownership is important because—if the system begins to struggle—that sense of shared ownership shifts the conversation from “who’s at fault?” to “how can we improve the system?” In practice, this leads to faster iteration, stronger morale, and higher system quality.​​​

​

​Shared Ownership Workflow:​

  • Research & Proposal

    • Research design references & constraints

    • Draft a clear, focused design proposal

  • Peer Feedback & Buy-In

    • Discuss direction with key designers

    • Refine weak areas early

    • Ask 1–2 peers to actively support the proposal during kickoff

  • Kickoff Meeting

    • Invite stakeholders from Design, Engineering, Art, QA, and Production

    • Ask attendees to review the proposal beforehand and bring questions — the meeting is for Q&A, not for reading the doc together

    • Incorporate strong ideas on the spot to refine the feature collaboratively

  • Task Creation

    • Convert meeting alignments into concrete tasks

    • Collaborate with Production on scheduling

  • Team-Driven Iteration

    • Implement → playtest → evaluate

    • Adopt the best ideas, regardless of source

    • Repeat until the feature is stable, scalable, and ready to ship​​​​

 

By structuring the process this way, the team isn’t just executing a plan — they’re actively shaping the feature alongside me, which builds buy-in, accelerates iteration, and improves final quality.

Research & Proposal​​

​

The client initially suggested a 7 Days to Die-style block-by-block building system. We quickly identified that the slow construction speed of 7DTD's system wouldn't fit our fast-paced wave combat. In response, I generated 3 building system proposals and evaluated them against 3 key goals:

​

  • Fast construction speed

  • High base customization

  • Strong multiplayer support

​

Proposal Evaluation:

Building System Proposals.png

Proposal Gameplay Examples:

Peer Feedback & Buy-In

​

With proposals in hand, I discussed the building system’s direction with a small group of designers to gather early feedback.

 

Key Takeaways:​

  • Selected the Rust approach

    • This approach offered a strong balance between fast-paced construction and high base customization

  • Retained AoE-style blueprint planning

    • The team was excited about the potential for multiplayer teamwork offered by this feature

  • Identified control layout risks

    • We worried there weren’t enough buttons to comfortably support all the building system functions. This was flagged for adjustment once the core system stabilized.

​

After aligning on direction, these designers agreed to actively support the proposal during the upcoming kickoff meeting.

Kickoff Meeting


​

After securing initial buy-in, I scheduled a kickoff with the broader group of stakeholders from Design, Engineering, Art, QA, and Production. Attendees were asked to review the proposal doc beforehand and bring their questions and ideas to the meeting.



 

Key Outcomes:

  • My supporting designers and I clarified outstanding questions and addressed concerns about the system.

  • A team member proposed an interesting control scheme, which we incorporated into the updated design doc:

    • Add a “fire select” toggle to the build tool that switches between Build and Edit modes, expanding available button real estate.

    • I had some initial concerns about this method, but the team’s enthusiasm led me to support prototyping it for evaluation.

  • The group left the meeting with a clear understanding of the mechanic and how each discipline would contribute to its implementation.

​

The Proposed Control Scheme:

Task Creation​

 

​Post-meeting, I converted our agreed design direction into discrete JIRA tasks and worked with Production to schedule them into the backlog.

Team-Driven Iteration

​

With the feature tasked and scheduled, we entered a cycle of Implement → Playtest → Evaluate. We continuously gathered notes and suggestions from the whole team via playtests, desk-side feedback, and surveys. The system evolved significantly over multiple iteration cycles.

​

 

Key Iteration Changes:

  • Removed Blueprint-Style Planning

    • Originally included to encourage multiplayer teamwork, it ended up slowing construction and making controls feel fiddly. Removing it streamlined gameplay.

  • Replaced Mode Toggle Control Scheme

    • The original build tool used a button to toggle between “Build” and “Edit” modes, which confused players. We replaced it with a simpler system: selecting a buildable from the menu put the player in Build mode, and deselecting it returned them to Edit mode, making controls more intuitive.

  • Added Paginated Build Wheel

    • Players select what to build from a circular menu (the Build Wheel). Pagination allowed more build options to fit in the menu while keeping it easy to navigate.

  • Added Building Stability Rules

    • Structures were made to follow basic stability rules, preventing players from making glitchy-looking buildings that had insufficient ground support.

  • Added Damage Visual Feedback

    • Buildings shook and showed visual damage below 50% health, helping players understand the state of their base during attacks.

  • Added Crafting Workbenches

    • Players could build workbenches only inside their base. Advanced crafting required a workbench, encouraging players to return to and invest in their home base rather than crafting everything from a backpack while roaming the map.

Conclusion

​

The Building System underwent several rapid iterations early in development before settling into its final form. Because the core mechanics stabilized relatively quickly, the team had significant time to gather playtest data, address edge cases, refine control schemes, and polish UI and visual feedback.

 

This process of early alignment followed by team-driven iteration allowed the system to evolve quickly while maintaining strong cross-discipline collaboration.

bottom of page