Hi,

I'm designing a game for a while now, I've been through various phases of prototyping then going back to design and so on, continually adding new stuff and removing/changing old stuff in search of the fun factor.

I'm doing this as a hobby although I would like to have an actual game based on it at some point (i'm more a programming guy than a game designer) but I was wondering:

Is it OK to spend this much time - three months by now - on game design and prototyping alone?

When I take a break and then go back and read my design (mechanics and story) I feel like part of it is crap and needs to be replaced and I also have some new stuff to add. When do I know it is ready? Sometimes I feel like this process will go on forever without actually being able to pinpoint a "final" design which I can go on and implement into an actual game. Did you experience such issues before during your design process?

Cheers.

I'm a 'Programming Guy' too, I do this like a hobby as well, but if you're serious about seeing your game in action, I suggest you should finalize your design doc and start working on it.


If you think what you wrote is not good and it needs to change because you thought of a better way to do something, don't. Stick with it, there's always another game to put those ideas in. Sure, it's important for the design to be perfect, but don't change it drastically every time a new idea comes to mind!

As long as you're prototyping, it's not such a big deal to spend a lot of time on design (particularly if you're a hobbyist, and don't have milestones to hit), in my opinion. But you're suffering from, among other things, feature creep. There will never be an end to things that you could include in your game, however they end up impacting the fun factor. So at some point you need to decide what you want your game to be, and then producing it.

You can always update a release later, expanding on existing features or adding in new ones (see Dwarf Fortress, for example). But if you ever want to produce your game, you're going to have to settle on at least an initial feature set and then actually put it together.

I agree with NeoMortiny.

If you change your design every time a new idea comes into your head, you'll end up with feature creep. Just start programming whatever version of the game you have now. Once you have most of the game finished, then you can see if gameplay elements need to be tweaked or readjusted.

Unless your game has dynamic storytelling with player action directly affecting the story (and if you do, you might not want to work on this alone), then don't worry about story so much right now. It's much better to just get your mechanics in playable form.

If you don't think the game is fun at all while searching for the fun factor, then that's a different problem.

Its OK to spend time designing your game, the more effort you put in here will benefit you later on.

What you need to do it write out what you want to achieve and the steps your going to take to get there. Just remember you wont be able to keep up with technology and your naturally take new inspiration from things and want these in your game, but save them for the sequel! Once you've settled on a design, finalise it and get stuck in with the fun part. If you continue to change the design just to keep up technology or personal preference your game will not make it off the drawing board.

You'll have learnt a lot by the time you have the finished product. From here, your next design will be much more polished as you'll know what worked and what didn’t last time round.

- Kevin.

You might want to consider your goals in programming.

I have a pet-project that I first conceived about 8 years ago. The concept has since continuously changed and progressed as my understanding of programming and game design changed. The pacing changed, the 'player actions' changed, the inheritance tree changed, the engine changed and I could go on like this for a while - but at every stage I was quite content with my progress because I'm mostly developing this for myself, even if I think others might enjoy it by now too.

The point is, if you receive your satisfaction from releasing your game to the public, finish it. If you're happy with how things are going, keep going at it. But don't feel pressed to do either of these.

Thanks for your replies. I think I already have a core of features I want to stick to. I guess I better make them work together first and try to make the game around them. Feature creep indeed is trying to make itself a way into my project but I try to keep it away. I don't want to pump features in it so they don't make sense anymore but I also don't want to deliver a game in which the user does the same thing over and over again until it gets bored.

I'm a 'Programming Guy' too, I do this like a hobby as well, but if you're serious about seeing your game in action, I suggest you should finalize your design doc and start working on it.


If you think what you wrote is not good and it needs to change because you thought of a better way to do something, don't. Stick with it, there's always another game to put those ideas in. Sure, it's important for the design to be perfect, but don't change it drastically every time a new idea comes to mind!

I strongly disagree. Designs at every stage should be mutable, you should never be opposed to changing a design because you've already started working on a game. Attempting to keep a mechanic around that does not work is tantamount to suicide for a game, and if it needs to be changed then it needs to be changed.

Vain you must strike a balance. Game design is definitely shooting a moving target. As you make the game, you're going to have to go through iterations of design, prototype, test. You will discard ideas, pick up new ones, and rework things.

I think it's great that you've spent time prototyping and designing before jumping into implementation. It's a lot easier to test something out on paper and scrap it over the course of a few hours than to spend weeks coding and scrap it. It is not uncommon for games to have fairly extensive design phases like this with multiple designers working on the game before it gets to serious digital production. There are three things I would caution against, however.

1) Biting off more than you can chew. 3 months is a decent amount of time, and does make me suspect that this game may have a grand scope. There's nothing wrong with this, but keep in mind there is only so much a single person or small team can do. A big game will take a loooooooooooooong time to make. Feature creep can cause this, too.

2) Spinning your wheels. Shooting a moving target implies that you get closer to the bullseye with every shot. If you aren't, and keep redesigning big chunks of core game mechanics over and over, something's wrong. You might need to get some outside perspective to help focus your thoughts and develop a solid kernel to wrap your game around. Don't be too afraid of someone stealing your million dollar idea or something, collaboration is really valuable.

3) Weak prototyping practice: If your prototypes aren't actually capturing the spirit of your design, and what you want to test, then you need to re-evaluate your prototyping process. I'm not sure if you're doing strictly digital, paper, or a mix, but if you're only using one method give another a shot.

You do at some point have to start making the game, and I would recommend starting off by digitally prototyping your solid, core mechanics and growing from there. If you have a good foundation, you can build a good game around it. If the core is weak, the design will falter. If you're having trouble designing parts of the game, focus on the core mechanics first. While nothing in a design is immutable, the closer things get to the core, the more you should think about changing them. That's why the best thing you can do early is design a very solid core concept for your game, even if you can't figure out how to make the complete game from the core quite yet.

I'd also shy away from an elaborate design document. I don't think they're really worth it most of the time, and that an early design document should be a skeleton that you fill in. It's going to be nearly impossible to nail down exact numbers of exactly how every system interracts. Focus instead on filling in the design as you go, figuring out the specifics of each item as it comes up. Since systems rely heavily on interaction of their constituent parts, and even the best prototypes cannot 100% accurately reflect how a game will play, I feel this gives you the best quality design.

Thanks for your elaborate answer. Let me answer to your points:

1) The game is pretty simple and I learned my lesson trying to do bigger projects before. This one stays small, actually I had to let go of some of the (not so important) mechanics because they didn't fit in with the amount of work I have to do (or outsource) on the art part. Most of the time I was evolving my core mechanics, often scraping most of them, but now I'm pretty close to what can be called a core.

2) The outside perspective is mainly why I got my core mechanics scrapped over and over, and I'm not sorry about it, again, it led me to something more interesting in the end. I just need a way to put all the things together as I'm still missing some minor parts of "the puzzle".

3) I usually make digital prototypes as it is very easy for me as a coder to throw in some simple geometric shapes/objects in there and write some scripts to test the ideas. I will try the paper method too, although it's pretty hard because it is a real time game.

I guess I'll follow your advice and do just that, start prototyping again these new ideas and try to build on those instead of scrapping everything and start from (almost) scratch again.

I don't do design documents, it's just a notebook where I write my ideas so I don't forget them, then read them later and see if they still seem fun and intriguing.

Most people on this forum would disagree with me, because their situation is different. If you are a designer in a 6 people team and you spend a year designing the game that is produced with 1 year you only used 20% time of the team. But if you are a lone guy doing both design and coding and you spend 6 months on designing a 1 year game then you used up 50% of resources on design. That's unacceptable amount.

3 months is awfully long for a hobbist who also needs to spend the time later on the coding and making gfx assets.

In short, if your design will be used by a team of expensive programmers later, go all the way, any amount spent on design will most likely pay off. But if you doing it all alone then the time used up on the design is simply eating up the resources that you could use on the implementation instead.