How do you all go about it? I'm more of a visuals person with jotted down, scattered notes: unorganized. I feel that helps with eating away at my motivation when doing artwork and designing a game. I'm almost certain that if I had better organizational skills, things would get done much faster than they're currently going.
Any tips?
**I've also never been too keen on completely writing out a design document, is there an simplistic method to writing one out?
ID:809381
 Jun 10 2012, 8:02 pm (Edited on Jun 10 2012, 8:10 pm)
|
|
|
Jun 10 2012, 10:17 pm
|
|
Boxcar
 |
I love writing things down, getting them out on paper. I have a portion of my wall that is now covered in check lists with things I have to do to finish my project, along with design documents and maps I hand drew. I find that organizing all my ideas about my project re-motivate me to work on it.
|
I have a whiteboard for this sort of thing. I find writing down, as was said above, key concepts really helps when designing gameplay.
When you actually get on to implementing it, work out what the 'base' things are, the bits that need to be done before anything else can be done, and work up from there a layer a time until you have the order things need doing in. | |
BYOND users focus on design because they think that's what professionals would do, but professionals would realize there's very little need for design here. Design is an activity that's done to minimize risk. These benefits are almost completely lost on BYOND games because these games are small projects with very little risk. Risk can mean many things:
Risk can mean "Is the game technically possible?". This doesn't apply here because you're using BYOND. If you want to make a multiplayer RPG, you know that's possible. It's not like it's 2004 and you're trying to invent some Wii-like motion gaming controller and you're not sure if the technology will work. You know what BYOND is capable of so you know that you're game is feasible without doing any design work. Risk can also mean "Is this the right way to do things?". This doesn't apply here. If you were setting out to make a game you might first research different game development platforms. If you've decided that you want to make a game using BYOND, you get to skip that design work. Risk can also mean "What's the cost if something goes wrong?". This applies here but the cost is very low. If a huge commercial project runs into a problem and the design needs to change, this could cost hundreds of thousands of dollars. Hobby games are simple projects. If you run into a problem you might have to spend 20-30 minutes re-coding something. Risk can also mean "Will this game be fun?". This absolutely applies here but the best way to answer that question isn't to write a design document. Build a prototype of the game, play it, and see if it's fun. The only time I write out actual design notes for a game is when the idea is so rough that I couldn't actually build it yet. For example, I might have an idea to make a game where players win battles by pushing their enemies off the edges of the board. That's a very rough idea so there's not much I could implement. Is it real time or turn-based? How do you push enemies? Writing down some notes preserves the original idea and might help to figure out answers to those other questions. But, once those questions are answered, the design stops and the implementation starts. Once I have a DM project going I usually have a code file that just contains notes about what things I'd like to add next. It's just a bulleted list and it's not really design (I'm not saying how I'll add these things), just that these are things I need to work on. If you need more than one page to describe what you want to build, you need to stop writing and start building. If you want to keep detailed notes about something, keep notes about what you've already built, not what you plan to someday build. | |
I think it's much easier for coders to not need a design document, over artists and designers. I haven't managed to learn a lick of code since I joined BYOND, which is my own personal negligence that I regret. Most of the code developers that are asked to help, require a design document. Maybe it's just the people I ask, but I feel I require more creativity and flexibility than a set-and-stone document.
I do however, after reading all of this, have a rough idea of how I'm going to write out this design document. | |
You might need to be more detailed when describing what you want to be created to someone else, but often these details are inconsequential. For example, if you want someone to implement a menu with four options, you have to tell them what order the options should be listed in. This is a very low-level detail - if you described every aspect of the game in that amount of detail it'd take forever to write a design document. However, this detail isn't important. It'll only take three seconds to change the order later on, so writing a lengthy description to provide every detail won't save you any time.
| |
Forum_account wrote:
You might need to be more detailed when describing what you want to be created to someone else, but often these details are inconsequential. For example, if you want someone to implement a menu with four options, you have to tell them what order the options should be listed in. This is a very low-level detail - if you described every aspect of the game in that amount of detail it'd take forever to write a design document. However, this detail isn't important. It'll only take three seconds to change the order later on, so writing a lengthy description to provide every detail won't save you any time. Absolutely, which is what I feel like I'm being asked as soon as I'm told to "write a design doc.", it drives me crazy and motivation is lost almost instantly. S'why I hide in my cave, do recreational substances, and do my artwork. But back on topic, I appreciate the help, greatly. | |
I pretty much just think as I go along. For instance, if I'm making a shooter, I just draw some sprites and a map, implement everything you typically find in a shooter, and then add unique aspects that make my game different from every other shooter. I may say to myself "This would be more fun if shotguns knocked back the enemies and did extra damage if they hit a wall" or something, and then add that to the game. I never write anything down. I just make a foundation for the game and brainstorm the rest. I attempted to write things down and "be organized" but it doesn't help me at all for some reason.
| |
EmpirezTeam wrote:
I pretty much just think as I go along. For instance, if I'm making a shooter, I just draw some sprites and a map, implement everything you typically find in a shooter, and then add unique aspects that make my game different from every other shooter. I may say to myself "This would be more fun if shotguns knocked back the enemies and did extra damage if they hit a wall" or something, and then add that to the game. I never write anything down. I just make a foundation for the game and brainstorm the rest. I attempted to write things down and "be organized" but it doesn't help me at all for some reason. Exactly, I mean, I write out Notepad documents about such and such, but I can't just put them all into one document all at once: I didn't like essays in-school, why would I now? | |
If you're bringing in programmers, they probably ask for a design document so they know what your game is about. It's in your head, not theirs. They need to know what your ideas are so they can make them happen without having to email you or message you a million times to get an idea of what's up. They way they can just do the work and finish it.
| |
Yusuke13 wrote:
If you're bringing in programmers, they probably ask for a design document so they know what your game is about. It's in your head, not theirs. They need to know what your ideas are so they can make them happen without having to email you or message you a million times to get an idea of what's up. They way they can just do the work and finish it. Might've had the wrong idea of a Game Design Document, but the ones I've seen have been 20+ pages long, outlining EVERY SINGLE DETAIL. That's not appealing to me, whatsoever lol. | |
It's not always the best to get every single detail, like how many rounds there are in each gun but general statments work well. For example I might say in the design for Shotguns that they are high power, low ammunition. Just an example but definitely getting it to at least that point where you're looking at each part individually and working out how it all fits together.
I like to just get a notepad myself, virtual or real. Then I jot down all my ideas, no matter how crazy they may seem. After I throw most of it out and some of it sticks. It's that stuff I use to expand upon and hopefully mould into a game. Don't get me wrong, there are lots of different ways to design games and it's really what works best for you. Definitely get it mapped out to the point that you have a general reference guide for anyone making your game. (I think.) - P.S Almost forgot to mention, if you're stuck on designing a game then look up other game developers and learn how they design games. There are plenty of Youtube videos that have interviews with some of the greatest designers out there, ranging from John Romero(Doom 2, 1994) to head Maxis staff (The Sims, 20xx). I find a lot of inspiration this way. | |
I'm naturally an organizer (even though I'm not naturally organized). On my latest project (an RTS/RPG), I have several documents:
Functionality, since the game required a lot of custom controls. UI layout (which I drew up while watching a movie or something) A chart of class/level development that I'm using as a starting framework for unit balance. It's not Starcraft, but I had an idea for how things should balance, so I wrote it down. Most of my codefiles have a short To-Do at the top, which usually includes "Clean up section X, document section Y, abstract section Z" etc. Some of them include a section of reserved keywords for Topics. This has helped me tremendously in one particular way- whenever I hit to that "Ugh, I don't want to work on this, nothing is going right" I can look at a codefile and see a clear, material goal of what I need to accomplish. If you are set on writing out designs, the best way I've discovered is to start with a broad statement of what you want to accomplish and gradually break it down into codeable chunks. | |
I'm thinking of a Q&A format for myself, which I will then break-down into more detailed portions. I have a method on how I want to design my ultimate game and I just need to get home to put these methods into function.
Thank you all for your helpful tips. I wish you all luck on your gaming ventures. | |
Yusuke13 wrote:
If you're bringing in programmers, they probably ask for a design document so they know what your game is about. It's in your head, not theirs. They need to know what your ideas are so they can make them happen without having to email you or message you a million times to get an idea of what's up. They way they can just do the work and finish it. I tend to do the opposite of this, in commercial settings (and the few times I did it on BYOND). The design document is usually the first thing to go in the bin after a polite reading, then a chat with the guy setting me the work is in order to work out if what he wrote is at all what he meant. Usually I find the document doesn't describe what he meant, even with very experienced engineers, just because of the problem Forum_Account alludes to: Big design documents usually describe process/detail, not intention. People typically describe how they expect stuff to work in their documents (good), but in terms of their understanding of the code, implementation ideas, their own capability etc (bad). So much so usually, that you can't work out the intention. It's intention that you want to document, if there is indeed anything to document at all with your game idea up front, that can't just be prototyped. | |
Red Hall Dev wrote:
For example I might say in the design for Shotguns that they are high power, low ammunition. You don't need to write that down. It should be obvious that shotguns are high power/low ammo and that should also be something that's easy to change (ex: change shotgun/power = 10 to shotgun/power = 20). I realize it was just an example, but when you look closely at everything you might put in a design document you'll realize most of it doesn't need to be written down. You design things to avoid problems but there's no problem to avoid here. If you jump right in and write the code for shotguns and give them the wrong power, you can easily change it later. If anything, it's better to write code with the expectation that certain things will change. Just because you write in a design document that shotguns are high power, that doesn't mean that's how it should be. After playing the game for a while you might discover that your maps force players into a lot of close-quarters combat and shotguns are too effective so you want to lower their power. You couldn't have anticipated this back when you were designing the game. For making a BYOND game, it's a more useful skill to deal with problems as they come up than to try to anticipate them all ahead of time (especially for a community of mostly novice programmers and game developers who surely don't know what problems they might run into). | |
Forum_account wrote:
write code with the expectation that certain things will change. This is the Golden Rule™ for good design. If you have a rigid code-base that can only do one thing, it won't be nearly as useful. | |
Boxcar wrote:
I love writing things down, getting them out on paper. I have a portion of my wall that is now covered in check lists with things I have to do to finish my project, along with design documents and maps I hand drew. I find that organizing all my ideas about my project re-motivate me to work on it. This x2 | |