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.

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.

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.

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.

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.

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 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.

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).

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