Jump to content

  • Log In with Google      Sign In   
  • Create Account


How much time do you spend on game design?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
16 replies to this topic

#1 meeshoo   Members   -  Reputation: 508

Like
0Likes
Like

Posted 18 April 2011 - 10:24 AM

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.

Sponsor:

#2 Tincha7   Members   -  Reputation: 169

Like
1Likes
Like

Posted 18 April 2011 - 11:46 AM

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!

#3 Khaiy   Crossbones+   -  Reputation: 1342

Like
2Likes
Like

Posted 18 April 2011 - 12:13 PM

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.

#4 MashesButtons   Members   -  Reputation: 107

Like
2Likes
Like

Posted 18 April 2011 - 12:17 PM

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.

#5 moNoKnoT   Members   -  Reputation: 124

Like
1Likes
Like

Posted 18 April 2011 - 01:24 PM

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.

#6 In.Vain   Members   -  Reputation: 108

Like
0Likes
Like

Posted 18 April 2011 - 01:57 PM

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.

#7 meeshoo   Members   -  Reputation: 508

Like
0Likes
Like

Posted 18 April 2011 - 02:24 PM

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.

#8 PropheticEdge   Members   -  Reputation: 150

Like
1Likes
Like

Posted 18 April 2011 - 02:30 PM

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.

#9 meeshoo   Members   -  Reputation: 508

Like
0Likes
Like

Posted 18 April 2011 - 04:45 PM

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.

#10 Acharis   Crossbones+   -  Reputation: 3545

Like
0Likes
Like

Posted 19 April 2011 - 01:28 AM

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.

Europe1300.eu - Historical Realistic Medieval Sim (RELEASED!)


#11 meeshoo   Members   -  Reputation: 508

Like
0Likes
Like

Posted 19 April 2011 - 03:21 AM

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.


Well, I am alone but I do not plan to do all the things myself. I will limit to game design, programming and a small part of the graphics. I plan to outsource the rest, including music, sound and the most important graphic assets. The game is quite simple in terms of mechanics, basically a complete prototype would represent 90% of the game done in terms of programming. The bulk of the work is made of level design and graphic assets, and I plan to do the level design somewhat in parallel with the creation of the assets.

#12 Ghostknight   Members   -  Reputation: 166

Like
1Likes
Like

Posted 19 April 2011 - 07:21 AM

In my years of designing as a hobbyist working on board game projects, tcg and ccg and small wwII strategy table top games, I notice that its alright to take as long as you need to work out the mechanics of your projects thoroughly then to rush through a project to find out that the game your worked on doesn't play or doesn't flow like you had hoped for.

I am still working on my survival horror board game and first stcg (strategy trading card game) since 1999. Those are two of my biggest projects.
The board game to computer game idea prior to my suvival horror board game took me two full years to draw out a top view fantasy action adventure board game. from 1992 to 1994. It started out as a large maze but decided to work on it as a dnd similar type game. The map is 13 1/2 feet in length and 4 1/2 feet wide. The map also consists of two sections.

Yes way to long for these projects. But I like to have the adventure in creating the storylines and mechanics as I go. Thats the whole idea of creating these game projects right?
At one time I would like to have seen these projects on store shelves but with one person its an enormous task but its okay. Just going through the paces.

#13 DarklyDreaming   Members   -  Reputation: 363

Like
1Likes
Like

Posted 19 April 2011 - 11:06 AM

Design should always be iterative; if you're making a game design upfront and not revising it as you go, you're doing it wrong.
"I will personally burn everything I've made to the fucking ground if I think I can catch them in the flames."
~ Gabe

"I don't mean to rush you but you are keeping two civilizations waiting!"
~ Cavil, BSG.
"If it's really important to you that other people follow your True Brace Style, it just indicates you're inexperienced. Go find something productive to do."
~ Bregma

"Well, you're not alone.

There's a club for people like that. It's called Everybody and we meet at the bar."

~ Antheus


#14 PropheticEdge   Members   -  Reputation: 150

Like
2Likes
Like

Posted 19 April 2011 - 12:56 PM

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.


Yes, but without a good design implementation won't work, and result in even more wasted time.

The whole reason you take time to design games is because it's cheaper to design than it is to implement, at every stage of the development process. It doesn't matter if you're solo or with a group of 50 dudes, you will save time if you work out design issues before implementation.

However! Really, honestly, I cannot stress enough that monolothic design is a bad idea. You don't need to spend a year with dwarven design smiths hand forging the legendary Design Document of Narsil deep in their gilded halls before you think about touching code. Rather, design works well if it is intermingled with the development process. This is actually true for projects of virtually any size, big and small. Even a small game with less moving parts can benefit from not designing the entire thing up front, but rather designing as you go.

When I was in college, I came up with a method for making games that works like this. I'll use the game Sanctum as an example (new FPSTD, First Person Shoot Tower-Defense that came out like a week ago).

1) Conceptualize. Come up with the idea for the game. In this case, it's simply, "Make a tower defense game where you also control an individual ala a first person shooter that fights creep waves along with towers you build, ala a standard tower defense game."
2) Rough design: Come up with a framework design for the game. This encompasses, more or less, the overall mechanics of the game and points out some questions that will crop up in the future. Perspective will be first person, you'll have a couple guns you can switch between (should they have ammo or powerups?). You will fight enemies with standard FPS mechanics (should there be health?). You can build towers to defend against mindless creeps that will suicide run into your base (should I allow mazing or gauntlet style construction? What will be build interface be? Should I implement a top-down view for building?)
3) Identify the core of the game: Most games have a core, or a few cores, that make up the most important mechanics of the game. Likely candidates for core mechanics are actions that players will be performing often, or a mechanic that many other mechanics depend upon. It is very key to identify core mechanics and refine them well; if they suck your game will suck. If your secondary mechanics suck, then your game can still be good with a couple problems that detract from, but do not ruin, the experience. In Sanctum, the core mechanic is the interplay between first person shooter and tower defense, being able to maneuver through your towers and fight alongside them to kill the enemy.
4) Refine and test the core mechanic: Here's where you'll spend a lot of time in the design phase. Try to start off with a simple, but complete, slice of your core mechanic and test the shit out of it. Make prototypes, digital or paper. Make them rough and fast, but good enough to thoroughly test the mechanic. In this case, I'd fire up the UDK and code a rough turret I can place down, just a box that shoots anything hostile near it. Then I'd spawn a bunch of simple bots that run toward me, or even simpler, get some friends to take place of the bots and try to navigate through a turret maze toward me. This should give me an idea whether or not this idea is a dud. It also lets me identify potential problems down the way (moving around turrets is awkward, it's much easier to fight while standing on a turret, my guns seem way more useful than the turrets, etc). Mostly, I'm not worried about exact numbers at this stage, but rather the idea behind specific mechanics. Exact numbers are polish, and should be left for later.
5) Take (or scrap, nothing ever wrong with scrapping) the prototype and build it out into an actual mechanic.
6) Identify the next-most-important design aspect of the game and repeat.

To assist with this, I use a development organization style I call the tier system. I divide up my design into tiers of importance, the lower ones being core mechanics, the higher ones being less important. This helps me decide what to focus on next.

Tier 0:
Turret maze prototype. The ENTIRE game hinges on this working.

Tier 1:
Gun prototypes (different types of guns)
Turret prototypes (different types of turrets)
Enemy prototypes (different types of enemies)

Tier 2:
Construction interface prototype

Tier 3:
Refine enemy types
Refine turret prototypes
Refine enemy prototypes

Tier 4:
Refine player movement
Refine construction interface

Tier 5:
Overall polish

I also, usually, make a tier list for the software engineering side for each task in the design tier list that helps determine how to implement it.

This is a rough guideline to help me make a roadmap of my iterative design->development process. At every tier, I re-evaluate the entire design to see how the pieces are fitting together and redesign mechanics that I feel are becoming clunky. For instance, maybe implementing very fast enemies was really cool, but exposed that it's too hard for the player to move around the maze efficiently to fight them. Solution? Let the player build teleporters at strategic points along the map. This lets you fix problems at the crop up, and identify what changes caused the problem in the first place.

#15 meeshoo   Members   -  Reputation: 508

Like
0Likes
Like

Posted 21 April 2011 - 09:29 AM

I have seen Sanctum's trailer, nice game you have there. I'm fed up with TD games myself, but this seems to be an interesting take on the subject.

About incremental design, I agree it is one of the best ways to work on design and game development for that matter. The only risk here is to make too many iterations with the wrong core mechanics, and then go back and start from scratch, but if you identify your core mechanics early in the process and be sure that is what you want in your game, the rest is best to be added in various iterations. Each iteration should both contain improvements to the existing stuff that was nailed down in a previous iteration and also new stuff that is added for testing.

I am currently working on another (6th?) simple prototype for testing my core mechanics and also getting more used with Unity, as I found out this is the most important side effect from prototyping with a new technology: you get to learn a few tricks way before starting to work on the actual game.

#16 PropheticEdge   Members   -  Reputation: 150

Like
0Likes
Like

Posted 21 April 2011 - 10:17 AM

I have seen Sanctum's trailer, nice game you have there. I'm fed up with TD games myself, but this seems to be an interesting take on the subject.

About incremental design, I agree it is one of the best ways to work on design and game development for that matter. The only risk here is to make too many iterations with the wrong core mechanics, and then go back and start from scratch, but if you identify your core mechanics early in the process and be sure that is what you want in your game, the rest is best to be added in various iterations. Each iteration should both contain improvements to the existing stuff that was nailed down in a previous iteration and also new stuff that is added for testing.

I am currently working on another (6th?) simple prototype for testing my core mechanics and also getting more used with Unity, as I found out this is the most important side effect from prototyping with a new technology: you get to learn a few tricks way before starting to work on the actual game.


Well, I didn't make Sanctum (I wish!), I was just using it as an example of how I would work through the development process if I'd made Sanctum.

Oh, another point. Unity's a great tool to make prototypes with! Even if you were making a game with straight up C++ and DirectX/OpenGL, using Unity to develop prototypes would be super worth it simply because you can churn out a working prototype with it about a million times faster than using something heavy weight.

#17 meeshoo   Members   -  Reputation: 508

Like
0Likes
Like

Posted 22 April 2011 - 03:59 AM

Well, I didn't make Sanctum (I wish!), I was just using it as an example of how I would work through the development process if I'd made Sanctum.


Sorry for the misunderstanding.







Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS