Do you actually use diagrams to model games? [closed]

Question

I mean mostly UML but any method that works is viable. So - do you actually model your games with UML/other diagrams or different methods? I had a subject at my university about modelling with UML and it seemed like more effort than actual benefit but I realise that might be only because I've never created a huge complex IT system. So is it worth the while and what types of diagrams/methods are usually* the best?

*Of course, many times concrete tools need be chosen to concrete problems but maybe there are some patterns.

Edit: I forgot one important thing - do you create diagrams before or after implementing stuff? What I mean is - when one designs and implements something one usually changes mind or something unexpected comes up and one has to make changes, sometimes major ones - and doing them in already complex diagrams seems equally hopeless as in the code itself.

Answer 1

I like to think that everything around us can be represented, one way or another, through a diagram. Even if it is just a linear diagram representing the transition between the states of a particular object throughout time (like a living being, going through a number of states from birth to death). I use diagrams to lay down my thoughts and ideas for the actual implementation. I improvise quite a lot.

Therefore, my diagrams are most of the time at a very high level, and feel like mind maps.

To throw some examples in, this is actually a class inheritance map (one that's been cut) in my game where Interactive Object is the base type.

This is an FSM (Finite-state machine) diagram for a spikes trap (those awesome traps on which you step and woosh spikes show up from the ground).

This is a handbook diagram (named this way because it's intended to be a come back to it often diagram) that I drew recently. It outlines the components of a game, and also helps with gathering the required assets, as you can see immediately what's needed and what isn't. I recommend these on small projects, as they get pretty huge on big ones. They can be broadened further though, so that may fix things.

When I go to a lower level, it's usually because I need to plan the most intricate aspects of my architecture, and I usually deal with UML there. I never concentrate on outputting absolutely clean and correct UML though. I've adopted what I liked the most about the UML convention, and turned it into a nice mindmap-ish UML. It's simple and does the job for me, but I wouldn't go with it in an environment where actual UML is expected, for obvious reasons.

Another situation when I have to go to a lower level is when I have to describe actual algorithms. I use what I call flow diagrams. It is a format inspired by the diagrams used in white box testing.

A sample for the spike trap that I drew right now would look like this:

This is normally the final layer between diagrams and actual algorithm implementations. If the need arises, I detail the flow diagrams further (with extra executed instructions), and deduce or estimate complexity, and build accurate test cases. I also prefer diagrams over pseudocode.

Not that related to game development, I also have a nice format to describe the screens in a multi-screen app, the functionality that the user can trigger on each screen, and the relationship between screens. I normally build these before starting the actual development, and they act like a map throughout the development process. If it's for a client, the screen diagram is even more useful! It helps me go through all of the project, from start to beginning, and take into consideration all of the functionality that it's going to need. Therefore, it's invaluable to providing an accurate cost and time estimate.

So yeah, I definitely diagram everything and anything. If I have an idea, I can and will definitely draw a diagram for it. If I somehow start a project without at least a very broad diagram to back me up, I feel crippled.

Answer 2

I certainly do - both structural and behavioral - my rule of thumb is that I make diagrams when the cost of making the diagram is less than trying to remember what the hell I was thinking a month later - or when I need to clearly explain myself to some other developer

Class diagrams when the inheritance hierarchy becomes sufficiently complex

Object diagrams when things like instantiation of objects becomes something bordering on the creation of a Frankenstein monster from disparate parts - especially useful in kitchen sink vertex and pixel shader users, to make sure all of the requisite bits are pushed through the pipe

Sequence diagrams when the detailed interactions between a set of objects become complex - this is extremely useful in modeling complex render flows where previously computed information is needed at barely related downstream locations

Answer 3

Diagrams are a great way to communicate, document and aid your design, and design is the most significant part of software development. UML has a lot of features but you are not meant to use them all at the same time, only the ones that are useful.

When navigating in a new city, do you actually stop and look at a map, rather than just continue and follow signs? That's what design vs coding is about. When things are unfamiliar, when the problem is complex, when you feel lost, that's when thinking about design is most helpful, and it's better to do it earlier than later. It's much easier to change your design before you've implemented anything.

Diagrams are a great way to visualise the problem and help your design, especially for visual thinkers (which is most of us on gamedev I'd imagine). A lot of problems become trivial, defects become obvious, when it's clearly mapped on a diagram. Some issues you may find in a diagram:

• Too many connections to a single component? You may have a god object that is hard to maintain
• Too many interconnections? Maybe the modularity can be improved, to make the architecture less fragile
• Too many pathways between two components? Perhaps you have tight coupling
• For high-performance applications such as games, are there too many components involved in the hot path or inner loop? This may impact your performance
• Most of the time however, the diagram will show inconsistencies between the design you envisioned, and the actual implementation

Furthermore, diagrams are great for communicating and documenting your design, either to non-technical people or people who are new to your project - and remember, in 6-months time you are practically new to the project too!

How you use UML should be driven from these considerations. Diagramming for your own sake? Use whatever notation you are most comfortable with. Collaborating with other developers? Try to include the details of API calls, message types, directions of dependencies. Discussing architecture? Black boxes and simple connections will suffice. No-one uses the full set of UML features anyway, plus it is very useful as a set of standardised notation that many people understand - whereas my napkin doodles may be incomprehensible to you and vice versa.

As for myself, I use diagrams all the time - simple notepad drawings for personal projects, simple UML diagrams at work. This UML diagram is what I'd consider too complex, and one that I'd never make because the cost of producing and maintaining it outweighs its benefit, but of course YMMV.

Answer 4

I'd say there are two types of diagrams. Formal diagrams and scribbles.

Regarding formal diagrams, I do them when I'm working with other programmers, but I rarely do so when I'm programming alone.

However, that doesn't mean I sit and code whatever comes to mind. In my opinion, the most important thing when programming (or actually anything in life) is to think first and do later.

Coding is a very mechanical task. You type and words appear on the screen. The idea is that by the time you start coding, you should have already solved the problem at hand. Making scribbles is a great way to sort your thoughts, and even force yourself to do the thinking that you need to do the coding part correctly. Scribbles are not meant to be saved for future reference, just so you can understand your thought processes easily.

Don't worry if you take too much time thinking. I think that a good balance happens when you dedicate 90% of your time thinking and 10% coding. I've met several "senior" programmers who live by "we don't have time to think, just to do". But even if they call their code "done" earlier than those who do take the time to think about what they're doing, they (or the unlucky souls left afterwards) then spend countless hours fixing and patching something that should have been built correctly from the beginning.

The best thing is that thinking is free! you don't have to be sitting on your computer to think. You can think about the code while you're eating, commuting, exercising... In fact, the best ideas come when you least expect them, so keep your mind open at all times, and only start coding when you really know what you're going to code.

Here's a related article that I happen to agree with.

Edit: Regarding the actual format and type of diagrams, I'd recommend you go freestyle, and actually handwritten instead of using prepackaged tools. Remember that the point is to help you in your thought process, so feel free to draw whatever you like. Semantics are whatever you like them to be, and they may be different between diagrams, and even between different parts of the diagram.

There are three main benefits with freestyle/handwritten diagrams over prepackaged tools:

1. You're not forced to abide to the type of diagram supported by whatever tool you choose. Sometimes mapminds will work, sometimes something more like UML will be fine, while other times a logic diagram will do. Other times a completely custom diagram is what works, and no tool can give you all the flexibility of freestyle diagrams (try punching a hole through the paper and continuing on the reverse side of the paper, in your favorite package, and see what happens)

2. You will spend more time actually diagramming instead of using the tool. Regardless of the tool, pen and paper is always faster at diagramming than keyboarding and mousing through menus to find the specific elements you're looking for.

3. You don't need a computer to handwrite. Most of the time I'm doing complex designs, I do them in a library, a cafe, or even inside an airplane. Also, good ideas always pop up in the least appropriate moment, so be sure to always carry something to write with, and something to write on.

Answer 5

It may be worth pointing out a few design diagram talks from the Game Developers Conference 2013. These are some very practical and road-tested examples -- and it seems they've been presented at many conferences across the years.

(The other answers have done an admirable job of demonstrating why and how design-focused diagrams can be tremendously helpful in planning, building, growing, and maintaining a codebase, so I'll leave that aspect alone, and trust these resources might be useful to anyone visiting the question.)

Joris Dormans and Ernest Adams discussed the Machinations game design/balance diagramming system. (Here's a paywalled GDC Vault video from GDC EU 2012; samples from GDC 2013 on Dormans' wiki.) Rather than attempt to paraphrase, here's how the wiki describes the system:

Machinations is a theoretical framework and an interactive, dynamic, graphical representation that describes games as dynamic systems and focuses on closed feedback loops within them. The intention is to find a way to express and investigate (recurrent) game structures methodologically. Machinations offers a new lens on the intuitive and delicate practice of game design and balancing.

Noah Falstein gave a talk called "The Arcane Art of Puzzle Dependency Diagrams" (paywalled GDC Vault video). I can't find any non-paywalled link here, but various folks have discussed or posted their notes on-line.

Both talks discussed when they created and how they maintained these diagrams, to one extent or another.

Answer 6

You should probably check this article about using a simple abstract grammar to describe your gameplay loop, how it can help you identify design problems, and how easy it is to iterate at that level.

http://www.gamasutra.com/blogs/JoshuaStarner/20130205/186060/Applying_Abstract_Models_to_Game_Design.php

I can also point you toward my own work on the subject, more based on the economics of the gameplay loop, using abstract resources to track things like opportunities, luck or preparation:

http://www.stephanebura.com/diagrams/

If you find this approach useful, you should have a look at Joris Dormans' Machinations, a tool for making such diagrams and running their simulations:

http://www.jorisdormans.nl/machinations/

His whole process is explained in his book:

http://www.amazon.com/Game-Mechanics-Advanced-Design-Voices/dp/0321820274/