How Much Planning - High Level Concepts?

Hmm, not many comments on that last post.  Guess it was just Too Damn Long.

Have a long build right now, so I'll respond to a comment.  Pag asks:

Don't you need planning for the higher level ideas though? Iterations work great for low-level features that can be implemented and tweaked relatively easily: controls, enemy AI, etc. But you can't really iterate on high-level concepts. Sid Meier's dinosaurs game died after a while and as I understand it, they still weren't sure if the game would be turn-based or real-time -- that can't have helped production.

Basically, how do you balance the need for a clear overarching vision and the need for flexibility during development?

Don't know anything about this dinosaurs game, but I'd think turn-based vs. real-time would be something you'd nail down in prototyping early on, while there's only a handful of guys on the team and your "dinosaurs" are still flat-shaded boxes - or maybe it's even in 2D and the dinosaurs are just X's and O's - or maybe you even make a board game and move toy dinosaurs around a hex map, faking the "realtime" somehow.  At this stage it's totally possible to iterate on various kinds of turn-based and realtime mechanics.  And at some point you make an informed decision about which you like best and prototype the next thing and eventually go into production.

The "more planning" alternative would be to have meetings, before any code is written (or boardgame mock-ups are created) to discuss why the game should be realtime or turn-based.  You can involve all the stakeholders.  Maybe publishers don't want the game to be turn-based for marketing reasons.  Maybe some of the designers are worried that griefers will ruin turn-based network play, or that it will be boring waiting for your turn.  And you write a document that says the game will be real-time, damn it, no matter what.  And you'll make that game.  Nevermind if you had a new take on turn-based that could have been really cool.  On the bright side, this process probably takes less time than iteration on that turn-based mockup.

This was a hypothetical example, but my real-life experience is that planning is the enemy of creativity.  None of my cool ideas would have gotten done if I'd had meetings discussing whether they were good ideas or not first.  (But maybe I'm just a bad salesman.) 

Oops, build finished a while ago, and I didn't really get to "vision."  Ok - started another build.

What is this Vision thing, anyway?  (An album by Sisters of Mercy, ha-ha.) Real-time vs. turn-based isn't necessarily under the umbrella of Vision.  It's quite possible whoever "owns" this game (whether it's the producer, director, designer, or--my favorite--a hive mind) couldn't care less whether it's real-time or turn-based, as long as whatever they end up with is fun.  Maybe all they care about are the dinosaurs.

On the other hand, maybe from the start, they had a cool idea for a turn-based game with dinosaurs.  "This game is all about turn-based dinosaurs!"  (For whatever reason.)  Well, that's just the box within which the team works and iterates, right?  And yeah, "turn-based" should be in the doc, with all the reasons why, and what that means to you - do I move all my units, then you move all of yours?  We switch-off?  You move while I fire?  Time limits?  Chess clock?  Some of this you care about, it's essential to your vision -  ("Absolutely you only move one dinosaur at a time.  That's final.")  And everything else you iterate on.

Where you get into problems is when the team doesn't share the vision.  Does more planning help here?  Maybe - you can hear them raise objections and maybe sell them on the vision or at least say, 'duly noted' and pull rank.  Does a doc help?  Maybe, if you can get them to read it.  I'll say I've definitely been there, and seen parts of games that I had strong feelings about go in directions I thought were simply wrong.  But the problem wasn't lack of planning or documentation - the problem was simply that I caved.

Note to self:  my builds really aren't long enough to work on blog posts.

And I don't know what happened with the formatting there...too lazy to edit the html.

Comments

[greggman]

Sorry I didn't reply to the last post. I was too busy planning what to say :-p

Sid might actually be a good example. I can't say how he works now but back when I worked at Microprose (20 years ago) Sid would pretty much make prototypes by himself. Back then he used BASIC with little bits of assembly language and his own forth like language called Sid Tran. The point of using BASIC was extremely rapid prototyping. He would sit in his office and tinker with all kinds of ideas. Think of it as having like 5 indie games going all at once. He might spend 3 weeks on one then 4 weeks on another. If one of the ideas turned out to be truely fun, only then did it becoming something a full team might work on. Up to that point it was just Sid and possibly one artist part time.

As far as I remember there was ZERO planning up to that point.

I wish I was motivated enough to do those small kinds of games. I'm generally always bogged down in trying to get some giant system in place so a medium to large team and make massive amounts of assets with lots of freedom. That in itself takes lots of time and so I'm never free to do these prototypes :-(

I pray that at some point we'll all have good enough engines and toolsets that we can stop this insanity and just work on the game.

[davidicus]

.

Paul Rand said, in Design and the Play Instinct, that the play instinct is “an
instinct for order, the need for rules that, if broken, spoil the game, create uncertainty and irresolution.” without play you can't experiment, but you need rules first.

having been through art schools, i've seen art without constraints. none of it was useful. planning actually sparks creativity, in my experience. it deliniates the sandbox.

even Sid had plans while he was tinkering.

planning influences creativity, just as creativity influences the budget.

.

[CDriK]

I think the point of view of the programmer is best described in the book "The Career Programmer: Guerilla Tactics for an Imperfect World".

You should do it step by step.

As a software engineer I agree but that's not the way it works in most company.

For the record, here is the list of actions from the book:

1. Management states high-level requirements.
2. Programmers formalize the requirements in detail.
3. Management approves detailed requirements.
4. Programmers identify testing resources.
5. Management approves testing resources.
6. Programmers estimate duration of design phase.
7. Testers estimate duration of test plan creation.
8. Management approves design and test plan efforts.
9. Programmers perform design phase.
10. Testers begin development of test plan.
11. Programmers estimate duration of estimation phase.
12. Management approves estimation phase.
13. Programmers perform task partitioning.
14. Programmers perform detailed estimate in hours.
15. Management may allocate additional programming resources.
16. Programmers define timeline with incremental milestones.
17. Management approves the timeline.
18. Programmers begin implementation.
19. Testing begins when software deliverables are available.
20. Programmers complete implementation.
21. Testers perform full regression testing.
22. Programmers define integration procedures.
23. Programmers implement installation program.
24. Testers perform full regression testing including installation and integration.
25. Testers approve beta release.
26. Beta testing begins.
27. Testers perform free play testing in parallel with beta.
28. Beta testing complete.
29. Testers perform full regression testing including installation and integration.
30. Testers approve product release.
31. Management or marketing begin distribution.
32. Programmers collapse in corner and sleep for three days.