Design Best way to design a game

R

Richard Mountain

Guest
So i'm pretty new to the game developing scene and I have a question about designing games in respect to features and functionality, as I don't think just jumping straight into game maker and bolting features on as and when I think of them.

Now I know the first thing I should do is write down everything about the game, but I wanted to know if there was a better way of doing it, or software which can help organise the game design rather than just a bunch of text in a word document or spreadsheet.

Any help, suggestions or even own experiences would be a great help.
 

Yal

šŸ§ *penguin noises*
GMC Elder
Xmind is a really good mindmapping tool I can recommend (it's free too!), but I mostly just write stuff in Google Docs... long documents/GDDs with tons of ideas get a lot easier to read in a traditional document than in a mindmap. Google Docs are also awesome for collab projects, since you not only can share them really easily, you can also edit the same document together in real time - it's awesome for brainstorming.

When you need to design something visually, such as levels or characters, I recommend pen and paper... it's a lot faster to doodle IRL than digitally, unless you have tablets and stuff you've also mastered using them. I also find IRL documents easier on the eyes than digital ones.
 

The M

Member
Personally I write a few documents, depending on the game. Start with a general design document where you list key features and describe your game's concept, theme, gameplay and some content. The idea is not to write down everything but enough that you feel you know what game you're making. You can expand it later.

Then I'd make a list of tasks to do and select which to work on. I'd say it's best to start with the core gameplay and iterate until it feels good, then you delete everything (or rather, you put your test levels aside) and start making the actual game.

Somewhere you'd probably want to fit a document where you list how the game progress (describe levels and how they are ordered) and one where you write down the game's story and describe the characters involved, etc. depending on what kind of game you make.

Edit: I fully agree with Yal on both Google docs and pen/paper. I find the latter to be especially useful when designing levels because you can overview and move things around better on paper.
 

ShaunJS

Just Another Dev
GMC Elder
Personally, the only time I've ever written a design document was for university work, or while I was employed by Ubisoft. My own projects have never needed something like that (given the primary purpose of such documents is to stabilize, prioritize and plan larger products and also communicate effectively and clearly with a team.) My projects though have generally had a very defined and simple scope. That's me specifically though.

I design by prototype. I build the most key, most interesting, most quickly and easily-built part of the idea and then either discard, or carry on from there.

This is not necessarily the best way to do things, I just find it effective for me as it's easy to get bogged down with documenting ideas when most of them will not survive the first prototype.

Almost all game ideas ever thought of never survive their first contact with reality. Part of growing as a designer is learning to recognize the "bad" earlier and earlier in the process. The best way to do this especially early on is to build as many different things as you can. If you write down "everything about the game" you are overwhelmingly likely to waste time, at very best, reworking the design massively less than days into development and at worst, discovering once you begin coding that the whole idea is unworkable or uninteresting to you after having planned the whole thing in detail.
 
S

Snail Man

Guest
The short answer is that there's no one way that works for everyone. Some people like to plan out every detail, some people like to intentionally avoid planning! Just find what works for you, and that's what you should do.
 
R

Richard Mountain

Guest
Thank you all for the responses, they have been very helpful.
 
M

Morumotto

Guest
The short answer is that there's no one way that works for everyone. Some people like to plan out every detail, some people like to intentionally avoid planning! Just find what works for you, and that's what you should do.
I agree. I take a different approach depending on the project. Sometimes It's fun to wing it. Something I want a connected story with I may make a design document. I find somewhere in between works best for me. I call it "constructively winging it." I basically like to fool around until I have something I think might be interesting. Then, maybe I'll write a small plan with how I'll integrate it into my current project or something. Most of my game dev hard drive is full of just quirky prototypes because of this. (Which is a great resource!)

I think people get hung up a lot on the little details. There isn't a right or wrong way. Some people plan every little detail and it makes them really happy and productive, but I personally think it's too constrictive. Plus a lot of that type of planning can take a very long time, and then you're not doing what a game maker needs to do, which is make games, you're just being a project planner. Just jump in and make something!

My two cents!! <3
 
F

Fodderbot

Guest
Personally, the only time I've ever written a design document was for university work, or while I was employed by Ubisoft. My own projects have never needed something like that (given the primary purpose of such documents is to stabilize, prioritize and plan larger products and also communicate effectively and clearly with a team.) My projects though have generally had a very defined and simple scope. That's me specifically though.

I design by prototype. I build the most key, most interesting, most quickly and easily-built part of the idea and then either discard, or carry on from there.

This is not necessarily the best way to do things, I just find it effective for me as it's easy to get bogged down with documenting ideas when most of them will not survive the first prototype.

Almost all game ideas ever thought of never survive their first contact with reality. Part of growing as a designer is learning to recognize the "bad" earlier and earlier in the process. The best way to do this especially early on is to build as many different things as you can. If you write down "everything about the game" you are overwhelmingly likely to waste time, at very best, reworking the design massively less than days into development and at worst, discovering once you begin coding that the whole idea is unworkable or uninteresting to you after having planned the whole thing in detail.
Places I've worked at have generally been SCRUM houses and while there are some general documents to describe the overall idea, it usually all gets put into a project wiki that the entire team, Design, Art and Engineers work on and expand it as the project grows. When enough information is in the wiki you can better populate your process tasks and tracking documents.

When I'm working on my own projects then I usually have a few word files to fill in as ideas arise, and a spreadsheet with multiple sheets to track tasks, progress, needed bug fixes, and the like.

When working in Gamemaker I like to use "Game Information" section to jot down bugs that I run into on the fly, insipration on coding, art pipeline or engineering ideas, and keep kind of a programming diary as I run into hard bugs, and the ideas I try or want to try as I am trying to track them down. I also note my progress and what I am thingking about when programming and when I stop programming for the day, so if I do have to step away from the project for a week or two, I can update myself on where I left off so when I reboot I can get started faster instead of spending too much time trying to figure out what the heck I was actualy thinking and where the code was headed, and why. I can also use this information to update my external notes and speadsheets later without having to stop the flow of programming. I think that has helped me more then a lot oft hings I've tried.
 
For my game, I just jumped right in. I just add things I think would be cool. It's been working out for me so far. I don't think it's good to write every single thing down and try to plan out your entire game. I think planning too much will actually stifle your creativity and hinder your game's natural growth into something interesting and fun. I say let the game slowly stew in your head, and just go with the flow. Bob Ross would've been a great game designer, I think, haha! Maybe it's no coincidence I'm an artist first and a programmer second! :')
 
S

sparksinfinite

Guest
The need of 'documents' depends on your memory and (team) workflow I guess.
Speaking for me, I cannot remember every idea, every goal and every bug I have to fix (or issue I have to consider). Therefore 'documents' are very helpful to me! Here is what I use:

- simple log file (notepad, date and work, watch the progress)
- simple to do list (notepad, bugs needed to be fixed and next goals)
- a concept/idea document (word, just a collection of many ideas)
- a gamedev journal (a real little book to keep gamedev ideas, tricks and reviews - in general)

Most of these documents are SIMPLE, because I don't want to spent to much time organizing them.
And I don't like expensive Game Design Documents at all, they are okay for university, and maybe for team sharing, but I want to spend my time with the game and not in the documents.

Game Development is a process with a lot of CHANGES, and updating complex documents every time a change happens costs time and power, and this is what your game needs the most.
 
Top