4X Design Document up for Review
After taking a quick look though this recent thread and in particular sunandshadow's fine design doc (.doc, 355k), I was motivated to create a design document for my hobbyist project. This is my first doc, and my first non-trival game, and would be interested in any feedback people have on the Doc itself, and in the rough design. Project Moe Design Document (.doc, 113k) [edit: fixed the other doc link]
I've skimmed through your design document. It's not a bad start for a design. The game idea itself seems fine to me.
However, as it stands the design document seems incomplete (is it still a draft?). In my view, the design document has two roles; as a record of all game ideas layed out to ensure completeness of design and to aid in building the game, and as a method for communicating game ideas to an entire team (or if you are working solo, to ensure you don't forget). A lot of the game ideas seem fuzzy to me; I couldn't really get a good feel of how the game will play from reading your design. Pictures may help, even if they're just sketches. It might also be a good exercise to consider a walkthrough of a your game, considering everything that the player will do. Write down what the menus do, write down how a few sample turns will play out, and figure out what holes in the design need to be plugged in.
This might also just be a personal preference, but it might be a good idea to put a couple of paragraphs at the start of the document listing your own personal objectives for making the game, and what makes your game special. Put in something to make the reader enthusiastic that your game will be great, even if your only target audience for the doc is yourself. This is especially important if you are going to use your design doc to try and sell your game idea to other potential team members. At present, you start off with "Moe is a run of the mill turn base strategy or 4X game", which isn't really that inspiring [wink].
Note that everything here is my opinion; mileage may vary depending on your personal tastes in design docs [grin].
However, as it stands the design document seems incomplete (is it still a draft?). In my view, the design document has two roles; as a record of all game ideas layed out to ensure completeness of design and to aid in building the game, and as a method for communicating game ideas to an entire team (or if you are working solo, to ensure you don't forget). A lot of the game ideas seem fuzzy to me; I couldn't really get a good feel of how the game will play from reading your design. Pictures may help, even if they're just sketches. It might also be a good exercise to consider a walkthrough of a your game, considering everything that the player will do. Write down what the menus do, write down how a few sample turns will play out, and figure out what holes in the design need to be plugged in.
This might also just be a personal preference, but it might be a good idea to put a couple of paragraphs at the start of the document listing your own personal objectives for making the game, and what makes your game special. Put in something to make the reader enthusiastic that your game will be great, even if your only target audience for the doc is yourself. This is especially important if you are going to use your design doc to try and sell your game idea to other potential team members. At present, you start off with "Moe is a run of the mill turn base strategy or 4X game", which isn't really that inspiring [wink].
Note that everything here is my opinion; mileage may vary depending on your personal tastes in design docs [grin].
It's not so much a draft as a first run.
Quite a few of the big parts [professions, technologies, projects] don't have details yet. Partly because details aren't too essential to technical design [they're just content], and partly because those particular details will likely owe their balance towards other elements such as birth/death rate.
A few other big parts [birth/death rates, trade, Unit actions] are hard to get a grip on without a prototype to toy around with.
And I wanted to get at least the majority of big ideas, and 'things to keep in mind as possible' together before building said prototype. As things become a little more than "hey that's a good idea" they'll get put into the doc.
Anyways, I suppose I should add some context at the beginning. I'm not so good at selling things :]
Perhaps also some sort of Timeline/Milestone list at the end?
Quite a few of the big parts [professions, technologies, projects] don't have details yet. Partly because details aren't too essential to technical design [they're just content], and partly because those particular details will likely owe their balance towards other elements such as birth/death rate.
A few other big parts [birth/death rates, trade, Unit actions] are hard to get a grip on without a prototype to toy around with.
And I wanted to get at least the majority of big ideas, and 'things to keep in mind as possible' together before building said prototype. As things become a little more than "hey that's a good idea" they'll get put into the doc.
Anyways, I suppose I should add some context at the beginning. I'm not so good at selling things :]
Perhaps also some sort of Timeline/Milestone list at the end?
I understand the need to throw things down into the doc; in my present design document I'm just typing things down as I think of them to reorganise later. And in my case, I haven't yet started on a personal game project big enough to justify a completed design document yet so I'm not sure exactly what works best. My training was in software engineering, where you had to put everything into your software requirements specficiation for the customer to sign off, otherwise there'd be serious problems when they inevitably change their minds about things [smile].
While it's most likely overkill to put in all the little details about everything at this stage, I'd probably put in a dot point list about all the features each game element could have. For example, specifying how many hit points or how much damage a unit does can be done with a prototype, but things like stating units can fly or deal different damage types I'd put in the design. Another example from your design would be with the races; I'd probably plan the code architecture differently if there were three hardcoded races rather than if you go with your custom race idea. I think most of this stuff is already in there, but maybe a summary dot point list would just make it a bit clearer.
A Timeline/Milestone list is good too; I'm not sure if I'd put this in the design or a separate document. I'd also include a section specifically on the user interface with a few rough sketches, as that's fairly critical (and I don't think you've covered that yet)
Note that while I might be being a bit critical here, I do like the basic gameplay ideas, and what I've read seems really interesting; the balance of three or more different races could lead to a good turn-based strategy game. You might also be planning on solving a lot of these problems in a subsequent architectural or functional design doc when you plan out the code.
While it's most likely overkill to put in all the little details about everything at this stage, I'd probably put in a dot point list about all the features each game element could have. For example, specifying how many hit points or how much damage a unit does can be done with a prototype, but things like stating units can fly or deal different damage types I'd put in the design. Another example from your design would be with the races; I'd probably plan the code architecture differently if there were three hardcoded races rather than if you go with your custom race idea. I think most of this stuff is already in there, but maybe a summary dot point list would just make it a bit clearer.
A Timeline/Milestone list is good too; I'm not sure if I'd put this in the design or a separate document. I'd also include a section specifically on the user interface with a few rough sketches, as that's fairly critical (and I don't think you've covered that yet)
Note that while I might be being a bit critical here, I do like the basic gameplay ideas, and what I've read seems really interesting; the balance of three or more different races could lead to a good turn-based strategy game. You might also be planning on solving a lot of these problems in a subsequent architectural or functional design doc when you plan out the code.
Oh no, this sort of feedback is exactly the sort of thing I was looking for, and is actually criticism rather than... bashing I suppose is the opposite.
And yes, I kind of did this as a game design doc [for rules] assuming there would be a seperate technical design doc [for implimenting the rules, as well as UI]. But like you its my first, and I don't even have the benefit of training on tech docs, just a little perspective from the QA side of consuming them.
And yes, I kind of did this as a game design doc [for rules] assuming there would be a seperate technical design doc [for implimenting the rules, as well as UI]. But like you its my first, and I don't even have the benefit of training on tech docs, just a little perspective from the QA side of consuming them.
I sorta skimmed it. Like TrapperZoid, I didn't find it to be well-structured enough for others to quickly understand, but then my design docs are essentially just lists of ideas anyway..
One thing for sure is that if you can pull it off, it sounds like it would be an awesome game to play.
One thing for sure is that if you can pull it off, it sounds like it would be an awesome game to play.
Quote:
At present, you start off with "Moe is a run of the mill turn base strategy or 4X game", which isn't really that inspiring.
Heh, I'm not big for inspiration, but here's an updated Background:
Moe is a run of the mill turn based strategy or 4X [explore, expand, exploit, exterminate] game. Play begins with players creating an empire to lead through time, hopefully building the budding little empire to rule the world. The game ends with one empire completing one of the victory conditions.Well, that’s not so special! Exactly. Since the game pulls from a common genre, it is immediately recognizable to players, as well as being easy to pickup for players experienced with turn based strategy games [the target audience]. Further, since much of the mechanisms are being blatantly ‘borrowed’ from other games (which most often ‘borrowed’ them from others…), it leaves less room for implementation error. A good idea is useless if it is implemented poorly [see Master of Orion 3].Why shouldn’t I buy those games then? Ah, the more important question. Firstly, there hasn’t been a fantasy 4X game for the PC in about 10 years [Master of Magic]. Secondly, there are some significant gameplay features which should be unique to Moe:- Innovative dynamic racial customization system, which includes three distinct species.- A tech tree that includes spells as well as magical and psionic techniques alongside traditional technologies.- Variable knowledge levels.- Construction unbound to cities.- A resource/trade system that grows with infrastructure as well as technology.- Population as a finite resource, in life, death and undeath.
Quote:Well, if you don't count Age of Wonders and sequel, or Dominions 2 etc..
there hasn’t been a fantasy 4X game for the PC in about 10 years [Master of Magic]
Quote:
Original post by Argus2 Quote:Well, if you don't count Age of Wonders and sequel, or Dominions 2 etc..
there hasn’t been a fantasy 4X game for the PC in about 10 years [Master of Magic]
Age of Wonders, Dominions (as far as I can tell), [as well as Battle for Wesnoth, the Warlords Series, and countless others] are missing the exploit X, as well as the explore X usually and (imo) are much closer to traditional wargames.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement