best laid plans
Author
Hi
Im just starting to look into making a game, A racing motorcycle sim is the plan as there nothing out there any good for us virtual scratchers.
There going to be two of us working on the project, One has basic/intermediate C++ and the other basic/intermediate 3d modeling skills. (Im trying to learn C++ as well but finding it heavy going and the books a pretty dry read tbh).
We also started working though some basic game making books, Im enjoying game maker apprentice, It also gave us a reality check that this will be a 7-10 year project more than likly.
Question is: What the best way to plan the game out please? As this is all were going to be able to work on untill our skill progress.
Quote:
Question is: What the best way to plan the game out please? As this is all were going to be able to work on untill our skill progress.
Forget about it.
In order to become a better programmer, you need to practice. And in order to that you need to finish smaller projects. You, at least, are probably going to have to put aside the idea of working on this big project until you develop some smaller ones first, to build up your skills.
Once you are at a point where you feel your skill level equates with the skill level required to make the kind of game you want, then you can consider how to plan and develop it. There is no "best" way to do that -- there is only the way that works the best for your team, and that's something you're going to have to decide on your own.
Author
Maybe i asked the wrong question, I should'nt of put what the "best" way, but how do you guys do plan games out.
Im aware i can't make the game i would like at the moment.
Im aware i can't make the game i would like at the moment.
I would plan to start working on something you'd like to make where you know in advance how to do roughly 70% of it and are reasonably sure you can work out the remaining 30% along the way.
That's pretty much how I did things, and it stops the project from being too challenging and hence offputting, or too easy and hence boring.
Actual percentages may vary for the individual.
That's pretty much how I did things, and it stops the project from being too challenging and hence offputting, or too easy and hence boring.
Actual percentages may vary for the individual.
This recent thread talks about how people keep track of their thoughts. I also use a personal wiki.
Also, this page seems to have some general level stuff to think about.
Me, I pretty much just make it all up as I go along. But I suppose in general consider what I want to do, think about what I need to get it done, research as needed, try out whatever I came up for a solution, make notes regarding success or failure, and then repeat.
Also, this page seems to have some general level stuff to think about.
Me, I pretty much just make it all up as I go along. But I suppose in general consider what I want to do, think about what I need to get it done, research as needed, try out whatever I came up for a solution, make notes regarding success or failure, and then repeat.
Jpetrie is correct. Forget about it and learn to program free of any expectations of banging out a game. Start small and work your way up. Expect about a year of doing command prompt work learning the language until you work your way into a GUI environment of some kind...
But if you're asking what I do, there is no recipe for success. I'll talk briefly about the design aspect, however:
I have one moderately popular game mod I put out (Vampirism Beast for Wc3), I can only really speak to that. Basically I took an existing type of game, played the hell out of it. Then I started simple by developing a derivative of the game with a few new items and improved game balance. Then I sped up the progression system so people had a more active and engaging game and added more content.
The game evolved to include many elements not in the original concept of that kind of game and only the core gameplay mechanics are similar to the original. The key to its success was to iterate over the game design often and really take feedback into consideration.
This similar concept has worked with success for League of Legends and Heroes of Newerth which both went different directions with something similar to my approach.
___
There have been entire books written about the software development life-cycle. Code Complete covers this among other things and I recommend it (just don't take its word on absolutely -everything- it's mostly very good but has some weird ideas about pseudo code which I have -never- encountered in the wild for example.)
But if you're asking what I do, there is no recipe for success. I'll talk briefly about the design aspect, however:
I have one moderately popular game mod I put out (Vampirism Beast for Wc3), I can only really speak to that. Basically I took an existing type of game, played the hell out of it. Then I started simple by developing a derivative of the game with a few new items and improved game balance. Then I sped up the progression system so people had a more active and engaging game and added more content.
The game evolved to include many elements not in the original concept of that kind of game and only the core gameplay mechanics are similar to the original. The key to its success was to iterate over the game design often and really take feedback into consideration.
This similar concept has worked with success for League of Legends and Heroes of Newerth which both went different directions with something similar to my approach.
___
There have been entire books written about the software development life-cycle. Code Complete covers this among other things and I recommend it (just don't take its word on absolutely -everything- it's mostly very good but has some weird ideas about pseudo code which I have -never- encountered in the wild for example.)
The problem is you are asking how to plan to build an interstellar spaceship without understanding what the parts are that you even need to build the ship.
Until you understand the basics you can't start to plan how to do something more advanced.
You can't do a Marathon before you even learn to turn over.
theTroll
Until you understand the basics you can't start to plan how to do something more advanced.
You can't do a Marathon before you even learn to turn over.
theTroll
Prepare yourself first by realizing that you will have to rewrite a lot of code before you reach the final solution.
Now... start:
Define all goals. Break each goal into parts recursively until the parts are simple enough that you know how to implement them OR find out that you need to learn more. At this point they're 'tasks'. Keep a tree/graph of how each larger goal breaks down into its parts since this will be useful later...
You won't be able to progress while there are any unknowns (or missing goals), so solve those first. You need to fill in gaps in your knowledge (google, trial-and-error, etc). Feedback from learning new things may require modification of your existing goals/tasks.
After you have *everything* broken down into known tasks, take all pairs of tasks and determine what their relationship is as far as you understand it (peer system, subsystem, helper, totally unrelated, etc). You can start with a big 2D matrix, but eventually you'll want to simplify it into a node/edge graph of some kind (UML or whatever you want). You'll need to integrate these relationships into your task breakdown graph.
Examine the task relationships and try to determine how each implementation task will interact with anything it's related to. See if there are common things that you can simplify/share. Consider how you would deal with these things in your implementation language. See if there are any conflicts or spots where you suspect implementation might get ugly. Make modifications if you can at this point (they *will* be necessary).
After this you can probably start writing some code with a very good idea of what to do. You'll run into all problems you haven't had the experience to forsee by now (and add them to your experience for next time). You will have to scrap some (or all!) of your code and redo some/all of the previous steps.
Now... start:
Define all goals. Break each goal into parts recursively until the parts are simple enough that you know how to implement them OR find out that you need to learn more. At this point they're 'tasks'. Keep a tree/graph of how each larger goal breaks down into its parts since this will be useful later...
You won't be able to progress while there are any unknowns (or missing goals), so solve those first. You need to fill in gaps in your knowledge (google, trial-and-error, etc). Feedback from learning new things may require modification of your existing goals/tasks.
After you have *everything* broken down into known tasks, take all pairs of tasks and determine what their relationship is as far as you understand it (peer system, subsystem, helper, totally unrelated, etc). You can start with a big 2D matrix, but eventually you'll want to simplify it into a node/edge graph of some kind (UML or whatever you want). You'll need to integrate these relationships into your task breakdown graph.
Examine the task relationships and try to determine how each implementation task will interact with anything it's related to. See if there are common things that you can simplify/share. Consider how you would deal with these things in your implementation language. See if there are any conflicts or spots where you suspect implementation might get ugly. Make modifications if you can at this point (they *will* be necessary).
After this you can probably start writing some code with a very good idea of what to do. You'll run into all problems you haven't had the experience to forsee by now (and add them to your experience for next time). You will have to scrap some (or all!) of your code and redo some/all of the previous steps.
I actually couldn't disagree more strongly with Nypyren who has basically described the design phase of the waterfall method... Though suggested that after defining everything you may still get it wrong which is at least correct.
You need to find a part that you are comfortable implementing and do it. Then find the next part. Your overall goal should not be to have the whole system and all interactions defined before you begin, but to have a rough sense for what you are doing (we'll need 2d graphics, sound, physics, some tools etc) and then begin analyzing and implementing those individually and iterating over the implementations as you integrate.
The most important thing is to get something running early so that you can build off of a working and running piece of the game. Obviously you want to be flexible in your implementation (something you can only do with lots of experience) and try to keep yourself developing through each task. Feel free to analyze sections as you need them, but do not concern yourself with understanding every working part before you begin because that just isn't possible.
That said, before you start jumping into the actual game project you should really know the actual language you are jumping into. This is why I suggest you wait before attempting to tackle something where each part will prove impossible at your current level of skill.
You need to find a part that you are comfortable implementing and do it. Then find the next part. Your overall goal should not be to have the whole system and all interactions defined before you begin, but to have a rough sense for what you are doing (we'll need 2d graphics, sound, physics, some tools etc) and then begin analyzing and implementing those individually and iterating over the implementations as you integrate.
The most important thing is to get something running early so that you can build off of a working and running piece of the game. Obviously you want to be flexible in your implementation (something you can only do with lots of experience) and try to keep yourself developing through each task. Feel free to analyze sections as you need them, but do not concern yourself with understanding every working part before you begin because that just isn't possible.
That said, before you start jumping into the actual game project you should really know the actual language you are jumping into. This is why I suggest you wait before attempting to tackle something where each part will prove impossible at your current level of skill.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement