Design documents

Discussion about the project in general, organization, website, or any other details that aren't directly about the game.
Post Reply
Message
Author
User avatar
Vezzra
Release Manager, Design
Posts: 4673
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Design documents

#1 Post by Vezzra » Sun Mar 13, 2016 4:47 pm

I have a proposal wrt to the design process, I think we should reintroduce maintaining design documents, at least for basic/fundamental game mechanics, and for those that get sufficiently complex. However, what I have in mind isn't the original "requirements documents" which were based on versions, but design documents based on specific game mechanics (e.g. combat, species-empire relations, influence&happiness, etc.).

The reason why I want to propose that is my experience with the current design discussion about influence (and related mechanics). IMO it gets difficult to keep track what has been agreed upon/decided, what's still under consideration and what alternatives for the things still under consideration are on the table, etc. TheSilentOne currently tries to do that by posting summaries now and then, but this isn't ideal IMO, as those get buried in an ever growing thread.

I think it will be helpful if, for design discussions like that, we maintain design documents on the wiki, where the current consensus as well as the options still under discussion are specified. These documents will be continually revised, until a complete (maybe just for the time being, but still) consensus has been reached, so actual implementation can start.

If the game mechanics specified in a design document get revised/extended later on, the document needs to be revised/extended accordingly.

I'm aware that only the bits and pieces for which we start producing design documents now will actually be documented in this way, so the design document collection will be far from complete (the old requirements documents are so badly outdated that we can only archive them for historic reasons, no point in trying to base anything on them). But even if we only manage to write down those bits and pieces, I guess that's better than nothing.

The current game design only exists scattered among many, many threads, in the heads of the most active contributors, and what still applies of the old requirements documents.

Thoughts, opinions?

User avatar
MatGB
Creative Contributor
Posts: 3310
Joined: Fri Jun 28, 2013 11:45 pm

Re: Design documents

#2 Post by MatGB » Sun Mar 13, 2016 6:31 pm

I have a suspicion that whatever we end up doing will rarely, if ever, get updated.

But a document per area is definitely a better plan than the sorta roadmaps that get abandoned approach we currently have, and we're picking up so many contributors since we moved to Github that some way of organising things that isn't "wade through many many threads" has to be done.

For example, I'm sorta in charge of species development at the moment, except I've barely done anything because there's so much history and ideas both in threads here and on personal pages on the Wiki and it's a bit of a mess.

Another approach, for lesser stuff, is to make much greater use of the Github issues thing, I keep meaning to open a bunch of issues for stuff I want to do but don't have time to script, then either a) I have a reminder or b) someone else can do it (prime example is monstrous weapons and detection, we're all agreed they need fixing but no one's done it)

So yeah, in theory, it's a good plan, or at least better than the current non-system, but it'll need work (and reminders) to keep things up to date.
Mat Bowles

Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12277
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Design documents

#3 Post by Geoff the Medio » Mon Mar 14, 2016 12:08 pm

If someone wants to maintain "state of the discussion" documents on the wiki, that could be useful, but I suspect it would be a lot of work, and not of much use if not maintained diligently. I'm also not fond of the old-style design documentation which ended up being huge, overly detailed documents that took months to work out the details for, but which ended up being mostly irrelevant. I think things work much better for this project with an iterative implement-test-modify method, for which a design document can be a guide, but is not rigidly adhered to and doesn't have excessive details prescribed. This is unfortunately a bit more difficult for complete newcomers to start helping with, but most of them probably need to work on some smaller or design-independent issues for anyway...

Post Reply