We more than once stressed the usefulness and efficiency of picking a well-known analogy to introduce a brand-new topic. Most of modern videogames are developed by sizable and heterogenous team, thus the importance of defining and agreeing upon a scaffolding structure or ubiquitous language the whole team will be comfortable with. Ideally, early in the project lifecycle. By doing so, every project stakeholder can exchange and make proper decision, without wasting time explaining concepts or wondering about proper definition or usage, again and again.
We will leverage Rayman, a famous platform video game, developed by Ubisoft to materialize this idea.
Stage
Videogame has stages. They are used to focus on a dedicated biome, a major life zone, with matching environments, fauna and flora.
Section
Each stage is split into sections, which are chunks focusing on a given activity like solving riddle, escaping danger, shooting enemies, …
Objective
And within stage, you have objectives to achieve like picking collectibles, freeing friends, fighting bosses, … Those objectives can be:
- global for a stage or sticked to a given section.
- recurring or one-shot.
- or even optional.
Progress
This semantic is also used to track player progress and be able to resume accordingly:
- Stages are marked as clear (you could be able to run an already cleared one or not).
- Checkpoints store the last section you can restart from.
- And obviously, we monitor objectives to provide rewards accordingly.
Skills
To walkthrough stages, player is empowered by skills he can leverage. Skill usage can be obvious. Or not, at least at first sight. Or to reveal useful later in the game.
Skills are not frozen, they can evolve.
For example, wall run can start by being triggered by the player, then evolve and be automated and automatically trigger when approaching a wall.
Sometimes, player can unlock new capabilities by pairing multiple skills. Or even using skills in an unexpected way, allowing for unconventional approaches…
Rules
Stages obey some design rules, that may involve specific processing, such as introducing timer, involving multiple players, providing shortcuts, … Obviously, we would like to avoid crafting the same rule again and again for every single stage we would like to apply it to. Thus, rules are gathered within library, and ready to be picked, combined and applied to different stages. It enforces consistency among stages, and drastically decreases development and maintenance.
Those rules may have underlying traits or consequences, that in turn could be sorted, grouped and reused.
Multiplayer
- Are players competitors or allies?
- Do they see each other?
- Do they contribute to a consolidated objective, or do they play in their own swim lane?
Shortcut
|
- Is shortcut available the first time we walk through a stage?
- After a first completed run?
- Only once or be traversed as many times we want?
Tooling
Crafting, assembling and delivering above concepts is made through tooling or toolchain. The stronger tooling is, the easier it becomes to develop, maintain and debug the whole ecosystem. Usually, we can leverage at least 3 kinds of tool.
Engine
Engine is an obvious one, as nobody want to start from scratch every time. Here, Child of Light, another famous game from Ubisoft, even if looking and playing completely different, is powered by the same engine.
SDK
Engine alone is not enough and teams up with SDK that support developer journey into shaping and crafting levels.
Tutorial
And last but not least, documentation, for both developer and end-user. Toolkit may end up being released to end-user, enabling videogame modder to create and share customization of the base game.
Closing
We split the problem space, introduce taxonomy and materialize relationships, ending up with a bunch of concepts, namely stage, section, objective, skill, rule and tooling. We could have listed more, but those are enough to shape the game structure. Every teammate can now easily discuss about adding a new stage, shaping a new rule or crafting a new skill. And not only how we develop such features, but also what it implies in term of design, test, documentation, storytelling, resource … and how it integrates in the whole ecosystem.
In videogame industry, this is usually gathered in a document, known as Game Design Document, whose objective is to keep the whole team not only on-track but also on the same track (it’s not the same thing). Obviously, this document should be started early in the project lifecycle. Ideally, it should be updated along the way. And optimally, it should be reviewed at each release to gain experience from.
Now that vision is shared, team can focus on delivering.
On time. On budget. On value.
In the next post, we will see how one could replicate this method to cope with solution design.