Jump to content

Design Document Proposal


Nullus
 Share

Design Document Proposal  

8 members have voted

  1. 1. Should this content be accepted for the design document?

    • Yes, I think this content should be accepted
    • No, I don't think this content should be accepted
    • Yes, I think this content should be accepted, but with some changes (please specify in the comments)


Recommended Posts

As mentioned at https://wildfiregames.com/forum/topic/77438-looking-back-on-the-balancing-strategy/, a new design document is required. This is my proposal for a design document. If the community approves of this, it could be adopted and design documents could be revised for the civilisations. This is a design for the general gameplay, not for any civilisations. Most elements will remain the same, I've only mentioned elements that could change or which need to be clearly defined. 

All features which require mechanics not yet added to the game are highlighted in red.

  Reveal hidden contents

 

Edited by Nullus
ChronA's comments
  • Like 5
Link to comment
Share on other sites

I suggest that a more in depth discussion of counter relationships for each unit type and any unusual information about attack interactions or composition synergies/anti-synergies should be added. E.g. for the spearman line:

Spearmen will usually be the basic melee troop, armed with spears. They will have moderate damage, armor, and speed, and a strong attack bonus against cavalry. They will have a slightly longer attack range than sword units [interaction quirk] and therefore benefit more from fighting in dense formations than swordsmen [synergy]. They should decisively lose to an equal value of pikes in dense formation fighting [situational counter]. In equal value comparisons, Spearmen should effectively counter sword cavalry, spear cavalry, rams, catapults, and artillery towers. They should be countered by elephants, swordsmen, skirmishers, slingers, archers, crossbowmen, javelin cavalry, archer cavalry, bolt shooters, and fortresses.

(note: when you write it up this way, the spearman line looks pretty bad huh?)

Other suggestions:

I think the Mechanics section needs to be filled out with more information about civ phases, techs, resource harvesting, production, and all that jazz. I'm sure that was the intent already for that section but its worth making explicit. 

I would also add a separate section after the Units & Structures to cleanly summarize of the key counter cycles:

Counter Cycle Design

The tactics of combat engagements will be characterized by the following type-counter relationships:
melee cavalry > ranged infantry > spearmen > melee cavalry
ranged cavalry > swordsmen, spearmen > melee cavalry > infantry archers > ranged cavalry

[etc...]

And lastly, I would add a section about civ design principles. This should lay out the logic of designing a multiplayer-viable civ, the temporal and geographic bound of the game's representation, maybe list some civilizations. Others with a stronger sense of the game's vision can opine on what to say here. The one thing I would urge you to put in writing is that Every civilization will have access to at least one viable counter to every established unit type. While that sounds completely obvious, I think it is important to stress because it runs counter to the intuitive civ development methodology the game is built around. We're not starting with the question "what would be a fun faction concept to play with." We are starting with real civilizations and trying to represent them in the game. But real civilizations were not balanced. They did not always have answers to every military doctrine. When they met a doctrine they could not deal with they either changed their own identity or ceased to exist, which makes it hard to to produce iconic, accurate, and balanced representations.

 

Make these changes and I think you will have a good format and foundation to build from. Then the real work of debating about design and balance philosophy can begin.

  • Like 2
Link to comment
Share on other sites

  On 24/04/2022 at 1:01 PM, ChronA said:

I suggest that a more in depth discussion of counter relationships for each unit type and any unusual information about attack interactions or composition synergies/anti-synergies should be added.

Expand  

This would be good, yes. I'll update the proposal to reflect this.

  On 24/04/2022 at 1:01 PM, ChronA said:

I think the Mechanics section needs to be filled out with more information about civ phases, techs, resource harvesting, production, and all that jazz. I'm sure that was the intent already for that section but its worth making explicit. 

Expand  

The eventual design document should include this, certainly. However, for this proposal I'm only listing any features that I think should be changed or which I think need to clarified.

  On 24/04/2022 at 1:01 PM, ChronA said:

And lastly, I would add a section about civ design principles. This should lay out the logic of designing a multiplayer-viable civ, the temporal and geographic bound of the game's representation, maybe list some civilizations. Others with a stronger sense of the game's vision can opine on what to say here. The one thing I would urge you to put in writing is that Every civilization will have access to at least one viable counter to every established unit type. While that sounds completely obvious, I think it is important to stress because it runs counter to the intuitive civ development methodology the game is built around. We're not starting with the question "what would be a fun faction concept to play with." We are starting with real civilizations and trying to represent them in the game. But real civilizations were not balanced. They did not always have answers to every military doctrine. When they met a doctrine they could not deal with they either changed their own identity or ceased to exist, which makes it hard to to produce iconic, accurate, and balanced representations.

Expand  

This sounds like a good idea, but I'm not sure if it really fits in the general design document. This could be done along with the pages for the individual civilisations, but I think the overall design document should describe how the game should play in general, not the specifics of civilisation design. I will add the information about viable counters, thank you.

  On 24/04/2022 at 4:14 PM, Outis said:

If we want to vote and propose changes, then I propose to do so on smaller chuncks. Arguments and agreement will be easier to track.

Expand  

Perhaps, but I'd like to keep this issue as centralised as possible for now. I have tried to avoid adding anything too controversial, so I don't think that should be too much of an issue at the moment.

  • Like 4
Link to comment
Share on other sites

Thank you for your effort on this! :)

I must say this Design Document rather looks like an result of one? It looks more as an implementation of a design than a design itself? But I could be mistaken.

For a DD I would expect more something along the lines of the tail of this post:

 

  • Like 3
Link to comment
Share on other sites

  On 25/04/2022 at 5:18 AM, Freagarach said:

I must say this Design Document rather looks like an result of one? It looks more as an implementation of a design than a design itself? But I could be mistaken.

For a DD I would expect more something along the lines of the tail of this post:

Expand  

I'm not sure if we have the same understanding of what the design document should be. What I meant by the term was a document that describes how how the game should play. Basically, I meant a set of goals for the design, not a description of how the design itself should be performed.

Link to comment
Share on other sites

IMO, what makes a good design document is that the design document + the technical documentation of the engine and and any other development tool + any good encyclopedia should give enough information for any competent developer to deliver the completed product.

Yes, that does not usually require specifying exact unit stats or civilizations to include, but that is because this information is implied by the more general descriptions of the gameplay and the scope of the project given by the design doc. On the other hand though sometimes is is necessary (or maybe a better word is proper) to get into specifics. The most useful thing the design doc can do is let you detect problems before you go to the trouble of actually writing code. That is easier to do when systems are described directly. (This is why I suggest describing counter cycles in detail, we know that this is a hard thing to get right. Being specific about them makes it easier to to spot any contradictions and logic holes before someone has to start interpreting the intent into working code. Their job is hard enough already.) 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

you are right when you say that clear and throughout design is a good thing when developing software. this is something 0AD lacks. but don't let you be distracted by it.

that level of design comes right before implementation, and should be the product of the dialogue between the developers who are currently working on that issue, and the community (in a corporate setting, that would be called customer oriented - also consider the Agile statement that working software is more important than comprehensive documentation, and that responding to change is more important than following a plan). if you put design too much before development, than you are building on quicksand: even the most polished design may prove ineffective or brocken in the end, for whatever reason you couldn't foresee.

a design document should indeed look much more alike what hyperion proposed, and finally, it would be very useful if really adopted by the team and its management: I can see here that people are still confused about what civ differentiation should achieve, what level of micro should be required, how good is rock-paper-scissors design, what's should it be the purpose of territory, what level of snowballing is best, why some tactics are considerd abusive and some aren't, etc...

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...