How game designers can go from abstract idea to dev-ready tech specs

This post covers the whole journey, with examples of technical specifications and tips from game designers.

When a game designer comes up with an idea for a game mechanic, it just exists as an abstract idea in their mind, with no specific implementation details. So, in order to bring it to life, the game designer needs to clearly and unambiguously describe this idea to the developer and to create working mechanics based on this idea.

Game studios write technical specifications for this purpose (this is sometimes called a design document for a separate feature), where the game designer describes in detail what they want to achieve, the features the mechanics should have, and so on.

In this post, we’ll answer questions about how studios generate technical specifications, the details they should include, whether or not references are needed, and much more.

To craft this text, the following people shared their experiences: Lead Programmer Oleg Ageev, Lead Game Designers Mikhail Sipсov and Oleg Snisarenko.

The structure of technical specifications

In different projects, the structure of technical specifications may differ, but regardless, the main purpose of the documentation is to convey to the artist the list of requirements and conditions for the game entity in a simple and unambiguous form.

In our development process, in addition to the description of the mechanics, we also describe how this action looks from the player’s point of view. In other words, we describe the desired effect of the feature.

Mikhail Sipсov, Lead Game Designer

When generating technical specifications, it’s useful to go from the general concept to the specific. In practice, at the very beginning, we describe the general operating principle of the feature: for example, “We’re adding the ability to do somersaults. When the character is rolling, they’re invulnerable.” Then, you need to consistently describe the mechanics, breaking the information down into parts, describing it in detail from the point of view of gameplay, settings, and so on.

When describing mechanics, emphasis should be placed on logical relationships and constraints. It’s important to describe a clear sequence of actions within a specific mechanic, as well as various use cases. If we continue the example with the somersault above, then the description of the mechanics should include this:

• Whether the move can be used during other actions; if it interrupts the current action or not
• Whether other actions can be performed during the roll-over; for example, if the character can use potions during this action
• How the character interacts with other objects during the somersault; if they break objects when passing through them
• If there is a dependency between the parameters of a roll-over and the characteristics of the hero; for example, if a hero in heavy armor can do a roll-over for a shorter distance

When drawing up technical specifications, a game designer must mention the main parameters of the mechanics, without indicating specific numerical values; it’s important for a game designer to be able to change them independently, trying different options in the future. For example, for a roll-over, this could be range, speed, and duration of invulnerability.

It’s also worth noting that technical specifications are used, not only by game designers and developers, but also by other team members. For example, QA specialists use technical specifications to check whether the mechanics are working correctly. In some cases, the performer or customer of a specific feature may change, and the technical specifications will help preserve the original idea.

What kinds of references are needed?

References significantly simplify the work, and the more complex the entity, the more useful they are. Depending on the situation, you might get by with a diagram, or could attach a link to a video from YouTube. Most often, references are needed if a game designer isn’t confident that a mutual understanding with the developer has been achieved.

Another option for a reference is to make a prototype yourself. This is usually not required, but at some studios, game designers implement mechanics using internal tools. And, if the task is too complex, the game designer turns to developers for help.

For most of the new pawns in Rush Royale, there is a pre-production stage, during which we assemble something as close as possible to the desired result from blocks, simultaneously setting tasks for new mechanics for developers.

The more prototypes a game designer makes, the more mistakes they can anticipate. Fewer adjustments mean you get more work done on time, and have fewer complaints about “raw design.” So, prototype creation, maybe not even for your game, but “to feed the soul” is a solid recommendation for any game designer.

Mikhail Sipcov, Lead Game Designer

Examples of technical specifications

A technical specification directly depends on the project and the mechanics that need to be implemented. For clarity, we’ve decided to provide several examples of technical specifications that differ in content, but with generally similar structures.

Blade Dancer

This mechanic is designed for Rush Royale, a game in the Merge Tower Defense genre, in which users place pawns that shoot at enemies as they pass by. Monsters try to reach the castle gates and destroy it, and meanwhile, pawns shoot at the enemy, increasing their damage or changing certain parameters when positioned correctly.

Here’s a text description of the Blade Dancer pawn:

“Attacks the first target. If there are no other dancers in the neighborhood (on the nearest cells horizontally and vertically), it goes into enhanced mode, increasing its attack speed and damage. Damage increases with the number of dancers on the battlefield. The maximum bonus is achieved with eight dancers.”

The Blade Dancer pawn in the game

The pawns are some kind of universal entities with unique mechanics. Moreover, all pawns have standard parameters: for example, “damage” and “attack speed”.

To make a Blade Dancer from a basic pawn, you need to implement the following mechanics:

• The pawn should shoot at the first target (there may be other options, for example, the target with the highest health rate, or the boss).
• We must check for nearby pawns of the same type.
• We must check the number of pawns of the same type on the table.
• There should be a bonus for pawn parameters if specified conditions are met.
• There should be limitations on parameter growth.

It turns out that dancers receive the maximum increase in characteristics with this arrangement

As a result, the Blade Dancer has several characteristics, which are configured by the game designer:

• Damage
• Interval between attacks
• Acceleration
• Fighting spirit
• Minimum gain
• Maximum gain

The mode switching mechanic look like this:

“Has 2 weapon mechanics. Provided that the neighbors’ count is equal to 0, the change in parameters specified in PawnBladeDancer_NeighborAttackChange and PawnBladeDancer_NeighborIntervalChange begins to work.”

Zombies falling from pipes

In this next part, we’ll talk about the mechanics of “delivering” zombies to the battlefield in an isometric shooter.

“We need zombies to fall out of pipes. The pipes can be of any shape and size. Zombies will fall out according to standard splines, which will be pre-configured in the scenes.”

I propose to make a new component that we hang on the unit. In it we indicate:

• The bone to which we attach the ragdoll to the spline
• A list of colliders for which we disable physics during the fall
• The minimum speed with which we drag the unit along the spline.

We need to add a checkmark to the spawn points, which will tell us that from here we will spawn according to the following logic: the unit appears in the form of a ragdoll and goes along a spline. All this time, it’s completely invulnerable and cannot be targeted. At the end of the spline:

• Transfer the unit from ragdoll to normal mode and turn on the animator
• Pull the Spawn trigger in the animator
• Activate other logic (you can select it as a target, cause damage, and so on)

As a result, zombies are invulnerable during “delivery” to the battlefield, but immediately after spawning, they become valid targets.

Ability to determine and compare the angle of avatar movement

This mechanic is intended for a third-person action RPG.

What needs to be done: depending on the angle of the avatar movement relative to the cardinal points (wind directions), speed the avatar up or slow it down. For example, if the wind is blowing north and the avatar is traveling at an angle of no more than 45° to the north, then it should accelerate, and if it’s more than 135°, then it should slow down.

Build option: while moving, compare the avatar’s angle with the desired value overtime using PredicateGreater and, with certain comparison results, apply slowdown/acceleration buffs. Perhaps even try to scale the speed relative to the angle.

Here, you need a calcer that can determine the angle between the avatar and the locator or the angle of the avatar relative to the absolute coordinates of the world.

There is AngleCalcerToLocator or AngleCalcerRelative, they were made for the EffectSpin effect to set the rotation angle. But these calcers cannot be used with PredicateGreater (you cannot even combine them into a design document). I would like to make these calcers work with a predicate or invent another way to calculate the angle of movement of the avatar.”

Tips for game designers:

• Let the developer read your technical specification and ask if everything is clear; perhaps something is missing, or they have no questions.
• Don’t forget that both you and the developer want the same thing: to make a great game together. And if something is implemented incorrectly, it’s definitely not due to the developer’s ill intentions.
• If a problem arises, it’s worth figuring out why it happened and deciding how to avoid it in the future.
• The most common problems arise from the fact that the technical specifications are not clear enough, not detailed enough, or because some changes were made to it during the development process.
• While working on mechanics, the game designer must communicate with the developer to make sure that the idea is understood correctly and the technical specification contains all the necessary information.
• The better the game designer understands the technical side of the project, the more accurate and understandable the specifications will be. Therefore, always learn the details of the engine and technologies, communicate with developers, ask them questions on the topic.
• In the technical specification, the game designer should focus on what should happen in the end, not on how to implement it. Often, it’s the developer who understands which solution will be most suitable. But, if a game designer has development experience and is confident in this area, then they can offer the solution in the technical specification.