21
\$\begingroup\$

In my university, they always emphasize and hype about UML design and stuff, in which I feel it is not going to work well with game structure design. Now, I just want a professional advice on how should I begin my game designing? The story is I have some skill in programming and have done many minor game such as getting some 2D platformer working to some extend. The problems that I find about my program is the poor quality design. After coding for a while, things start to break down due to poor planning (When I add new feature, it tends to make me have to recode the whole program). However, to plan everything out without a single design flaw is a bit too ideal. Therefore, any advice to how should I plan my game? How should I put it into visible pictures, so that me and my friends are able to overview the designs?

I planned to start coding a game with my friend. This is going to be my first teamwork, so any professional advices would be a pleasure. Is there any other alternatives than UML?

Another question is how does "prototyping" normally looks like?

|improve this question
\$\endgroup\$
  • 26
    \$\begingroup\$ UML is bullshit. It's a badly designed paradigm to make businessmen feel like they are producing and understanding something while they actually are only creating useless constraints. \$\endgroup\$ – o0'. Apr 22 '12 at 10:40
  • \$\begingroup\$ Although I definitely think that UML has a place in business software it's not designed for designing anything too interactive. Try to find some Game Design Documents for existing games to see how they handle the formal stuff, something like this: delta3d.org/filemgmt_data/files/… also try to keep in mind to do a lot of prototyping and don't be afraid to 'throw away' stuff (here throw away means shelf in your source control system and not actively using it). \$\endgroup\$ – Roy T. Apr 22 '12 at 11:11
  • 4
    \$\begingroup\$ I use xmind to plan just about everything. I wouldn't use technical thingy like UML unless I'm forced to. It's important to visualize things before going technical. Mind mapping is your friend. You can use it to plan technical things too. \$\endgroup\$ – He Shiming Apr 22 '12 at 11:23
  • \$\begingroup\$ Imho, the big problem with UML is the lack of tools to convert diagrams into e.g. class and function declarations and vice versa. UML is a great tool to visualize and communicate ideas between team members, but the way most UML workflows w/o tools have you do certain things twice makes UML overkill for small and/or hobby projects. Personally, I'm using pen and paper to visualize relations between classes & entities in some sort of pseudo-UML. It's nice to get an overview over class interactions and hierarchy. \$\endgroup\$ – Exilyth Mar 18 '13 at 10:44
18
\$\begingroup\$

I just want a professional advice on how should I begin my game designing?

Game design is the specification of the gameplay, the assets, the scoring systems, etc - these are not software-specific. As such, UML is the wrong tool for that task.

When it comes to designing the code to implement these systems, UML is a good tool for the task, providing your team know it, and stick to the more common diagram types. Normally, when trying to design a feature, you will know whether you need to use a description or a diagram. If you do need to use a diagram, UML gives you a standard way of drawing it, which is a good thing.

After coding for a while, things start to break down due to poor planning (When I add new feature, it tends to make me have to recode the whole program).

That is generally a problem with the way you program, rather than how you plan. Good software usually is easy to extend and reuse. If you stick to good programming practices, this problem will decrease. But better planning will help also, and you don't need complex diagrams for this. Just having a list of features will mean that when you code one thing, you have the other features in mind and can consider them as you code.

Therefore, any advice to how should I plan my game? How should I put it into visible pictures, so that me and my friends are able to overview the designs?

It sounds like you're mixing 2 problems here, the game design, and the code design.

I suggest first writing out a basic game design, specifying the features you need, the graphics and sounds you need, how the game is won and lost, etc. Look up 'design documents' if you need some help there.

From there, you will have an idea of the features that you need to code up. You can look at each feature in turn and try to think about how to implement them. Diagrams can help to show the relationships between different classes and objects in your game but the skill of knowing which objects need to exist is something that you have to learn through practice and/or further reading.

Also, try working on smaller, less ambitious projects. That will get you used to writing good, working code, without needing extensive planning or rewrites.

|improve this answer
\$\endgroup\$
  • \$\begingroup\$ I guess I mixed it. I think I could say I really have some rough game system ideas. However, I would like to know how can I effectively tackle my "code" design problem? Or in other word, translate my game structure into code effectively? I usually have to choose between taking lengthy-time to generalize the code or rapid specific coding. Usually the first one took hell out of me, so I went on second one and later bump into a wall... \$\endgroup\$ – user1542 Apr 22 '12 at 12:33
  • 2
    \$\begingroup\$ It looks like you're still inexperienced with software modeling (modeling is the process of translating abstract design into concrete implementation). I'm afraid that this will only really get better with experience. A good way to check if you're making progress is to look at 6+ month old code of yours from time to time. If you don't find anything that you'd write differently (or just plain better) if you rewrote the thing, then you probably haven't improved in that timespan. \$\endgroup\$ – TravisG Apr 22 '12 at 19:02
  • \$\begingroup\$ Agreed with heishe - experience is the only real solution here, combined with learning to make the experience count. Try to read about and understand basic concepts such as encapsulation and abstraction, more complex ones like the Law of Demeter and the Single Responsibility Principle, and understand Design Patterns well enough to see where some may help you. That knowledge, combined with practice, gives you the tools to translate ideas into working code. \$\endgroup\$ – Kylotan Apr 23 '12 at 12:03
2
\$\begingroup\$

Not understanding something makes it easy to dismiss. The UML is an engineering tool used to communicate the ideas you have in a structured way. A game is a system which can be engineered like any other. If anything, a game's complexity and dynamism makes a visual representation of it's parts and their interactions invaluable.

The UML diagrams are different views of a model of the system under discussion. I start with use cases for a person sitting down in front of my program and starting it. In the case of a game there are two kinds of users: designers and players. I write a use case for each of the things I can see them doing. Then I make some CRC cards to figure out what services I need to provide. Then I make a class diagram for the interfaces that will provide these services and their relationships. This is based on the CRC cards. Next come dynamic diagrams for events like initialization which require planning and orchestration. Then more detailed static diagrams showing the classes implementing the interfaces.

All the while I am writing code and prototyping and evolving it in the direction of providing the services to support fulfilling the requirements of my game. Nothing gets built that doesn't support the user through the use cases. I write some useless diagram elements, but between the interface coding and the diagramming I write very little useless code. Diagramming gives me confidence that I understand the way the class I am writing fits into the whole system.

The point I am trying to make is that a trivial program can be written without plans, but a game is anything but trivial. Some time ago, when OOP was new, there was a lot of experimentation and some best practices came to the fore. The software development community agreed that we needed a language to write about and analyze software designs. The UML is the language we developed. We all know and understand it, so if you want to use other people's solutions to your problems (books, online discussions, articles, pattern catalogs, etc.) and not reinvent the wheel you must learn to read the standard notation. As a bonus, when you force yourself to think about your system in another language, you learn unexpected things.

Many different methodologies exist, but they all identify the problem and describe one solution in a systematic way. This is engineering. The UML is huge and complex, but no one model uses every construct. It is like a Swiss army knife. You have to get to know it and figure out how to use it to support your engineering process. The important thing is not which process or methodology but that you have one. Otherwise you will drown in complexity.

|improve this answer
\$\endgroup\$
2
\$\begingroup\$

I'm also working on some independent game projects with a friend (2-person team). As someone in a similar situation to yours, I can offer a few tidbits that I've found helpful.

  1. If your ideas are rough, try implementing them one at a time in super tiny prototyping projects. For example, I am making a 2D platform game now, and getting the player's jump right is extremely important to me. So, I made a new project where the only 2 things that happen are a) Drawing the player on the screen, and b) Detecting input, and redrawing the jump [character cannot even move left or right]
  2. Some people might frown on this piece of advice, but think about writing the game manual first (to explain the concepts, controls, objectives). This can do 2 things for you -- generate a much needed document, but also outline the subsystems of your game and any necessary details for the player. If you know in advance what the player needs to know, then you know in advance what you need to do.
  3. Write code in small enough (aka modularized) chunks that the factored pieces can be either moved around, or better organized without feeling like you're trying to remove all of the mid-sized pieces of spaghetti from a plate of pasta.

Hopefully you found at least one useful piece of information in there, and good luck!

|improve this answer
\$\endgroup\$
1
\$\begingroup\$

I think there are some valuable takeaways from UML that you can't deny. on the other hand, keep in mind that UML was built for business processes, you know, modelling systems that have a lot of people interacting with it, all with different wants and needs and desires. UML tries to make sure you don't leave anything out or get overwhelmed by detail.

UML is "a standard way to visualize a system's architecture"

UML describes

  • activities
  • actors
  • business processes
  • database schemas
  • (logical) components
  • programming language statements
  • reusable software components

But if you're making a simple game, do you really need to model all this?

  • Actors: The player.

How much does that help?

Modelling some of the other things though, is very helpful. For example if you're making a small MMO, you definitely want well designed data base schemas.

So while the take aways from UML are excellent (know what you're doing, write down the requirements, and sketch diagrams of flowcharts wherever it is needed), and elements of it are very useful, I tend to feel the full UML process is a bit of a square peg round hole for games.

|improve this answer
\$\endgroup\$
  • 1
    \$\begingroup\$ Actors: designers, artists, network players, (if you are lucky) financial backers, qa people. Communication between designers, developers, clients, end users and programmers is abysmal at best in every branch of the software industry that I have seen. UML is a tool to give the stakeholder's a common language to discuss a project. There is a degree of hostility in the development world toward things like documentation(programmers) and source control/collaboration(designers) that really drags down the quality of the ultimate project. Most of these things are built by teams, so we need to share. \$\endgroup\$ – Sinthia V Jul 3 '12 at 22:22
  • \$\begingroup\$ @SinthiaV Actors aren't meant to be the dev team. Actors are meant to be the people that interact with the final product. \$\endgroup\$ – bobobobo Mar 19 '13 at 15:57
  • \$\begingroup\$ What about level/resource editors and engines? That was the use case I was referring to. \$\endgroup\$ – Sinthia V Jun 1 '13 at 4:34
0
\$\begingroup\$

UML is not one thing it is a collection of things some of them have value others not so much. the older style Use Cases (at least what we call use cases) that state

  • name
  • requirements
  • preconditions
  • triggers
  • actions
  • alternate actions
  • exceptions

can be quite useful. though what you find for "Use Cases" if you do a web search (the pictures) are more for general software.

I would also put some credit to the Class diagram. this shows that you are able to show the relationship between all of your objects, and that you know the layout of your architecture.

what it comes down to is that your feature set should be all planned out, and locked int (at-leased in a need/want setup) before modeling, and diagramming is even started. these should be all in your Brief/Treatment/Script (sometimes referred to as pitch, features document, and story). then from there you would do up your tech doc stuff that has your models, and diagrams.

there are companies that use UML, but these are usually companies that have separate design and implementation teams. the companies that will create all of their documentation, and then give it to a team of code-monkeys to create an prototype/alpha. its said that if you can model your game accurately you should be able to give it to a completely different team and have them program it though this is more a pipe dream then an accuracy.

|improve this answer
\$\endgroup\$
0
\$\begingroup\$

They will be teaching you about UML at your university to help you communicate your ideas to the rest of your team, and show lecturers you have a good working knowledge of basic software engineering principles.

Like any discussion over language, tools or design - it usually comes down to how YOU use it. Pick the best tool/language/design for the job and back up your choice with a strong rationale. I'll admit UML is not so flexible for game production, although I can say that we have used it effectively to model engine features such as network communications and timing, parallel task management and use cases. There is nothing worse than explaining the same thing to 5 different team members 10 different times because they don't quite get it. Here's the documentation, read it.

Depending on how solid you designs are, and how disciplined your team is, it can be quite productive to be able to model your own constructs around those that haven't even been started yet, and yet know exactly how they will operate due to the documentation.

In spite of this, you will probably hear (and realise harshly) that these are LIVING DOCUMENTS, and unless they are reviewed and updated regularly, they will be become obsolete fast and effectively useless.

|improve this answer
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.