Advice on designs for personal projects.
Author
I usually have a hard time finishing or staying focused on my personal projects. I think one of the reasons i have this problem is the lack of me doing little if any kind of design for my projects.
So i'd like some advice on doing some game design for my own use. Are there any guidelines on what i should design? How detailed it should be? What i'm really looking for is some kind of basic outline or template to get me started. I'd like to get to a point that i can start my implementation and refer back to a design document when i am unsure.
I know i could just start writing but i wondered if there was any advice on structure or organisation that would help me get the most out of my design. Any help much appreciated, thanks.
The standard sort of structure for an independent or commercial game is:
1. Concept Document
2. Proposal
3. Design Document
The concept document details the bare essentials such as genre, engine, platform, etcetera, in addition to providing a description, most often in the second person, of the player's experience playing the game. The proposal is, in a way, an expanded concept document. It contains market research and technical evaluations in addition to a revised and expanded concept. The design document details EVERYTHING. Every PART of everything. It takes a lot of work to write one of those bastards for a decent sized project.
I would encourage you to write a concept document and a design document. The concept will allow you to hammer out what you want your mod/game to play like, and you can show it to others to see what the think. The design document will give you a complete layout of your game, and a complete list of tasks to undertake. You may omit the technical evaluations in most cases, considering you're unlikely to be developing a next-generation engine. If you intend to release your project commercially or are seeking a lot of attention you may wish to write the proposal also. Most especially you could undertake market research.
As for templates, there are quite a number of documents and templates available in the articles section of this site or GamaSutra which can provide advice on writing these documents.
1. Concept Document
2. Proposal
3. Design Document
The concept document details the bare essentials such as genre, engine, platform, etcetera, in addition to providing a description, most often in the second person, of the player's experience playing the game. The proposal is, in a way, an expanded concept document. It contains market research and technical evaluations in addition to a revised and expanded concept. The design document details EVERYTHING. Every PART of everything. It takes a lot of work to write one of those bastards for a decent sized project.
I would encourage you to write a concept document and a design document. The concept will allow you to hammer out what you want your mod/game to play like, and you can show it to others to see what the think. The design document will give you a complete layout of your game, and a complete list of tasks to undertake. You may omit the technical evaluations in most cases, considering you're unlikely to be developing a next-generation engine. If you intend to release your project commercially or are seeking a lot of attention you may wish to write the proposal also. Most especially you could undertake market research.
As for templates, there are quite a number of documents and templates available in the articles section of this site or GamaSutra which can provide advice on writing these documents.
Tom Sloper's website, Sloperama.com, has several great references for discussing design docs. I would highly recommend the book Game Design Complete by Patrick O'Luanaigh, because it is fantastic. In the back of the book he presents a pretty nice game design document layout.
At work we tend to work in the order of:
Pitch Document
Expectations Document (when working with bigger publishers on bigger contracts)
Game Design Overview
Game Design Document
Since you are working on this title yourself, you can go straight to the game design overview. The GDO should encompass what the game is within about 6 pages. You should be able to show the GDO to just about anyone (and I highly recommend you do to get feedback), and they will know what it is that you are making. Once you have your GDO, and know that everything in it is exactly what you want, then you proceed forward with the GDD. The GDD really is composed of all of the information you'll need to reference to make your game.
At work we tend to work in the order of:
Pitch Document
Expectations Document (when working with bigger publishers on bigger contracts)
Game Design Overview
Game Design Document
Since you are working on this title yourself, you can go straight to the game design overview. The GDO should encompass what the game is within about 6 pages. You should be able to show the GDO to just about anyone (and I highly recommend you do to get feedback), and they will know what it is that you are making. Once you have your GDO, and know that everything in it is exactly what you want, then you proceed forward with the GDD. The GDD really is composed of all of the information you'll need to reference to make your game.
Quote:Original post by JimmyDeemo
I usually have a hard time finishing or staying focused on my personal projects. I think one of the reasons i have this problem is the lack of me doing little if any kind of design for my projects.
Well, then, now you can find out if that's what it is. Writing a game design is a project in and of itself. IOW, you're taking on two projects:
1. Writing a design;
2. Executing it.
Go ahead and give it a try. But your biggest hurdle is your personal one - that of expecting instant gratification. That expectation is a deal-breaker in the game biz.
Author
Thanks to all who replied, and to Mr.Sloper.
Could you elaborate more on this please. What I’m trying to do is improve, I'm not trying to find an instant solution to my problem. I'm trying to identify where I’m at fault and address it, sometimes this proves quite difficult. I already know what kind of hill I need to climb to get where i want to be, and I appreciate its a big one. I've got not visions that I can become better overnight. My thinking is that I could aid my programming by improving my design ability.
Are you suggesting the i stop thinking about doing both and just do one? Perhaps execute other peoples designs? I'm finding your reply quite cryptic, or was that the point?
Quote:Original post by Tom Sloper
But your biggest hurdle is your personal one - that of expecting instant gratification. That expectation is a deal-breaker in the game biz.
Could you elaborate more on this please. What I’m trying to do is improve, I'm not trying to find an instant solution to my problem. I'm trying to identify where I’m at fault and address it, sometimes this proves quite difficult. I already know what kind of hill I need to climb to get where i want to be, and I appreciate its a big one. I've got not visions that I can become better overnight. My thinking is that I could aid my programming by improving my design ability.
Are you suggesting the i stop thinking about doing both and just do one? Perhaps execute other peoples designs? I'm finding your reply quite cryptic, or was that the point?
Quote:Original post by JimmyDeemoQuote:Original post by Tom Sloper
But your biggest hurdle is your personal one - that of expecting instant gratification.
Could you elaborate more on this please.
I'm saying take it a little at a time. Yes, by all means go ahead and write a GDD. If you can finish that, great. Then maybe you were right that the lack of a clear plan was your problem in those previous cases of not finishing a project.
All of us have unfinished projects. But not having any finished projects is a problem.
I recognize that I'm still sounding cryptic. That's because I'm dealing with general concepts. All I know about you is what you told us: "I usually have a hard time finishing or staying focused on my personal projects." To me, that usually indicates someone who desires instant gratification and doesn't have the patience to finish. But it can also mean that you start by biting off more than you can chew. I don't assume that your explanation is the right one. Trying to write a GDD, and trying to execute from that, should be a revelation - but it requires objectivity.
Do a few story boards of how you want game play to work. Use a spiral development model get a very small bit done then test it. Then make it into something a little bigger. Repeat until done. Try to be organized. Try to stay focused.
Author
Quote:Original post by Tom Sloper
All of us have unfinished projects. But not having any finished projects is a problem.
This kind of highlights my problem. I get involved in a project but i can get caught up on something i don't know about. Let’s say i'm implementing something using technique x. Rather than doing it, furthering the project and coming back to review it later. I get caught up on knowing everything about it before i utilize it, which usually involved technique y and i go through the same project.
Thinking about your comments does make me think that maybe i'm picking things that are to complicated. Perhaps i should try implementing existing designs before doing my own.
I have got a couple pieces of advice for you. I too have been in that same boat, and I have ditched around 6 projects
1) if you can't explain it on a forum, it probably won't get finished.
2) Make your game something you can fully do, don't leave yourself to learning new stuff to finish the game.
3)Start small. My technique is to start with a box and a ball. The ball moves around in the box. Then I add a jump, items to collect, gun to shoot with...etc.
Just start with the very minimum you need to make your game function. Then expand with details and features to make it into the game you desire.
Anyway, hope that my advice may help you keep your project going. Good luck!
An easy template is:
+ Game name
+ Game bio ( what will you do in this game?)
+ List the main core features or actions you will be doing
-----for example, if my game involves gun slinging action, I would write:
FEATURE 1 : shoot bullets from gun /reload/(limited ammo)
After this you describe how you think you would go about making this feature:
FEATURE 1 : need Gun, Bullet, Gun sound
* variable keeps track of ammo with a declining value. Displays on screen.
* After creation, bullet moves at a speed horizontal with gun barrel.
* when clip count is at zero, wait a designated time, then reset clip count.
This will make it so all you have to do is plug code in to represent what you wrote, which makes it fast, easier, and prevents the "blank screen syndrome" when you start trying to write code.
1) if you can't explain it on a forum, it probably won't get finished.
2) Make your game something you can fully do, don't leave yourself to learning new stuff to finish the game.
3)Start small. My technique is to start with a box and a ball. The ball moves around in the box. Then I add a jump, items to collect, gun to shoot with...etc.
Just start with the very minimum you need to make your game function. Then expand with details and features to make it into the game you desire.
Anyway, hope that my advice may help you keep your project going. Good luck!
An easy template is:
+ Game name
+ Game bio ( what will you do in this game?)
+ List the main core features or actions you will be doing
-----for example, if my game involves gun slinging action, I would write:
FEATURE 1 : shoot bullets from gun /reload/(limited ammo)
After this you describe how you think you would go about making this feature:
FEATURE 1 : need Gun, Bullet, Gun sound
* variable keeps track of ammo with a declining value. Displays on screen.
* After creation, bullet moves at a speed horizontal with gun barrel.
* when clip count is at zero, wait a designated time, then reset clip count.
This will make it so all you have to do is plug code in to represent what you wrote, which makes it fast, easier, and prevents the "blank screen syndrome" when you start trying to write code.
K.I.S.S. (Keep it simple, stupid) is a great way to get going. If you don't know your limitations yet, you need to start small.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
