Game Design & Documentation
4 posts
• Page 1 of 1
01 Mar 2017 16:22
Hey guys was just wondering. Do you guys write design documentation before you start writing a game? OR do you guys just get a general idea and then just brain storm as you are creating? It would seem it would be better to plan things out at least the Systems so you are not just randomly coding and figure out the way you are doing it is not good. How did you guys tackle games when it was just the two of you. As I am a programmer and I am currently looking for an Artist and more then likely it will just be the two of us. (We can make it we Try...) LOL. If you do document your games and chance on releasing an version of a Design Document?
-
- Posts: 1
02 Mar 2017 09:14
Far as everyone knows, they make it up as they go along... much like the rest of their lives. XD How else would you explain their random eclecticism?
-
- Posts: 939
- Location: #1 Australian Fan
03 Mar 2017 20:46
We go on brainstorming, iteration, prototyping, and consensus, all tied together by the "good enough" principle.
Typically, Sam and Seth (and now Tiffa) first sit down and brainstorm the loops, core mechanics, core interactions, and background lore for a new portion of the game. Typically this is a 0.5-2hr discussion, with a lot of whiteboarding. Then everyone gets to work trying stuff out through rapid prototyping. If the prototypes feel good, iteration begins.
We have no design documents, though we probably have pictures of the whiteboards after each design discussion.
Typically, Sam and Seth (and now Tiffa) first sit down and brainstorm the loops, core mechanics, core interactions, and background lore for a new portion of the game. Typically this is a 0.5-2hr discussion, with a lot of whiteboarding. Then everyone gets to work trying stuff out through rapid prototyping. If the prototypes feel good, iteration begins.
We have no design documents, though we probably have pictures of the whiteboards after each design discussion.
-
- Posts: 1722
- Location: Dallas, TX USA
14 Mar 2017 19:58
Doobie Doobie, Doobie Doobie, Doobie Doobie! *GOT anthem* ;)
My response might lack credibility as I have never released a game, but I have been using Game Maker for a while and thought I'd share what I've done in my recent projects.
I start with a prototype and make sure the core mechanic is fun to play. In my current project, this basically meant having a bunch of dummy sprites throwing axes at each other. I fine tuned the controls + movement/combat mechanics until it felt right.
Then everything is built on as I go along - but in a structured process. A lot of my previous attempts failed because I hardcoded stuff or the code became impossible to maintain.
All the content of my project is stored in a single Excel spreadsheet. Any asset I add to the game (e.g. monsters, weapons, hero classes etc) I think of as a table first; I have a column for each parameter linked to that asset, and rows to store the actual content. This forces me to think of the asset structure before I even start coding it.
I put the framework in place first, then worry about the content itself afterwards (i.e. adding new weapons, monsters etc). This actually makes it easy to add content quickly once the structure is in place and all the code is written.
This topic is actually something I wanted to cover for a while on my dev blog, so I have put an entry there about it. If the method I describe here interests you, I'd much appreciate if you could take a peek at my last post. I am currently looking for feedback on my website so any thoughts are welcome!
http://hodgepodge-games.com/scalability ... n-scroller
My response might lack credibility as I have never released a game, but I have been using Game Maker for a while and thought I'd share what I've done in my recent projects.
I start with a prototype and make sure the core mechanic is fun to play. In my current project, this basically meant having a bunch of dummy sprites throwing axes at each other. I fine tuned the controls + movement/combat mechanics until it felt right.
Then everything is built on as I go along - but in a structured process. A lot of my previous attempts failed because I hardcoded stuff or the code became impossible to maintain.
All the content of my project is stored in a single Excel spreadsheet. Any asset I add to the game (e.g. monsters, weapons, hero classes etc) I think of as a table first; I have a column for each parameter linked to that asset, and rows to store the actual content. This forces me to think of the asset structure before I even start coding it.
I put the framework in place first, then worry about the content itself afterwards (i.e. adding new weapons, monsters etc). This actually makes it easy to add content quickly once the structure is in place and all the code is written.
This topic is actually something I wanted to cover for a while on my dev blog, so I have put an entry there about it. If the method I describe here interests you, I'd much appreciate if you could take a peek at my last post. I am currently looking for feedback on my website so any thoughts are welcome!
http://hodgepodge-games.com/scalability ... n-scroller
-
- Posts: 16
- Location: London, UK
4 posts
• Page 1 of 1
Who is online
Users browsing this forum: No registered users and 2 guests