anyways, I want to start hammering out a very simple game that basically will test whether certain features I want in my game are valid or not. Since I''ve never designed a game before, how exactly do you know what to prototype or not to test your ideas? I''m trying to figure out if I should protoype the elements based on diffuculty, or based on how essential the element is to the flavor of the game.
A little background would probably help. The game will be set in the sort of near future (2160AD). Game will be more on a grand scale, about divisional level for battles (roughly 4-10,000 men/units...or in game scale, roughly 100-300 of the smallest organized unit type).
Here''s my list in no particular order:
1) Hybrid real time/turn based sequence- fights are in real time, order phase is turn based)
2) Ability to modify/define units- i.e. units attributes are definable by the player before the game starts (possibly during the game...but I''m iffy on the tech tree thing)
3) Creation of templates- to create container classes that define Organized Units. OU''s are made up of base individual units) which are then defined by the templates
4) Officer system of control- Units are not directly clicked on, the interface to control the units are through Officer objects. Read#8 for more info on how control will work.
5) Ordering system- an interface system via the Officer objects that allows you to "script" how the Organized Unit will act and behave.
5a)If possible, the creation of simple logic algorithms to further define behavior (for example, IF (enemy) MOVES to POSITION (DH25), THEN order = attack(), ELSE order = opportunityhold())
6) Faction Design- the ability to define your country''s resources and capabilities. For example, setting natural resources, manufacturing centers, cultural bonuses, etc.
7) Logistics based vs. Resource based- the country you play has a certain output every turn, however, getting them to the fighting units is just as crucial if not more so. The system that will get replacements and new Organized Units to the fighting front will be based on a supply infrastructure more than a "building" infrastructure. (this is actually a more tactical consideration than a strategic one...strategic considerations will be the "building" equation of how much industrial capacity your country has).
This also implies that all units will have an "endurance" trait covering their ammo and fuel, and even fatigue for soldiers. This is exactly what I want, because few games out there really make you think about tiring out or exhausting your units expendables (this will allow for siege style strategies, denying the enemy any logistics reinforcement and supply)
8) Communication Tokens- all units gather information that must be passed via communication tokens to every other object in the game...including the player. The player will be an object on the board called an avatar. The player only knows about, and can control those officers from whom he has received the comm token. Tokens are relayed from base unit <-> officer <-> (officer+1 rank) or avatar.
9) Campaign mode- Fights will be based not per battle, but by campaigns. You must allocate your logistics, your transports, and when and where you chose to fight. This also means that units will gain experience between battles but will also suffer battle casualties.
I''d really like all of these elements, though I think #6 and #2 will be the last things I will attempt to do. I think that #4 and #8 go hand in hand, and I''m not sure if I can do one without the other. I know it''s a diffuclut question with my limited info, but what would be the most diffucult elements on my list below so I can do them last? I know that the features list above is all very complex, so I''ll slowly build on them, but I need to figure out which ones are dependent on other features, and also figure out how I can minimize the complexity, but still capture the essence of the feature. Any suggestions would be helpful, even just flat out saying what I''m accomplishing is too hard.
15 users logged in
Proud partner of GDC 2025
Before posting, review our community guidelines.
Support GameDev.net with a monthly GDNet+ subscription!
Prototype prioritization
September 29, 2002 10:59 AM
wow, don''t say the subject ten times fast
anyways, I want to start hammering out a very simple game that basically will test whether certain features I want in my game are valid or not. Since I''ve never designed a game before, how exactly do you know what to prototype or not to test your ideas? I''m trying to figure out if I should protoype the elements based on diffuculty, or based on how essential the element is to the flavor of the game.
A little background would probably help. The game will be set in the sort of near future (2160AD). Game will be more on a grand scale, about divisional level for battles (roughly 4-10,000 men/units...or in game scale, roughly 100-300 of the smallest organized unit type).
Here''s my list in no particular order:
1) Hybrid real time/turn based sequence- fights are in real time, order phase is turn based)
2) Ability to modify/define units- i.e. units attributes are definable by the player before the game starts (possibly during the game...but I''m iffy on the tech tree thing)
3) Creation of templates- to create container classes that define Organized Units. OU''s are made up of base individual units) which are then defined by the templates
4) Officer system of control- Units are not directly clicked on, the interface to control the units are through Officer objects. Read#8 for more info on how control will work.
5) Ordering system- an interface system via the Officer objects that allows you to "script" how the Organized Unit will act and behave.
5a)If possible, the creation of simple logic algorithms to further define behavior (for example, IF (enemy) MOVES to POSITION (DH25), THEN order = attack(), ELSE order = opportunityhold())
6) Faction Design- the ability to define your country''s resources and capabilities. For example, setting natural resources, manufacturing centers, cultural bonuses, etc.
7) Logistics based vs. Resource based- the country you play has a certain output every turn, however, getting them to the fighting units is just as crucial if not more so. The system that will get replacements and new Organized Units to the fighting front will be based on a supply infrastructure more than a "building" infrastructure. (this is actually a more tactical consideration than a strategic one...strategic considerations will be the "building" equation of how much industrial capacity your country has).
This also implies that all units will have an "endurance" trait covering their ammo and fuel, and even fatigue for soldiers. This is exactly what I want, because few games out there really make you think about tiring out or exhausting your units expendables (this will allow for siege style strategies, denying the enemy any logistics reinforcement and supply)
8) Communication Tokens- all units gather information that must be passed via communication tokens to every other object in the game...including the player. The player will be an object on the board called an avatar. The player only knows about, and can control those officers from whom he has received the comm token. Tokens are relayed from base unit <-> officer <-> (officer+1 rank) or avatar.
9) Campaign mode- Fights will be based not per battle, but by campaigns. You must allocate your logistics, your transports, and when and where you chose to fight. This also means that units will gain experience between battles but will also suffer battle casualties.
I''d really like all of these elements, though I think #6 and #2 will be the last things I will attempt to do. I think that #4 and #8 go hand in hand, and I''m not sure if I can do one without the other. I know it''s a diffuclut question with my limited info, but what would be the most diffucult elements on my list below so I can do them last? I know that the features list above is all very complex, so I''ll slowly build on them, but I need to figure out which ones are dependent on other features, and also figure out how I can minimize the complexity, but still capture the essence of the feature. Any suggestions would be helpful, even just flat out saying what I''m accomplishing is too hard.
anyways, I want to start hammering out a very simple game that basically will test whether certain features I want in my game are valid or not. Since I''ve never designed a game before, how exactly do you know what to prototype or not to test your ideas? I''m trying to figure out if I should protoype the elements based on diffuculty, or based on how essential the element is to the flavor of the game.
A little background would probably help. The game will be set in the sort of near future (2160AD). Game will be more on a grand scale, about divisional level for battles (roughly 4-10,000 men/units...or in game scale, roughly 100-300 of the smallest organized unit type).
Here''s my list in no particular order:
1) Hybrid real time/turn based sequence- fights are in real time, order phase is turn based)
2) Ability to modify/define units- i.e. units attributes are definable by the player before the game starts (possibly during the game...but I''m iffy on the tech tree thing)
3) Creation of templates- to create container classes that define Organized Units. OU''s are made up of base individual units) which are then defined by the templates
4) Officer system of control- Units are not directly clicked on, the interface to control the units are through Officer objects. Read#8 for more info on how control will work.
5) Ordering system- an interface system via the Officer objects that allows you to "script" how the Organized Unit will act and behave.
5a)If possible, the creation of simple logic algorithms to further define behavior (for example, IF (enemy) MOVES to POSITION (DH25), THEN order = attack(), ELSE order = opportunityhold())
6) Faction Design- the ability to define your country''s resources and capabilities. For example, setting natural resources, manufacturing centers, cultural bonuses, etc.
7) Logistics based vs. Resource based- the country you play has a certain output every turn, however, getting them to the fighting units is just as crucial if not more so. The system that will get replacements and new Organized Units to the fighting front will be based on a supply infrastructure more than a "building" infrastructure. (this is actually a more tactical consideration than a strategic one...strategic considerations will be the "building" equation of how much industrial capacity your country has).
This also implies that all units will have an "endurance" trait covering their ammo and fuel, and even fatigue for soldiers. This is exactly what I want, because few games out there really make you think about tiring out or exhausting your units expendables (this will allow for siege style strategies, denying the enemy any logistics reinforcement and supply)
8) Communication Tokens- all units gather information that must be passed via communication tokens to every other object in the game...including the player. The player will be an object on the board called an avatar. The player only knows about, and can control those officers from whom he has received the comm token. Tokens are relayed from base unit <-> officer <-> (officer+1 rank) or avatar.
9) Campaign mode- Fights will be based not per battle, but by campaigns. You must allocate your logistics, your transports, and when and where you chose to fight. This also means that units will gain experience between battles but will also suffer battle casualties.
I''d really like all of these elements, though I think #6 and #2 will be the last things I will attempt to do. I think that #4 and #8 go hand in hand, and I''m not sure if I can do one without the other. I know it''s a diffuclut question with my limited info, but what would be the most diffucult elements on my list below so I can do them last? I know that the features list above is all very complex, so I''ll slowly build on them, but I need to figure out which ones are dependent on other features, and also figure out how I can minimize the complexity, but still capture the essence of the feature. Any suggestions would be helpful, even just flat out saying what I''m accomplishing is too hard.
The world has achieved brilliance without wisdom, power without conscience. Ours is a world of nuclear giants and ethical infants. We know more about war than we know about peace, more about killing than we know about living. We have grasped the mystery of the atom and rejected the Sermon on the Mount." - General Omar Bradley
2,123
September 29, 2002 06:15 PM
1 and 9 are related. 2 and 3 are related. 4, 5 and 8 are related. 6 and 7 are related.
Tackle them in these logical groups, attempting to determine what functionality is basic and common to all elements in the group. Then try to build upwards and integrate these elements. Perform each group prototyping as a completely independent project. Gradually integrate the groups.
Tackle them in these logical groups, attempting to determine what functionality is basic and common to all elements in the group. Then try to build upwards and integrate these elements. Perform each group prototyping as a completely independent project. Gradually integrate the groups.
213
September 30, 2002 01:37 AM
Dauntless-
Above all things, two words come to mind. Object Oriented! I'm sure you know all about it so I won't explain what it is, just remember that it is one of the most important things when prototyping (especially if there is a chance what you are doing now could end up in the final version).
But more specifically...
I agree with Oluseyi's grouping of your 9 sections. Personally here is how I would go with your development-
I believe the mixing of real-time and turn-based is one of the most imporant parts of your project. Therefore I would try and put these two together as soon as you can as this will make or break your game (and I am sure make ). If you can create the basic interfaces of both areas and then spend a lot of time on melding the two together as I think this is where you game will work best.
I know that the actual linking of the two sections together will be easy, but it is the individual elements of each section that relates to the other that is imporant. So for example graphics are a non-issue right now, what is imporant is things like the way creating a group in the order phase will change how the fight stage starts. Personally I wouldn't even bother putting in the actual fighting until you have linked the other two. However from your previous posts I have read it is obvious that the actual fighting will also be quite different so that would be the second thing you can work on.
Anyways, just some suggestions, if there are things you have never done before, don't make this the first time, make up some dodgy little demo to make sure you understand them (such as templates and virtual functions which I know you have been asking about lately).
Doolwind
PS It all sounds very doable, just take it small steps at a time and don't get discouraged if you run into any major problems, that is what we are here to fix for you.
[edited by - Doolwind on September 30, 2002 2:41:07 AM]
Above all things, two words come to mind. Object Oriented! I'm sure you know all about it so I won't explain what it is, just remember that it is one of the most important things when prototyping (especially if there is a chance what you are doing now could end up in the final version).
But more specifically...
I agree with Oluseyi's grouping of your 9 sections. Personally here is how I would go with your development-
I believe the mixing of real-time and turn-based is one of the most imporant parts of your project. Therefore I would try and put these two together as soon as you can as this will make or break your game (and I am sure make
). If you can create the basic interfaces of both areas and then spend a lot of time on melding the two together as I think this is where you game will work best. I know that the actual linking of the two sections together will be easy, but it is the individual elements of each section that relates to the other that is imporant. So for example graphics are a non-issue right now, what is imporant is things like the way creating a group in the order phase will change how the fight stage starts. Personally I wouldn't even bother putting in the actual fighting until you have linked the other two. However from your previous posts I have read it is obvious that the actual fighting will also be quite different so that would be the second thing you can work on.
Anyways, just some suggestions, if there are things you have never done before, don't make this the first time, make up some dodgy little demo to make sure you understand them (such as templates and virtual functions which I know you have been asking about lately).
Doolwind
PS It all sounds very doable, just take it small steps at a time and don't get discouraged if you run into any major problems, that is what we are here to fix for you
.[edited by - Doolwind on September 30, 2002 2:41:07 AM]
118
September 30, 2002 03:02 AM
quote: I''m trying to figure out if I should protoype the elements based on diffuculty, or based on how essential the element is to the flavor of the game.I''d prototype them in order of how essential the elements are to your vision. If you feel that they are important, then it''s best to work out how you''re going to implement them first. That way you can work the less-important elements'' implementation around the important elements'', which is as it should be.
I''d program the real-time and turn-based elements of your game completely separately. They are for all intents and purposes different games, plus it gives you a natural break in your project so you can tackle things in smaller chunks (which is vital in programs of any significant size).
One last bit of advice : do the officers sans units first, and make their command groups trivially size 1 so that you can extend them once the rest of the game is done (cooperative AI is *hard*).
and good luck with the project!
September 30, 2002 08:36 AM
Argus-
Good tip on designing the RT and turn based seperately. I''ve been trying to conceive of a model of how to do this but have been turning up a blank mind. But I think if I design them seperately (ala Shogun), it''ll be easier for me to design everything else.
Now that I think about it, this is the most crucial element for me to think through...since the ordering system, the officers, and the logistics system all hinge on how and when the player interfaces with the systems.
Doolwind-
Thanks for the tips. Maybe this is easy for experienced programmers, but this is all exceedingly diffucult for me. I was actually reading up on object oriented design analysis and I think I''ve got some ideas now. Do you have any experience with Use Cases or UML? Basically, I''m working on the analysis portion of the software requirements rather than the actual design, although I''m laying out some pseudo-code now. Hopefully the design will be coming soon though The really hard part actually seems to be the analysis though...trying to figure out what the requirements are and the problem domain that I need to solve. Afterall, if I don''t really answer that, then the software coding will be incomplete. But, being a bona-fide OO newbie coder, I''m sure the design elements will be hard too. But thanks for the help...any and all of it is appreciated.
Good tip on designing the RT and turn based seperately. I''ve been trying to conceive of a model of how to do this but have been turning up a blank mind. But I think if I design them seperately (ala Shogun), it''ll be easier for me to design everything else.
Now that I think about it, this is the most crucial element for me to think through...since the ordering system, the officers, and the logistics system all hinge on how and when the player interfaces with the systems.
Doolwind-
Thanks for the tips. Maybe this is easy for experienced programmers, but this is all exceedingly diffucult for me. I was actually reading up on object oriented design analysis and I think I''ve got some ideas now. Do you have any experience with Use Cases or UML? Basically, I''m working on the analysis portion of the software requirements rather than the actual design, although I''m laying out some pseudo-code now. Hopefully the design will be coming soon though
The really hard part actually seems to be the analysis though...trying to figure out what the requirements are and the problem domain that I need to solve. Afterall, if I don''t really answer that, then the software coding will be incomplete. But, being a bona-fide OO newbie coder, I''m sure the design elements will be hard too. But thanks for the help...any and all of it is appreciated.
The world has achieved brilliance without wisdom, power without conscience. Ours is a world of nuclear giants and ethical infants. We know more about war than we know about peace, more about killing than we know about living. We have grasped the mystery of the atom and rejected the Sermon on the Mount." - General Omar Bradley
213
September 30, 2002 06:59 PM
Dauntless-
I have worked with UML and use cases a bit. I learnt them at uni then used them a bit at work. I just found it was a way of bringing my wierd and wonderful brain storming into a more formal representation. I believe the strength in them lies in you being able to create a representation of your system in UML and anyone that knows UML should be able to pick it up and get a better understanding than if they picked up your scribbled notes on the back of a McDonalds napkin.
So if you are the only one reading them I wouldn''t worry too much, but if you plan to make larger games in the future it would certainly get you in better habits now if you learnt the basics of UML (it is a very simple subject I found, I think UML Distilled was the text I used, and it was tiny, but gave heaps of info).
I still think you should try and bring your two elements together as this would lead to you better understanding what you really need and don''t need in each individual part (based on how it fits into the big picture of both parts together). I do admit it would be a more complex than keeping them seperate, but well worth it.
Doolwind
I have worked with UML and use cases a bit. I learnt them at uni then used them a bit at work. I just found it was a way of bringing my wierd and wonderful brain storming into a more formal representation. I believe the strength in them lies in you being able to create a representation of your system in UML and anyone that knows UML should be able to pick it up and get a better understanding than if they picked up your scribbled notes on the back of a McDonalds napkin.
So if you are the only one reading them I wouldn''t worry too much, but if you plan to make larger games in the future it would certainly get you in better habits now if you learnt the basics of UML (it is a very simple subject I found, I think UML Distilled was the text I used, and it was tiny, but gave heaps of info).
I still think you should try and bring your two elements together as this would lead to you better understanding what you really need and don''t need in each individual part (based on how it fits into the big picture of both parts together). I do admit it would be a more complex than keeping them seperate, but well worth it
.Doolwind
September 30, 2002 07:04 PM
I know this is off topic but....
Dauntless this sounds like a great yet massive game.
How many people are working on it? (Well besides Oluseyi and Doolwind, lol. All kidding aside they have been very useful)
Dauntless this sounds like a great yet massive game.
How many people are working on it? (Well besides Oluseyi and Doolwind, lol. All kidding aside they have been very useful)
213
September 30, 2002 07:58 PM
Alpha_ProgDes, I think I can answer this question for you...
Oluseyi and I run a small business OlusDool, and we have about 500 people on Dauntless''s project. He is currently behind in payments to us by about $5mil but I am sure he''ll send the cheque through sooner or later
.
Doolwind
Oluseyi and I run a small business OlusDool, and we have about 500 people on Dauntless''s project. He is currently behind in payments to us by about $5mil but I am sure he''ll send the cheque through sooner or later
.Doolwind
2,123
September 30, 2002 08:09 PM
quote: Original post by Doolwind
...OlusDool
Come on! Give us credit for sexy-sounding names! The company''s called Doolus. See how we ingeniously squeeze four letters of both names into only six letters, using the patented lexicographic spatial overlap technology we developed?
We sizzle; we''re the shizzle.
September 30, 2002 08:16 PM
LOL!
y''all are crazy, lmao!
sorry for getting off topic... just wanted to know. :D
y''all are crazy, lmao!
sorry for getting off topic... just wanted to know. :D
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement