Is game software design the same as non-game software design?

Question

Is the software design process for a game similar to a non-game? Do developers create UML diagrams? I ask because of the iterative nature of game development, I wonder if creating a UML diagram would just be a waste.

Answer 1

UML diagrams have 3 purposes:

1. Something that university professors can teach their students so that it seems like software development is a universally well defined structured process, and not some cowboy field where everyone does things their way.
2. Being a way of stalling when you want to look like you do some real work, or bureaucratize a process to slow everyone down. Not only does the creation itself take time, but the subsequent requirement that development follows the diagram can greatly slow down or even derail the work.
3. Helping people understand complicated data structures.

Point 1 and 2 are by far the most common.

This mocking is not to say that you shouldn't plan, but your initial plan probably doesn't need so much structured diagramming that a software framework is required.

The most important things for a game I'd say is:

• A list of desired features, and a note on what considerations should be taken when designing the core engine to make it possible to implement them all.
• A rough estimate of performance and possible issues, you don't want to have to deal with structural performance issues when the game is halfway done.
• A plan for the gameplay. Story, theme and artwork can all be tagged on later, they are not mandatory at this stage, but if you haven't got at least a sketch of what mechanically makes the game exciting to play you won't have any direction for the work.

If you do prototyping you'd probably want to first do a quick round of planning, then do the prototype, and then make a more thorough plan.

As the work progresses the plan should continuously be adapted as new knowledge about the game is gained.

@everyone Is there anything else the planning list should contain?

Flamebait disclaimer: UML is a tool, some people regard it as a solution, which is wrong and potentially dangerous. There is noting wrong about UML itself, only the way it is sometimes (mis)used.

Answer 2

Yes, software design for games is very similar to non-games -- which is not to say that game developers create UML diagrams (because not all software design involves UML diagrams).

Software design is a very varied process and the methodologies employed will differ widely between companies and individuals. But at the end of the day, games or non-games, it's all just software. The requirements may differ but the fundamentals are similar.

Answer 3

Most game development teams have been doing Agile since before Agile was a buzzword.

Answer 4

I think game development adds one step to traditional software developent, and that is creating some game art and sounds to demonstrate the look and feel. Since this is much more important then in regular software. In developing regular software you could work with mockups to show wich elements are positioned where and when on the screen, this would work for the gui part of the game, but the overall look and feel is best demonstrated using real art.

Most features in a game could be put in UML diagrams, entity diagrams and a database diagram (i think most games use some sort of internal database system for all the data)

Answer 5

I would say that game development is very different from software development. Mostly because game are artistics, while software aren't.

Actually I think it's closer to an animation movie than a software. Don't forget you're doing it for fun.

But I may be wrong, because I've never worked professionally in any domain.