Any standard to game design documentation?
Posted 14 April 2011 - 04:35 AM
To start, I have been working on this project as a hobby theory wise in my head for a number of years. After working through 3-4 major game design ideas and finding major flaws in them I decided to go in reverse, basically building backwards from the “endgame” I envision. The majority of this latest world and all of its components are in my head, and the complexity is becoming way too difficult to keep track of, (especially after a year of slowly adding and revising systems so they don’t break each other). So I'm looking for ways to organise on paper now in a way that not only myself, but others can follow and look for places I have screwed up, and to expand detail upon.
I won’t get into many details of the game, but I will mention the fact that by trade I work in the engineering/design/tooling industry, so working with complex systems where any variable can greatly affect a number of other systems is not foreign to me. That work for example is generally easily seen through sketches, cad programs, simulations, and other real world material examples.
However, when it comes to software I have very little experience with any form of programming, and virtually 0 when it comes to proper methods of laying out complex rule sets in text form for such programs. So not only can I not program or script any working examples or demos at this time, I’m not even sure how to properly convey my ideas to someone that does work in those fields.
To help that, I am looking at playing around with the torque engine (bought a basic 3d pro license the other day) So my goal is to eventually learn some basics behind coding and scripting, but at this point with my fulltime work it will almost certainly be a slow process.
Now that’s not to say I’m “completely” clueless about programming, I have worked with PCs since I was pretty young and worked a bit with modifying other peoples scripts, do machine programming, browsed through programming books, written tiny bits of code in school, and talked to friends that do programing for a living, so think I have a pretty rough idea of how coding ticks at the core, I just don’t know the language, or proper forms to make anything out of it myself. As such, I "think" i generally know the type of logic and rules a programmer might be looking for if they were to create something.
So when it comes to putting these ideas on paper, I had a few ideas in mind. One would be creating drawings showing scenarios of possible actions from players and the effects to the state of the game world. Secondly, some flow charts for certain major systems and as you move into more detailed or complex aspects, the only way I see is to write detailed documents giving game elements tags or references of some sort that can link them to absolutely everything they effect.
So I'm curious about methods of creating complex software rule sets that others can look at, maybe read, and make sense of? Are there widely accepted formats that are an industry standard for game programming? If so can these be found online as examples, or through certain books?
This entire project is primarily a “fun” project for myself, and some friends I have involved, but I do think I have a very solid set of game ideas in place that is scalable to a small world. So with some work, I believe someday I could build various test models that would have most of the major full scale world mechanics incorporated, hence the reason I would really like to go about the entire process in a semi proper way.
If anyone has suggestions, or if there are examples, books, or any other resources that go into detail about organizing projects like this and you can point me towards them I would greatly appreciate it.
Posted 14 April 2011 - 01:41 PM
- IMO, wikis rock for collecting game design document information. You can easily link into other pages and such. Make each page an "atomic" (in the sense of indivisible) unit and cross-link extensively. You'll cycle, allowing a little brainstorming explosion of info, but then having to collate it back into a succinct set, ad nauseum.
- A template helps. Google for more variants.
- Remember your audience. Is it just yourself, or any other targets?
- Get a couple of books on this topic, if only to get the lingo and help you search more effectively.
Posted 14 April 2011 - 04:28 PM
Posted 18 April 2011 - 02:41 AM
I've used MediaWiki for a number of projects, and recommend it highly. It's the Wikipedia software, from Wikipedia, bundled for the do-it-yourselfer, free to download and use.
Upload it to your web host, create a MySql database, update the MediaWiki config page with your database settings, browse the Installer page, answer a few questions, next thing you know it's your very own wiki.
The wiki makes it easy to record new ideas based on keywords, because wiki uses keywords as page names. You start with a Main Page, the home page. Make a few notes about your key ideas. Mark up the keywords as links by enclosing the keywords in double square braces. (There's a simple Wiki markup language, much simpler than HTML, the wiki program translate the markup into full HTML.) When you view the page, the marked-up keywords are now links. Click on a link, you go to the page by that name. If the page exists, it gets displayed; if the page doesn't yet exist, your browser displays the page editor, so you can get to work on the new page. Add more content, make more links. It's easy to build up content quickly, try some ideas, see where they go -- it's quick, encourages brainstorming creativity.
Meanwhile, other team members are editing existing pages, making new pages, adding and refining. Everybody can see and share the entire body of work, and there are various mechanisms for adding comments, annotations, etc.
Furthermore, the wiki keeps track of every single change from end to end, with notes about who did what, when they did it, and so on. Obviously for the real Wikipedia, you need this to revert vandalism. But even in a team effort where everyone plays nice, it's still a huge benefit to have a version control system keeping tracking, so you can view progress, retrieve long-deleted items that you wish you'd kept, etc.
If you want privacy -- a team-only wiki -- there a several things you can do:
(1) In the MediaWiki config:
A. Restrict page view to logged-in users, redirect all others to the Main Page (the home page for the wiki, which is always public).
B. Restrict editing to logged-in users.
C. Restrict account creation, no self-registration, admin must create new users
(2) HTTP username/password
Set the server to require a username and password for the folder where you installed MediaWiki. This is a server thing, not a MediaWiki thing as such. You can do this through the web host account control panel (for some web hosts anyway, I think it's common now; if you don't have that control panel feature, contact your web host).
When a user browses any URL in the protected folder/subfolders, the server requires a username and password -- if the login fails, the server doesn't send the page, instead the user gets a "Forbidden" message.
For more game design tips, see my game design blog, the Handy Vandal' Almanac:
Posted 20 April 2011 - 03:30 AM
For now, my primary focus was to create an sustainable endgame built around a number of interdependent systems. Each system by itself is logical and straight forward, but combined become fairly complex, so I'm finding it very difficult to put them in an understandable text form that shows them working as a whole. Because of that Ive been looking at creating proper sorts of flowcharts to describe the systems and how they interact with each other, hopefully so people other then myself can troubleshoot the systems and look for contradictions or flaws.
Hoping to have that worked out over the next 2-3 months as I have time to write /create charts and allow people to look over them. From there, probably will look at plugging some numbers into the systems and get some idea of a solid baseline, as well as figure out which #s to modify to effect the end values. Then well begin building classes / skill systems on paper and maybe someday begin building some of it into an engine. IMO, you don't have anything unless your endgame is solid so everything else such as leveling / quest / and shiny stuff are barely even in the picture yet.
Far fetched dreams, but like I said before its mostly for fun and a learning experience for myself and some others.
Posted 20 April 2011 - 12:26 PM
Posted 20 April 2011 - 01:29 PM
"Organizational ceremony" -- nice phrase, the word "ceremony" really captures the essence.
It's like some people say at dinnertime: "Don't stand on ceremony, dig in!"
Posted 20 April 2011 - 04:24 PM
If you don't mind a bit of reading, check out the IEEE 830-1998 Recommended Practice for Software Requirements Specifications and IEEE 829-1998 Standard for Software Test documents. There might be some free ones lurking around on the web. These are two solid guidelines for engineering software. Also have a look at the Software Development Process. There are a bunch of development processes, each catering for a specific need. Given your current position, I would look into the software prototyping or the spiral process. These are just guidelines, but they help orient your workflow, which is important to stay organized and focused.
Finally, look into UML to architect your software. You spoke about using flow charts to illustrate the relationships between your components, well that's exactly what UML was designed to do. It allows you visually show others the logical flow of your components, the relationships between classes and modules, the packaging structure, and more. A great tool for developing with UML is Visual Paradigm (just to get your started). Some software (mostly commercial ones, like Visual Paradigm) supports exporting your model to source code, thus eliminating part of the programming exercises.
Posted 20 April 2011 - 04:52 PM
I'm thinking earlier in the process of idea gathering, I guess. As for the collaboration stereotype, wikis are great even for solo brainstorming-like activities. It's basically like a mind-mapping tool.
It's definitely poor for formal presentation, say to investors or publishers. That's when you want to pull out Word and select and tailor the info for the particular audience.
As for architecting the app once the ideas are all there, UML is a good defacto notational system. Also, you may want to get familiar with a workflow notation (like BPML), since activity diagrams are poor at capturing the complexity that can exist.
BTW, this is a must-read for game designers, peripherally related to the above topic:
Posted 25 April 2011 - 02:56 AM
This weekend I have been working through a Python book and finding it extremely fun to learn. I'm doing allot of experimenting on my own outside of the books projects so I'm only on the second chapter, but now I really wish I had picked up a programing book 10+ years ago.
So not only is it something I'm very interested in learning, I think it will really help with my organization on a number of levels that would carry over into my project.
Posted 25 April 2011 - 04:10 PM
Dig into programming, it's never too late. I'm cheering you on, because I'm a programmer myself, and I'm here to tell you that programming can be an art and a joy, and that anyone who has a taste for programming will find that they have a hunger for it. Writers love to write, painters love to paint, dancers love to dance ... programmers love to program.
I haven't worked with Python, but I understand it's a good solid modern programming language.
Programming relates to the main thread of this page -- how to organize a complex project -- in any number of ways. In particular, consider object-oriented programming, and the concept of Class:
Classes represent the real world, the codified definitions of your problem domain. Classes make you think about your subject matter before writing actual working code. If you have a solid understanding of your goals, your classes will reflect this understanding. If your goals are half-formed and uncertain, you'll find out when you try to define classes that you don't know what you're trying to define. Good classes are good because they document what you are doing, in advance of you doing it.
Another possibility -- this is something I'm looking into right now -- is a Facebook application. Wouldn't necessarily teach you structured programming ... but it might be a quick-and-dirty way of getting the goods to market.
Anyhoo, I'm cheering for ya -- may your code be triumphant, and your bugs easily squished!
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users