Design Docs

ID:154090
 
Jun 17 2002, 6:07 pm
I have but one question:

Does anyone here use them?

I never have until my latest project, which I have restarted numerous times now due to poor design. Design is fairly simple when creating a fan game. Pretty much everything is laid out for you already!
Take DBZ games for example:
  • You're gonna have Saiyans, Humans, and Nameks at least!
  • You'll have powerlevel
  • You'll have certain enemies you will find at pretty much given locations.
  • * You're always going to use Dracon's code and icons
  • You'll always have all that other DBZ stuff. Gravity, Namek, etc...

    * This was just a joke, hopefully no one took it too seriously

    Pretty much everything else, if there is any more, is up to the creator.
    On the other hand, when you create an original game, it is more difficult. You aren't limited by much! Everything has to be thought up by the designer(s) of the game. This can lead to either an unfinished product, or a not-so-good game.


  • What kind of environment will my game take place in?
  • What kinds of weapons will it have? Or will it even have fighting in it?
  • What's the player's purpose in the game? Just be the strongest, or travel around and do quests a lot?
  • Lots more.



Anyway, if anyone wants to answer the original question, or comment on my post, please do.

-Joe


Link: GameDev.net - General Game Design Articles&Resources
This is a link to some good articles about game design. You may want to check out, specifically, the Design Documents articles the most, because that IS what this post was initally about...


P.S. I had to rewrite this 3 times -_- Stupid IE
Jun 17 2002, 6:35 pm (Edited on Jun 17 2002, 6:59 pm)
I write down everything for my TextMUD games. Everything from die rolls, to weapon stats. They're in my GM browser window.
Jun 17 2002, 8:36 pm
In programming in general, documentation is suuuuuch an imporant peice of the puzzle. A lot of programmers that I greatly respect, and try to emulate ( at least in meathod, not in style) actually spend more time sitting, wherever they feel most thoughtfull, with a pad and paper and just -write-, then they do in front of a keyboard. Generally, when you start coding without thinking (writing forces you to think) you wind up in a bigger mess then you start with.

A friend of mine was working as a programmer at one of the local mills, and he spent so much time out on the lawn in the sun, doing nothing but apparently doodling on a peice of paper, that his boss finally had to ask the rest of the department what he was doing with his time. *snicker* They finally showed him what he had done in his time there, and let me tell you, -he- wasnt the one that got fired ^_~

People also have this thing with code being writen in stone @.@ paper is psychologicaly much easier to modify. ^^

Sorry for the hugeass long reply @.@ I like to let people know what Im thinking ^^;;;;;;

El
Jun 18 2002, 5:54 am
I think that having a well thought-out plan for your game is key to getting it actually built.

A plan that you have spent time on developing all (or at least as many as possible) the things that can happen in your game means fewer surprises when it comes time to start coding.

A good design shows you where you can reuse objects, code, and/or libraries more efficiently and where new code needs to be developed.

To me a development plan should start small and be able to grow dynamically as you add features to the game - this helps to see where the integration between features will be, helping to isolate common elements...
Jun 18 2002, 5:07 pm
My design document for a given project is just a list of things that should be in the game. The things that I want to implement first are up high, and the things I want to do later are lower on the list. For example:

__ Players have a 10% chance of spontaneous combustion if they convert to Super Sampan without first eating Ramen noodles
__ Dalek Amulets provide 1 to 30% damage absorption for fire attacks

I don't worry too much about "design" in the sense of planning out an object hierarchy and the procs that I'll use. If the code starts to get too cumbersome, I refactor it to make it more logical.
Jun 21 2002, 8:48 pm
In response to Elorien
People also have this thing with code being writen in stone @.@ paper is psychologicaly much easier to modify. ^^

Surprisingly, I feel the other way around -- pseudocode is easy to write on paper, but if you're going to write actual program code on paper, you'll find it's far more of a headache.

That's typically why I use Windows Notepad to build my source lists rather than a pen and paper; pen and paper is good for brain storming, but Notepad is far better for making a set of things that is subject to change in order and size.


The most crucial thing I've found easier in Notepad than on a, er, notepad, is my ship console commands lists for Warrior. (Warrior is a former BYOND game I "made", that I'm planning on making into a full-fledged freeform space sim in a low-level programming language like C++. I still have 50-60 years left in which I can do it before becoming old and feeble, so I'm in no rush.)
Jun 21 2002, 9:04 pm
Kamoku wrote:
I have but one question:

Does anyone here use them?

On my personal projects I don't use them since I'm on no time restriction and most of them end up turning out way different than originally planned due to spontanious feature creep.

And on my school projects I use them since I have to :).
Jun 21 2002, 9:53 pm
Kamoku wrote:
Does anyone here use them?

The DDT has extrensive discussion about a game in email, and important points are migrated (now) to a special Bwicki for the team. Before the Bwicki, important points went into a notes.dm document in the project.

We don't try to follow any formal specification, but we do tend to flesh out the environment of the game and the gameplay. Sometimes very detailed, often just the outlines.

Actual development is iterative, with new builds of the game being posted nightly when we're in active development.

Often we make plans for a game months ahead of time, and it sits on a list of potential games. We're not quite as bad as Spuzzum or Lexy, but we are starting to get a good-sized list. However, in general, once we start into a game, we keep going until we finish it.

One thing that we've never been able to plan is which game we'll do when...no matter how much we think we know what the next game is, we often get passionate about an unexpected project when it comes time to make a decision.
Jun 21 2002, 10:26 pm
In response to Deadron
Often we make plans for a game months ahead of time, and it sits on a list of potential games. We're not quite as bad as Spuzzum or Lexy, but we are starting to get a good-sized list. However, in general, once we start into a game, we keep going until we finish it.

Though what I'm about to say isn't the whole truth, overall, I'm actually the same way; I like to get working prototypes in place rather than just leaving the ideas sitting in point form, but otherwise I make ideas for a game and then leave it on the back burner while I cook the current one up front.

The reason I'm saying that's not the whole truth is because I do that without planning to do that. ;-)


One thing that we've never been able to plan is which game we'll do when...no matter how much we think we know what the next game is, we often get passionate about an unexpected project when it comes time to make a decision.

Once all of my school obligations are taken care of (work experience, CAPP credit, graduation, overdue final CS 12 project, etc.) and my computer is upgraded successfully (last upgrade didn't take due to a ground fault that fried the new motherboard -- hence my absence over the past few days) I'll definitely be very capable of committing to a single project. Right now, my priority is getting my spuzzum.byond.com website up and running, but that's only a 1 or 2 week job; once I'm done with that, it's sending Guy my completed non-subscriber BYONDscape article (which requires my website as reference ;-)), then straight onto Battle for Solaris until it reaches alpha testing (which would be my first public test of any game since Hunter, remarkably).
Jun 22 2002, 2:04 am
In response to Spuzzum
Thats what I meant @.@ psudocode ^^ Gomen, Im not an idiot enough to want to write code on paper, with no debugging tools, and then type it into the puter again, with all the original error-prone logic streams, syntax errors, unknown commands, and then add in bad spelling >:P

My main point was if you do manage to get yourself into a mind-set where you write code on the fly, and modify it as you go along, you wind up with a huge mess. You solve one bug, only to have that fix make 4 more ^^ It doesnt happen much on smaller projects, but I ran into a few projects in my VB class that did that @.@ Sometimes its easier just to scrap the entire project and use the knowledge you do have to make it shorter, faster, and more effective @.@

Annnnyways, Im getting a little OT here so Ill shut up ^^

El
Jun 22 2002, 6:36 am
In response to Deadron
Often we make plans for a game months ahead of time, and it sits on a list of potential games. We're not quite as bad as Spuzzum or Lexy, but we are starting to get a good-sized list. However, in general, once we start into a game, we keep going until we finish it.

You mean you're not quite as good at this as Spuzzum or Lexy.

Anyways, I'm now observing strict "attention span protection protocols"... now that I'm working on HRH (and have been for a month, thank you) I never open up DM directly, as seeing a blank slate before me encourages me to create a new *.dme... instead, I open up the HRH project itself. I never open up BYOND at all within an hour of reading something or watching something that doesn't relate to the project... two hours or more, if it's something really interesting like the Spy vs. Spy Casebook I got for my birthday.
Jun 22 2002, 6:56 am
Despite my general sloppiness and lack of planning, somehow or another I got into the habit of using basic design docs quite frequently. My main use for them is as a means for assessing how feasible, motivationally speaking, a project is; if I can't hammer out a rough dozen or so brief paragraphs on various aspects of the games and get some example statistics written out, the project dies right there. Though I'm the sort of person that likes to write out extensive statistics for just about anything that could be assigned statistics, typically these are the least important parts of my design docs, mostly because they end up being the sorts of statistics that look good on (virtual) paper rather than statistics that have any grounding in anything actually relating to the game.
Jun 22 2002, 9:25 am
In response to Leftley
I've done lots of decent design documentation on several idea I want to try - both little and small. Being organized and giving as much detail as possible helps in the long run... But now that I've been doing the digitalBYOND site maintaining, I find I have no more time left to learn DM! Waaa!!! And it's all Lexy's fault! Had she not been so diligent in *her* coding habits, I would not have put up a forum for her, and I would not be baby-sitting 30 news users to the site... Waaa!!! Opps... getting off-topic here... what was I saying? oh, yeah:

Paper is good for fleshing out the ideas and features of a game. I tend to have a concept sheet, a feature sheet,(and a map sheet, and character sheet for games) that covers the bits needed for the program I want to build. Keeps things a little organized...