Get the latest Education e-news
 
  • When Should I Stop Preparing and Get to Work?

    [09.12.17]
    - Bartosz Olszewski
  • Originally published on Games Architecture blog.

    In indie game development, roles in a team aren't as purely diverse as they are in bigger studios. In a crew composed of several people most of them are probably doing more than one thing. When you're working alone, this is unavoidable.

    I noticed that the role that is the most often distributed over the team members is designer. The general underestimation of that function may be the reason. The designer's profile is often reduced to the 'idea-guy.' Most of us have many excellent ideas, so what's the point in having a designer, right? Whether your crew has a designer or not, you probably have some kind of design document or game vision that you and your partners share. Or you may think that everyone has the same image of the project, while the truth may be quite different.

    On the other hand, you all may be very insightful designers, that have an accurate design document, but it may be just a waste of your time and effort. The 90% of it may be just rubbish. Yes, that's a bit harsh, but I'm not telling you that IT SURELY IS trash. I'll just try to explain how can you find out without so much work being wasted.

    How can a lack of a design document be dangerous?

    Let's start with a more typical case. If you don't have ANY design document and a whole vision is in your head, you can't share it with the other people in a 'healthy' way. You can try, but it seems almost impossible to remember all the details and keep track of them while you're working on the game. Too many ideas pop out and mix during the development time. Your and your peer's visions will go different ways at one point. It may cause wasting time when you need to explain it to them over and over. It may also lead to conflicts, as your team pursued different game than you did.

    In my opinion, having the document is important even if you're a lone wolf. First, because if you make a change in the document, you can immediately read through the other dependent sections and think if the change makes sense for the other aspects of the game. The second reason is that it is much easier to write down tasks on Trello or Jira and prioritize them if you've got a well-constructed document. I'll explain what I mean by 'well-constructed document' in a moment.

    How can too much of a design be harmful?

    Here I'm assuming that you're NOT working on 1 to 1 clone of some other game because in this case all their mechanics are defined, and a symbiosis between them is already tested. When you're working on a new (at least not-a-clone) idea, you can rarely be sure that all aspects of it fit each other before you actually play it.

    We're living in an era of unselfconscious design, which means that we lack the tools that will allow us to prepare a whole design before development. For now, design and development go together till the end (well, to be accurate, the design usually starts a bit sooner). You probably already feel why too much design can harm you, but let's say it out loud. Too much design is likely to be a waste of time and effort because non-fundamental decisions are based on a core that hasn't been examined yet. If you'll make a playable demo at some point and you see that your main mechanics are just not fun, you don't want to have many hours spent on designing behind you.

    For every game concept the margin of 'too much design' may be placed somewhere else. For example, if you're making an 'FPS with a jetpack' you can probably start to implement FPS mechanics right now as they are pretty the same for the whole genre and have been tested many times. In the meantime, you can prepare a design for the jetpack. How high it should fly (to the sky, buh-bye), what its velocity should be, and how strong inertia it should have? Does it need a fuel? You've got the point. And then you can think of a level design already because it strongly depends on the jetpack's capabilities. After that, you can go to the enemies' project, because their behavior depends on the jetpack and level design. Go to the next layer of design, if the underlying one has been well thought out.

Comments

comments powered by Disqus