What is the equivalent of a functional specification for games?

As everything in software engineering the answer is depends rs

There is no silver bullet, as Brooks said, so there is no "equivalence", even why these practices / documents you cited are not unique to " systems ".

In addition, a game is also a software. So what prevents a game from adopting one or more of these practices? Absolutely nothing.

You have cited several practices at different levels of abstraction, which makes the issue very broad and makes an "exact" response difficult. Also, why is not it useful to have a technical specification ? And why not coding standards and standards for the project ? Again, nothing prevents the application of one or more ES practices in game development.

Specifically regarding your question:

  

What is the equivalent of a functional gaming specification?

Nothing prevents the use of use cases, user stories, business models with their rules, etc. However, due to some specifics, it may take a lot of work to document only those practices that are better known by the market " conventional ".

In the case of games there are also widely accepted practices. An example:

• Game Design Document : with GDD it is possible to represent various aspects of a game such as technicians (class and components, for example), of graphic design and also the functional ones, like the history of the game (like to reach objectives, for example), its personages, etc. There are lots of references and examples about GDD on the web, maybe it will help.

Another consideration for another question:

  

Are there formal tools to make it clear what you want to achieve?

Well, you can put any practice into a formal ES method. If it is always functional and necessary, there are already another five hundred.

Finishing and remembering, there are no hard standards in ES, you can adapt existing practices, compose your own mindset, evolve according to your needs and always go beyond =)

I do not have much experience in games, certainly other users can provide more valuable perspectives, but in the few that made the most important diagram was the States Diagram .

In a game with many variables and where many things can happen, just like in any complex business rule, it is necessary to delimit very well which actions can be performed at a given time and what the consequences of each action.

See, the game may be in E state. A A action causes the game to change to the E' state, but a B action would cause the game to change to the E'' state.

Of course you will not have a global diagram with all the states of the game, but one by mutable element . The character can have the states saudável , ferido , cansado . A weapon can have the status carregada , precisa recarregar , sem balas .

It is important to organize the elements of the Game well and define its states or it will end up with a tangle of IFs and confusing logics that always end up in unexpected results.

Regarding the rules of the Game, each type will require specific documentation, according to the rules that guide it. In an RPG game, for example, you will probably use and adapt the rules of a traditional RPG, while in a sports game you can use and adapt the rules of the sport in question.