What I'm asking is, when making plans for a game, should I plan every aspect of it from the beginning, or should I divide it into parts, to keep it more manageable, depending on the size of it?
Is it better to plan the whole game out, or just in parts?
I haven't been working on any larger games yet but I'm currently reading Intro to Game Development and from what I understand, there is some trade-off between concise planning and writing code blindly.
When writing code blindly, you will have to fix the code and clean it as you go along which puts you at a disadvantage because the more complex your code gets, the harder it will be to manage.
On the other hand, if you plan everything in the tiniest details you may find yourself coding more efficiently, but if something changes in your plans, the whole plan will most likely have to change and in a real-time development environment, you won't have the time to make a new one hence you are back at square one coding blindly.
The ideal path is somewhere in between. You want to do some planning but make the plan relatively loose so that when you code and a need for change arises you'll have some space for it and won't be caught with your pants down so to speak. Again, it's only what I've read of and slowly I'm actually starting to realize where this counts, but it's nowhere near the magnitude of a commercial game or anything more complex.
When writing code blindly, you will have to fix the code and clean it as you go along which puts you at a disadvantage because the more complex your code gets, the harder it will be to manage.
On the other hand, if you plan everything in the tiniest details you may find yourself coding more efficiently, but if something changes in your plans, the whole plan will most likely have to change and in a real-time development environment, you won't have the time to make a new one hence you are back at square one coding blindly.
The ideal path is somewhere in between. You want to do some planning but make the plan relatively loose so that when you code and a need for change arises you'll have some space for it and won't be caught with your pants down so to speak. Again, it's only what I've read of and slowly I'm actually starting to realize where this counts, but it's nowhere near the magnitude of a commercial game or anything more complex.
I have this same problem. I want to make a game on my own. When I started the project I created several filters such as "IO", "UI", "Graphic", "Logic", etc. Then I focused on each of them one by one. But it turned out that the time is too long to develop a good enough module before you lose patience and ask yourself when could I start to code the real core of the game...
So now I think a better way would be:
1, to have a clear structure for the project;
2, make interfaces and basic logic functions so that the game could run like a demo;
3, go deep into each module...
So now I think a better way would be:
1, to have a clear structure for the project;
2, make interfaces and basic logic functions so that the game could run like a demo;
3, go deep into each module...
Quote:Original post by Slateboard
What I'm asking is, when making plans for a game, should I plan every aspect of it from the beginning, or should I divide it into parts, to keep it more manageable, depending on the size of it?
Are you asking about the game design? Or the programming of the game?
First you need to have a GDD (a game design document). You need to have a complete idea of what you are making. Then you need to do the technical design. In thinking through the technical design, you should be able to figure out where you need to start.
If that's what you're asking.
Quote:Original post by Tom Sloper
Are you asking about the game design? Or the programming of the game?
First you need to have a GDD (a game design document). You need to have a complete idea of what you are making. Then you need to do the technical design. In thinking through the technical design, you should be able to figure out where you need to start.
If that's what you're asking.
Excuse me Tom, could you please describe a little more about the "technical design"? I'm wondering how wide and how deep should this doc go. Thanks!
I never design the game down to the last variable, or atleast I don't anymore. There's are always going to be needed changes, crap just happens as you realize your design doesn't work like you expected.
I like splitting things into general sections, and writing down how I think they should work and flow rather than the functions and variables I need.
Such as my recent game's gameplay was split into different phases. So I planed how those phases would play out, and what I expected to happen as they went along. ie the build phase, I expected the player to be able to select a building and spot to build it. That I was going to need a menu or gui to be able to select the buildings, and some way to interact with the map.
With that I hacked a simplified version that did what I described to a degree. I thne broke it down a little more and re factored what I had coded to make it work a little more as planned.
I like splitting things into general sections, and writing down how I think they should work and flow rather than the functions and variables I need.
Such as my recent game's gameplay was split into different phases. So I planed how those phases would play out, and what I expected to happen as they went along. ie the build phase, I expected the player to be able to select a building and spot to build it. That I was going to need a menu or gui to be able to select the buildings, and some way to interact with the map.
With that I hacked a simplified version that did what I described to a degree. I thne broke it down a little more and re factored what I had coded to make it work a little more as planned.
Here's my two cents.
The Game Design Document (GDD) describes how your game will play. It is essential that this be detailed, so that when you begin coding, you know exactly what you need to do. You do not, however, need to be so detailed as to include specific stats for each weapon, enemy, and player. Stats are a game balance issue. Games are very difficult to balance on paper. So, a description for an enemy might explain what the enemy does, even as far as specifying specific attacks or moves. And if it's an RPG, you may even want to include information about what type of damage each attack does (e.g., the fireball does fire-based damage, the frost bold does frost-based damage, and so on). What you don't want to do is specify, in numbers, how much damage it does. At the very most, you'll want to use relative descriptions. If you really, really want to, go ahead and include some numbers to start with. Just understand that you will[/] throw these numbers away during the balancing phase of your game.
The Technical Design Document (TDD) explains how the GDD is going to be implemented. Don't go nuts here. I think this is the sort of document that you'll want to write, and then re-write, over and over again, with increasing levels of detail. At first, it should just be a rough sketch of the overall architecture. Then, go over each area, and try to be a little more specific. Then, go over each sub-area, and try to flesh them out a bit. I don't think you'll want to get into the real knitty-gritty, e.g. specific variables, and so on. But certainly, you should specify specific classes, the interface to those classes, and whatever key data members you'll need.
Try to get it down to a granularity such that you can estimate the amount of time each task will take, and none of them are above 10 or 15 hours. If you estimate a time of 40 or 80 hours for a certain task, try to break it into sub-tasks, and break those into sub-sub-tasks, and so on, until you're at the right granularity.
If you find this level of planning too difficult, then consider working on a smaller project. Once you're done with the smaller project, try your hand at the larger one again.
Alternately, you can try to dive in and code, even though you don't have a solid plan. There is a higher chance of failure, but you will learn a thing or two. Sometimes it helps just to experiment. It's just about striking the right balance between rationalism (i.e., what looks great 'in theory' or 'on paper', which inexperienced programmers generally have difficulty with), and empiricism, i.e. actually testing things out to see how they *really* work.
Don't be afraid to fail, even if it means throwing away code. Code is not as expensive and precious as you might think.
Get a good source control system, and check in regularly. This will free you up for experimentation. If you're on Windows, I recommend Mercurial (Hg) or maybe SVN. Git is an option, too, but it's somewhat of a pain if you aren't using Linux.
The Game Design Document (GDD) describes how your game will play. It is essential that this be detailed, so that when you begin coding, you know exactly what you need to do. You do not, however, need to be so detailed as to include specific stats for each weapon, enemy, and player. Stats are a game balance issue. Games are very difficult to balance on paper. So, a description for an enemy might explain what the enemy does, even as far as specifying specific attacks or moves. And if it's an RPG, you may even want to include information about what type of damage each attack does (e.g., the fireball does fire-based damage, the frost bold does frost-based damage, and so on). What you don't want to do is specify, in numbers, how much damage it does. At the very most, you'll want to use relative descriptions. If you really, really want to, go ahead and include some numbers to start with. Just understand that you will[/] throw these numbers away during the balancing phase of your game.
The Technical Design Document (TDD) explains how the GDD is going to be implemented. Don't go nuts here. I think this is the sort of document that you'll want to write, and then re-write, over and over again, with increasing levels of detail. At first, it should just be a rough sketch of the overall architecture. Then, go over each area, and try to be a little more specific. Then, go over each sub-area, and try to flesh them out a bit. I don't think you'll want to get into the real knitty-gritty, e.g. specific variables, and so on. But certainly, you should specify specific classes, the interface to those classes, and whatever key data members you'll need.
Try to get it down to a granularity such that you can estimate the amount of time each task will take, and none of them are above 10 or 15 hours. If you estimate a time of 40 or 80 hours for a certain task, try to break it into sub-tasks, and break those into sub-sub-tasks, and so on, until you're at the right granularity.
If you find this level of planning too difficult, then consider working on a smaller project. Once you're done with the smaller project, try your hand at the larger one again.
Alternately, you can try to dive in and code, even though you don't have a solid plan. There is a higher chance of failure, but you will learn a thing or two. Sometimes it helps just to experiment. It's just about striking the right balance between rationalism (i.e., what looks great 'in theory' or 'on paper', which inexperienced programmers generally have difficulty with), and empiricism, i.e. actually testing things out to see how they *really* work.
Don't be afraid to fail, even if it means throwing away code. Code is not as expensive and precious as you might think.
Get a good source control system, and check in regularly. This will free you up for experimentation. If you're on Windows, I recommend Mercurial (Hg) or maybe SVN. Git is an option, too, but it's somewhat of a pain if you aren't using Linux.
Addition to what was already said...
Planning EVERYHING up front is sometimes called "Waterfall model". And it is better to avoid it. A better approach is called "Itterative development". Where you develop in "itterations" (cycles). And at the end of each cycles you try to have the game (software) in a "presentable" state.
By "presentable" I don't mean a complete game but at least something meaningfull. I adopted this development method and it really changed my life as a programmer.
I read about it in a object-oriented analysis/design book. And you should search more in depth about it.
Like the author of the book said: Beware, use it just on projects you want to succeed ;-)
Planning EVERYHING up front is sometimes called "Waterfall model". And it is better to avoid it. A better approach is called "Itterative development". Where you develop in "itterations" (cycles). And at the end of each cycles you try to have the game (software) in a "presentable" state.
By "presentable" I don't mean a complete game but at least something meaningfull. I adopted this development method and it really changed my life as a programmer.
I read about it in a object-oriented analysis/design book. And you should search more in depth about it.
Like the author of the book said: Beware, use it just on projects you want to succeed ;-)
Quote:Original post by Lovens
Planning EVERYHING up front is sometimes called "Waterfall model". And it is better to avoid it. A better approach is called "Itterative [sic] development".
It's best practice to plan everything up front, even if you are using an iterative method. You at least plan the first iteration, with knowledge of what you hope to achieve by the last iteration. The iterative method is to work out (by trying it in a low-impact way) either the primary fun or a tricky play feature.
Iterative does not mean throwing planning out the window.
Mostly I support Tom Sloper here.
Anyway, you have to plan, but not drill down to the tiniest details. It's like a mind mapping that Tony Buzan teaches. You have type of game, game mechanics, and the rest.
Just remember it's all plan, but snot traight jacket. It's usual for game developers to drop part of the plan due to time and budget constraint.
WINK: Some people complain why books inside Ultima 8 state that tear of the sea is located in an underwater city - but you just take it from a chest, given by Devon - besides, two item were taken from the titan itself, earth and air, but fire item were taken from the old sorcever, and tear sea was given outright. Conspiracy Theorist says the game just got shortened).
Looking at the patch released later, they have a point.
Anyway, you have to plan, but not drill down to the tiniest details. It's like a mind mapping that Tony Buzan teaches. You have type of game, game mechanics, and the rest.
Just remember it's all plan, but snot traight jacket. It's usual for game developers to drop part of the plan due to time and budget constraint.
WINK: Some people complain why books inside Ultima 8 state that tear of the sea is located in an underwater city - but you just take it from a chest, given by Devon - besides, two item were taken from the titan itself, earth and air, but fire item were taken from the old sorcever, and tear sea was given outright. Conspiracy Theorist says the game just got shortened).
Looking at the patch released later, they have a point.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
