A Look Into My Role On
Project Storm is a top-down Action/Adventure game set in a Storm Temple where you combat foes and solve puzzles to fend off a great evil.
Player Experience Goals
The most important design step during pre-production is setting the Player Experience Goals the design must strive for. To create an effective game treatment, I asked the following questions.
- The player will feel like a tomb raider exploring an ancient ruin.
- Players feel trepidation, curiosity, and mystery as they peel back the secrets of the temple.
- The dramatic arc for the player sees them feeling stronger as they peel back the secrets of the temple.
- Spatial reasoning will play a huge role in creating this sensation – the player should begin to understand the layout of the temple and how different areas relate to each other the further the player progresses.
- The space inside the temple should appear daunting at first, and by the end, the player should feel like they “mastered” it instead of simply “solved” it.
- The level should be the challenge, not a box that holds challenges.
- A central chamber should hold an array of obstacles that utilize items the player has not yet found. From there, the player embarks on two paths.
- These paths should introduce a problem for the player – an obstacle they face.
- The player should then be given an unfamiliar item and face problem scenarios that demonstrate the uses of the items.
- The player should then be tested for mastery of that item.
- Each path includes a critical path through that part of the dungeon, but optional rooms and intentional obfuscation of the critical path should be added to invoke feelings of non-linearity.
Effective level pacing relies on a macro design document, also known as a beat chart. I created one for our first stage.
While our design is in-progress, this beat chart allows us to see a high-level overview of the gameplay progression throughout the game.
This lets us catch pacing and design issues early, and accelerate the prototyping and iteration stage.
For our macros, one of the key attributes I’m watching for is mechanical progression. We have three weapons we want the player to have mastered by the end — a spear, a bow, and a drum. By listing the mechanics employed in each stage of the level, I can effectively dole out new challenges that continue pushing the player’s skills with each item.
Modular Scripting for Rapid Prototyping
Key to early scripting work is the modularity that allows for rapid changes that come with the prototyping and iteration stage of design.
For enemy AI, all enemy actors are extensions of a base class implementing a common interface. This allows changes to default enemy behavior and inputs for enemy classes from other actors to propagate to all enemy classes.
I designed certain methods to be overridden such that custom behavior could be applied on a per-input basis, allowing for rapid enemy development. This has increased our development efficiency, allowing us to accomplish a more ambitious level with the time we have.
Enemy base class “Hit from Player” event implementation. Use Right Click/Scrollwheel to navigate viewport.
On override, a child of BaseEnemyClass can quickly implement its own custom functionality based on the move used on it by the player. This saves code, and saves time.
Enemy child “Take Damage” override implementation. Use Right Click/Scrollwheel to navigate viewport.
Our goal is to release a public playable build by the end of April. Until then, I’m hard at work on level design and scripting as we work towards this milestone. This page will be updated with a download link when the time comes.