Before you start making a game, what aspects of it do you design, write down, or think about before actually working on it? Or. if you make it up as you go along, which aspects do you focus on? Things like story, style, gameplay, genre, etc.
I'd like to have a broad range of game aspects to draw from for my next project. And knowing what others focus on when making their games would help out tremendously.
I usually don't have good ideas so I have to rely on a friend of mine to come up with them . . . and he comes up with plenty. I usually contribute when I have something that I think is really awesome and I also modify his ideas a bit when I think that I can improve upon them.
We usually start with a simple notepad file outlining the basics. These usually include how many levels there are, how many sections per level, the general theme of each level, character abilities, any equippables/upgradeable items, health items, enemies, bosses etc.
We also do a lot of on-the-fly stuff so if he draws up a new enemy that we didn't plan originally we just incorporate it in. I always focus on gameplay more than anything as a game with great graphics and a great story, but shitty gameplay is a shitty game ( (game)play). A game with great gameplay and mediocre graphics (animations are the most important), but a crappy story can still be fun and not feel like a chore.
Depends on the type of project, how big you want to make it, whether you'll need documentation for someone else, whether you've failed the idea once before (), and things like that. The answer won't just be different from person to person. It's from game to game!
If you're making a puzzle game, for example, you might not bother with documenting anything. Whenever I start a game that has a story, it usually starts out with character sketches--drawings and figuring out the personalities and surroundings. But I might make a game with a story that doesn't have deep characters, so maybe I'd skip that. I usually start documentation for drier subjects after I have a good chunk done, if I document at all. Flying by the seat of your pants is really fun when you have no money invested in what you're making.
If you'd like to get it right the first time and you have a penchant for losing focus, do sit down and plan a bit. Figure out the style you want, figure out what you can and can't do, and give yourself a solid goal. Just dump everything you want on a page in Word. Doesn't have to be pretty, and last time I checked, .docs weren't made of stone.
while that is all well and good, thats the whole point of the project. to help with the design of the overall game. set basic parameters to work within. all of which can be randomized, selected, or edited and added to the list of selectable items.
its more about general aspects of a game than specifics. before you create your characters or sprites or anything within the visual environment you would need to choose an artstyle, therefore that would be a major aspect of the game. and again, before you go in and make your characters do stuff, you would choose what genre the game is, what point of view its played from, which would also be major aspects.
I start with an idea of how I want the game to be played. What can the player do? Why would the player want to do it? I'll try to come up with as many answers to those questions as I can. After that, I'll start thinking about setting. What kind of world will the game exist in? How will the player get around? How can I best structure the world data to meet these goals? The answers to these questions are from a design perspective rather than an artistic one.
At this point, I look at the big picture and the notes I already have. What fits in the grand scheme of this game? Anything that doesn't fit I look at how it can be changed to fit the project. If something can't be changed, then I cut it. I'm also looking at what concepts I could actually finish. If there is something that I know I absolutely won't be able to do, then I cut it. I'll then take the list I've assembled and structure it in a way that makes sense. What systems will I need working before I can working on other systems?
With a structured list of basic features in hand, I set deadlines for myself and then I get to work. Yes, deadlines. I allot an amount of time for myself to get the game to a specific stage of development. When I should have the game in the utmost basic playable state, when I have core features implemented, things like that. In the industry, we call these milestones.
Note that at no specific point am I looking at the aesthetics. Getting wrapped up in art style and story will take more time to work on than the design and programming. I won't work on the aesthetics until I have the content pipeline ready. It's a waste of time to work on art and stuff before you have an engine to plug it in to.
I think if you're someone like me, who has trouble finishing projects, a plan can be invaluable.
For a plan to be really useful, you probaly want to consider exactly what you're going to do, and the order in which you'll do it - and then stick rigidly to your plan.
There are three main reasons I fail to finish a game project:
1.) My game idea is overly ambitious, and either I realize this half way through, or I just eventually lose interest and give up...
2.) I get sidetracked making graphics etc, instead of coding, and eventually lose interest and give up...
3.) I start adding more and more extra "stuff", instead of focusing on the core game, and eventually lose interest and give up...
If you plan everything out in advance (and commit to that plan), you will have a better idea of how much work will be required, and whether the project is realistic.
This should help you avoid case #1.
As Aphant said, it's a really good idea to leave graphics until after you have a functional game - just use placeholders up til then.
That should help you avoid case #2.
If you plan everything in enough detail, and stick to your plan (do things in the order you planned, and don't add *anything* that wasn't in the original plan - tell yourself you're saving it for the sequel), then you shouldn't get sidetracked.
That should help you avoid case #3.
I'm following these guidelines with my latest project, and progress has been so much quicker than usual.
Obviously it depends on the game and the person though - if you have a bit more self-discipline than me, you can probably just wing it.
I am pretty much like sketchy, im just adding useless stuff. Anyway thats why this time i stick to the plan, and thats the most important thing, stick to the plan! Don't just decide in the middle " oh i need 300 weapons actually", trust me you don't!
Don't just make the idea before you start, make plans, what will you code first, what second etc... So you don't have to recode later on. Recoding and coding back is very painful and exhausting.
And the most important thing: Be wise like an owl.
Advertisement
Post Reply
Edited by GamesterXIII
), and things like that. The answer won't just be different from person to person. It's from game to game!
