Getting a game done: Planning vs. Doing?

[whisperstorm]

I've been working on various game projects - which all seem to stall out after awhile. I've been taking the approach of just jumping in and doing it - coding some, some art, etc. however it seems like I just end up at a dead end.

I know of many folks who spend time planning out their game forever and never get to the coding phase. So that seems like a dead end as well. Is there some kind of middle way that folks do to actually get a game done?

[wazoo]

This is definitely a huge barrier.

What's working out for me so far is a bit of both. I sketch up some base documents, jump in and code the game's "shell".

Then jump back out to do more document/design, then back into producing code to test out these ideas.

Rinse and repeat.

/shrug

No "perfect" way to do it IMHO, you've got to hit your stride and find out a method that works for you.

[mot]

I just end up at a dead end.

What kind of dead end? You run out of ideas, out of time or out of interest? If it's the latter you probably won't ever feel right making games anyway, so find something else. If you don't have ideas, try reading more books, watching more movies and playing games that you like.

Also if you're still thinking about what kind of game to actually make, do some prototypes - perhaps one or two a week. Think of them as something you will throw away even if it's good but have to do to find something what works and move on.

Once you settle on something you only need one thing - focus.

[whisperstorm]

Thanks for the advice - the prototype idea is a very good one - easier to try out things to see if they work before investing a ton of time and resources...

[Coyote]

I plan in stages. Too much up front tends to lead to "analysis paralysis" and overplanning. Insufficient planning before you get cracking on execution can lead to serious stalls in progress and too much re-work.

When I hit one of those stages where it feels like I hit a wall (this can usually be identified by the fact that I stare at the code for ten minutes wondering what to do next, and then find myself seeking distractions like playing a game or surfing the web), that's when it's time to re-plan.

You've made it from point A to point B. To get all the way to Z, you need to figure out how you get from point B to point C, and so forth. Think of what steps it will take to get you there. Think of what is most critical, and what will get you the biggest bang for the buck. Don't be afraid to backtrack (http://www.rampantgames.com/blog/2006/02/fighting-procrastination-local-maxima.html) a little if you need to.

You may hit a wall - soft or hard - several times. To me, that just means it's time to take a step back and do some "big-picture work" so you know where to go next.

[Twitchfactor]

I keep telling the people I'm working with, "You can't MapQuest without an address". Planning is VERY IMPORTANT. I find this whole "jump in and see what happens" attitude only leads to "playing around" and never actually getting anything finished. Or if it does actually get finished, it takes 5x longer than it would've been, had I just said, "Goal A = Blah, Goal B = Blab Blah Blah".

Even just a simple outline should be sufficient. Unless you're just blatantly copying something, then just fire up the game you're copying, take notes (oh, there goes that planning thing again... oops...) and go.

[GolfHacker]

I had the same problem, until I realized that the games I was designing were way too ambitious for one person working part-time.

My advice is to start with a small game, like maybe a simple arcade or puzzle game... something you know you can finish within 2-4 months time. Once you get your first game done, it gets a lot easier to see projects through to completion. Then you can gradually work your way up to lengthier projects. But you've got to get that first game completed!

In my case, I started with a simple puzzle game - that's how Fashion Cents was born. It has been a very good product for us, and continues to generate a steady monthly income, even after 2 years.

[Grey Alien]

I make an overview plan of the whole project with any details that inspire me at the time (but not many). Then I start work on it and before I do each section of the overview, I flesh it out in detail and do that. Then you have small achievable tasks you can tick off and feel good about and when the whole section is done it can be crossed off the overview. Plans work for me as motivational tools and also when I sit down at my PC I know exactly what to do next. Also of course you can prioritise every part on a plan so you know what is essential and what is just a wish list item (move these to another section to unclutter the main plan). If you've got any time left at the end (you won't have) put in some of the wish list items.

[Rod Hyde]

Is there some kind of middle way that folks do to actually get a game done?It might be an idea to work with someone else, or find someone who will take an interest in what you're doing. Developing software can be such an intensive task, so unless there's someone depending on you it can be too easy to just stall.

--- Rod

[Polycount Productions]

Prototyping is an excellent way to get moving.

[gdunbar]

I have two recommendations:

1) Start with a working prototype (both code and design), and gradually add in more working elements as you work. The majority of the time, you should have working code to run and test against. This is really helpful motivation-wise; you can see your project coming together. Also, it has the nice effect that you don't come to the end of your project and have to do all the testing and debugging at the end.

2) Come up with a schedule based on your bigger milestones, say 5-10. Estimate the time that it will take to do each milestone. Then, as you are working on the milestone, break it down into smaller tasks. By doing this, you will be able to track progress as you go (possibly rescoping your project if you realize you've over or under estimated your capabilities). This should also help your motivation as you can watch the big picture coming together.

But the biggest piece of advice is that making any computer program is hard work. You need to concentrate on it, slog through the hard bits, and not get distracted or demotivated. Not everyone can do this, but it's worth it in the end.

Geoff

[Jesse Hopkins]

What we all need to finish what we start is more time, time, time, time, time.

Who among us has no hinderances? Who among us is fully funded? Nay, I say we need more time, and then we could all prevail. The unfortunate truth handed up by the devil himself, is that Time is Money! Bah!

------------------------------------
Jesse Hopkins
http://www.composerarts.comOriginal composer for your games

[e-funsoft]

I think it depends on the type of game you make.

I used iteration method for my previous game Fruit Lockers, with very simple planning. I made a prototype, tried it to see how it was played, added features, made rules, and so on. So when we made the planning, we didn't know yet how the final game would look. However, everything ran smoothly and painlessly from start to finish. It was completed quickly and very efficiently. We were satisfied with the final game, and it sold quite well too.

However, when I implemented the same method for my last game Wild West Billy, it didn't work. It ended up with I spent too much time and effort to finish the project.

So in my opinion we should treat each project differently, and the need to spare more time on planning vs doing would depend on the complicacy of the game. For simple games we can make a simple planning then simply start the project. Everything else can be decided later on the way. However, for more complicated games with many elements, more and more time should be spent on planning, then we should follow the planning strictly, because even a little change will affect the design, other game elements, etc that will cause great confusion for the programmer eventually, generate more bugs, and so on.

[Tr00jg]

I generally first design some rough ideas and then start some prototyping. After that I usually develop up to a point where I am easily distracted.

Then I usually write some goals down aka planning and stick it up above my monitor. Every time I sit down, I know what I must be doing, which seems to work for me.

I am currently taking a break from my game, re-thinking and designing some levels, and developing my site (which is a nice side-project).

[Applewood]

For smaller projects, I tend not to bother writing down a game design.

If you believe in it, you will have spent much time thinking about how this or that should work gameplay-wise and maybe even how you'd code it. By the time you actually start developing you should pretty much know all about where you're going.

Frankly, I think that if a one-man project needs a design document, then you've over-specced said project in terms of your ability or time available or both. Start with something smaller and see how you go would be be my advice.

[zoombapup]

I had a hell of a time until I met my biz partner and it has been a lot easier since.

The mutual support and encouragement you get (plus if one of us is busy with a contract or something, the other still makes progress).

Forward progress is the most important factor I think. No matter how small, as long as you move forward, then you will eventually reach the end.

So my advice would be to find one other who can help you when things get you down.

[Applewood]

Yeah, that too. When I teamed up with someone at the beginning of Rubicon, we both ended up punting more work out than we did 2x individually.

Finding someone with complementary skills is a real boon in a variety of ways.

[Studio_Cobweb]

Excellent thread

From my experience, be loose and sloppy and go crazy and experiment in the prototype phase, but once it's gelled, plan it out in some kind of design document, and gooood lordie stick to that sucker or you'll go all over the place inevitably as you come up with countless tangental ideas and features that tally up to a lot of dead ends or make the whole thing even more complicated. Marry that plan, adapt slightly but be true to it.. then do it with moe-mentum.. tons of it. I guess if you're not a little obsessive compulsive, and prefer to have a real social life, you might not have the time and commitment to finish.

Normally I have been loathe to planning and being organized, just having a positive chaos in my life.. planning has historically seemed a hindrance to the creative process. But a few years of mistakes taught me the harrd lesson in the value of structuring actual development, and since then it's come to my aid countless times... especially when I have hesitation-- I look at my plan and do not question it much.. it's the road through the desert on which I'm running a marathon.. if I go off the road who knows where I'll wind up, but probably won't win the marathon.

Really, you've got to love what you start because you're marrying it. There should be indie-developer:game commitment ceremonies. If you plan something that you really do not feel excited or passionate about, you might not have the lust to finish it.

Caits Kloecker
Studio Cobweb, Doerrenbach
www.studio-cobweb.com (http://www.studio-cobweb.com)

[S2P]

I've been working on various game projects - which all seem to stall out after awhile. I've been taking the approach of just jumping in and doing it - coding some, some art, etc. however it seems like I just end up at a dead end.

I know of many folks who spend time planning out their game forever and never get to the coding phase. So that seems like a dead end as well. Is there some kind of middle way that folks do to actually get a game done?

One option, if not already been mentioned here.. is you do the artwork, and let someone else do the coding as a joint venture. You do what you enjoy and they do what they do best.

[amaranth]

Hey whisperstorm, can you tell us a little more about the dead end problem? Do you know what causes you to lose interest? Do you get caught up in bugs? Are you not sure what to do next with the game? Do you start multiple game projects at the same time? Or do you start other game projects while you are working on the one that eventually causes the dead end?

[Agent 4125]

I've learned that you can get past a productivity block by just implementing the next big feature without worrying how rough it is. It could even just be a static placeholder. You know you'll always have time to polish it up later. Sometimes that's enough to get the ball rolling instead of putting it off until you can do it right.

The other benefit of this is that seeing the new feature in place can make other problems easier to figure out, sort of like a game of Minesweeper. Even working on something that you're not "supposed" to work on yet, like the website or splash screen, can give you the solution to a more important problem.

[Cirdan]

This is definitely a huge barrier.

What's working out for me so far is a bit of both. I sketch up some base documents, jump in and code the game's "shell".

Then jump back out to do more document/design, then back into producing code to test out these ideas.

Rinse and repeat.

/shrug

No "perfect" way to do it IMHO, you've got to hit your stride and find out a method that works for you.

Yea...I do the same. I start out with the basic graphics that I know I'll need, start the basic coding. In my case I have graphics, client and server to work on. So I'll just switch what I'm working on to keep me interested.

I also agree with agent. Ever time I add something new I compile and test it, because I like to see things are working, and its fun to see it on screen. Once you get it added, then clean it up later.

[RinkuHero]

For me it depends on the type of game. RPGs and other story-heavy games require more design time than action games. But even in action games, I usually spend a day designing a list of the variety of enemies or the number of stages.

Most of my design documents are mostly lists rather than prose: lists of weapons, lists of locations, lists of characters, and so on. I don't write "the player will avoid goombas and koopas by jumping on them, break blocks with his head to reveal magic mushrooms" -- and I find that people who design like that can't actually follow it, it's not a good guide to making a game. Instead I might write something like:

Enemies:
- Goomba (slow basic mushroom enemy)
- Koopa (turtle enemy, turns into kickable shell when stomped)
[...]

Powerups:
- Magic Mushroom (causes Mario to grow)
- Fire Flower (gives Mario fireball)

Etc. -- lists like that are easily translated into development tasks.

[TunaBreeze]

I definitely had a lot of trouble when I first started. I had tons of problems, for the most part it was not knowing enough about what I was venturing in to. I've been doing research for the last two years and I'm always finding myself running in to roadblocks where I have to stop for a while and do quite a bit of research to continue. I'm finally at a point where I can put stuff together without massive roadblocks.

[Ahjin]

I am Ahjin from China. Glad to meet you here.

I have some questions,
At first, do you develop casual games individually?
And then, do you design casual games by yourself, if you are a developer or an artist?
Thirdly, how many people are there in your team? And can you survive your team?

Many Thanks.