This post is more a "speaking out loud" post.

Basically, i've been a hobby game programmer for a long time (well about 10 years - i'm now 30 years old) and i'm always thinking about new ideas. Recently, my wife must've noticed that i'm always talking about ideas and never doing. So she just urged me to actually do it. (Normally i write ideas / little snippets in excercise books all around the house).

So i attempted to start a design document for my games but my mind starts drifiting about more and more ideas and i just cant get the game design doc written. I dont know what it is but i think its because the design document is not doing anything.

So anyway, what i attempted to do in my latest game example is to actually start on the database and use that as a design template. So using my current game as an example:

So my new game is set in space so my first line of thought was how do i define the game world? well it makes sense that the "regions" of space would be broken up into Solar Systems so i created my first table called "solar_system". So what goes into a solar system? Well you need planets to make up a solar system so i made a table called "planet". Now a planet can only exist in 1 solar system so i added a "solar_system_id" field into the planets table.

What else can be in the solar system? well i'm going to want to have space stations so i made a "station" table and because a station could exist on a planet or in space, i made a station_solar_system_link table and a planet_station_link_table. Inside the station, i'm going to want to have "stores" setup so goods can be bought and sold so i make a "stores" table and link it to stations with the "station_id" field. I'm going to want to have some form of storage system so i make an "inventory" table and a store can have storage space and a ship can have storage space so i link the "inventory" tables to the "store" table and another link to the "ship" table etc...

Basically, i just keep flowing through and making the database structure to handle the ideas that i have. Its amazing how well this is working for me as i still have to plan what features i want and how i want it to work. The most detailed one i have gone through so far is the Mission system. The tables involved are:

Mission - This stores the general info about the particular mission
Mission_condition - this is where you can create a whole bunch of conditions that need to be met to enable the mission
Mission_condition_type - Stores all the types of conditions you can have so i know how to interpret the values in the mission_condition table
Mission_Mission_Condition_link - Because i want the ability to have multiple conditions for a mission and conditions can be re-used for multiple missions, this table will enable me to link any number of conditions to the mission
Mission_reward - this is where you create the various rewards that can be received for completing a mission
Mission_Reward_type - Stores the type of reward so the reward values are handled correctly i.e. Qty of a particular resource, qty of an actual item, qty of rep etc..
mission_mission_reward_link - Enables you to link multiple rewards to the mission
Mission_task - Stores the actually tasks that need to be done for the mission - built to handle any type of task i can come up with
Mission_task_type - Stores the type of task so the values are handled correctly - enables me to offer different mission tasks (eliminate enemy, deliver item, earn particular rep etc..)
Mission_mission_task_link - Enables mutliple tasks to be assigned to a mission

So you can see that by designing the database tables, i have actually started the mission design process and i have designed the tables in such a way that when i eventually start designing the various missions i want to offer, the database structure is not going to be holding it back so its going to be very easy for me to actually code the missions.

The reason this is working soo well for me is the fact that i am actually doing something that is going to be used in my programming so its not "wasted" time. (i fully understand the advantages of a design document and its obviously not wasted, but for me i am just struggling to put time into the doc when i could just be making the database).

I just wanted to share this technique incase there are others out there having a similar issue to myself. I'm certain there is negatives to this way and i'm not claiming that this is an awesome way or the best way to design games. But if you are having trouble starting your game or find writing the design document to be a waste of time, try designing the database first and see if it works for you.

The basic premise i am keeping in the back of my head while making the database is i dont want an ability or feature to be unable to be done because of my database structure. So i'm keeping the database in a very normalized state and making sure that i'm giving it the flexibility so when i actually go to add features into the game, that the database structure supports it.

Just an FYI

It sounds like you love databases! That is neat. Since your primary focus is databases, you must make a game that is database-like or db-friendly. Most games probably focus on the graphics and fast gameplay loop, which is a different skill, programming and progmath heavy, along with understanding computers good and also games and fun and action. A DB reminds me of stores and businesses and the warcraft auction hall, and also of microsoft visual web developer, which makes websites that connect to the dbs. Dbs are also very multi-user friendly, so a web site with free ms web express hosted for like $10 per month might work good....it must be non-action, or you will focus elsewhere and lose all your time...so perhaps make an auction site where users get an allowance of virtual goods and cash every day, and then can trade, set up stores, auction, market, advertise, lots of virtual item stuff based loosely on the warcraft auction hall...maybe quests, single player mode, ai auctioneers, and more. If you have a specific knowledge about dbs, for example you work in a computer repair store, you might make a db game about retailing items from wholesale, where you click around and buy from diff wholesalers and market and talk to virtual customers with dialog trees to sell stocked items, order new ones, and fix computers, with customers paying the store and the virtual player might start as employee, get promoted to manager, and eventually run the store or a bunch of them, all with new unlocking options, possibly with dual-player leveling systems as customers and employees....or maybe make the players all at least managers and allow the use of virtual employees with budgeting and other stuff too....also teamwork is good, database skills are kind of rare, so perhaps teaming up with a web site maker and seeing what they suggest, or if they need suggestions, or even if they have paying customers, might be good too.

LOL, I think your wife by "actually do it" meant that you should just select one random idea you have and go for it instead of making a database of your ideas, which is basicly another form of "talking about ideas and never doing". Ask her

Logical modelling is always good idea in any development, which is what you’ve been doing so far. And databases are a great way to store your game data. Especially as there various redistributable databases available these days, and there are a number of frameworks like nhibernate that let you serialize to and from databases. I’ve also been looking at using python as scripting language to handle the runtime behaviour of my various game entities and storing that python scripts as part of the game data in the db.



So, I have a game entity Rusty Revolver and all the data and scripts for its behaviour are stored in a table in the db, and then I use instanced versions of that entity in game.



The only problem I’ve got with your approach is that the logical modelling should follow from specific design requirements. So first think of the game play activities and ideally prototype them to see if they work and then derive your logical models. That doesn’t mean you should fully spec out everything first. Far from it in fact but you should ideally have your high level gameplay activities and then drill down and expand them out into the smallest logical activity to model.



So you have Missions

Then you might expand that into planet side and in space missions.

Then expanded that out into different types of space missions.

On in on until it doesn’t make sense to break it down into a smaller functional piece and then model that.



You’ll still find no matter what approach you take that you’ll have extensive refractoring to do once you try and build specific implementations as your realize existing bits no longer make sense.

i think its because the design document is not doing anything.

Writing a GDD is not "not doing anything" -- it's "planning."
Planning is important in that it prevents time wastage, cul-de-sacs, and work do-overs.

"Plans are only good intentions unless they immediately degenerate into hard work." ~ Peter F. Drucker

I've been basically doing the same thing you have on and off for the past 5 years now. I have notebooks full of various ideas etc, and actually started coding demo projects of various parts of the game. For example I had a working standalone program that demoed the item creation process before I had the individual items even thought out and I still don't have a written "document" on how it works.I have about 52 database tables created in excel, some of which are still blank templates, others actually have entries that I've created while creating the mini demo programs. 90% of It is still in my head.

I don't even have a name for it yet.

I've recently started the Design Document for the "game", I hesitate to call it a game since I'm not sure I'll actually build one as I may just push towards packaging parts of it up as Middleware. Then I stopped. The GDD is not something that I can or should write at this time as there are many elements of it that don't exist yet (story/plot/genre/graphics/network etc). Instead I started writing the "Technical Document/Bible".

Yeah i understand that the GDD is the "planning" but that just doesnt work for me - i think it sorta bores me. Technically, by me making my database i am also planning my game but also actually making it at the same time. So i am "designing" my game but i'm just using my database to prove i can do what i design without even coding it.

Because of the way i created my database (i follow a very specific design/naming convention) i have been able to make my "worldbuilder" tools quite easily. I'm really seeing the benifit of having a good database structure and design under me. Basically my tools are actually built by the tools themselves. So i dont have to keep changing the code, i just use my tool to change stuff in the database that creates my various worldbuilder tools.

I would post more specifics / screenshots but its still in very early stages - all i know is i'm having alot more fun and making alot more progress now that i'm focussing on making the database for my games rather then just writing down the ideas/features that i want.

So yeah, when i come up with new features or things i want to add to the game, rather then just write down the feature in a document, i make the table structure to support it so that its easier for me to implement when i eventually get around to coding it. The funny thing was, i then made my "feature list" from the database tables as a sort of "design doc" that i sent to a few friends. It was really easy to make this document using the tables because all i needed to do was explain what the tables purpose is which effectively showed the design ideas.

My current project is more what i call training. The scope is massive, the goals are huge and the idea is to learn from the positives and negatives so that my next project is actually better.

p.s. I am good with Databases / Queries if people need any help with that type of stuff

Yeah i understand that the GDD is the "planning" but that just doesnt work for me - i think it sorta bores me. Technically, by me making my database i am also planning my game but also actually making it at the same time. So i am "designing" my game but i'm just using my database to prove i can do what i design without even coding it.

You aren't designing your game, you are implementing your game on the fly from a mental design you already have. The reason design documents are good is because it puts (or should put) all your cards on the table before you implement anything. Doing what you are doing works fine for a while, especially when you start, but what happens when you decide that you have planets without solar systems or missions that don't have solar systems, planets, or space stations? Do you rewrite your database? What happens when database reconfiguring breaks your code? etc. etc.

Your "design" is now limited to the scope of your implementation, when, in fact, your implementation should be working to fill the scope of your design. On small single person things it's not that huge an issue as you know the entirety of the implementation and existing design, but as team size grows other people might implement something a certain way sans design that makes other key parts of your design impossible.

I think you should focus on the idea you most prefer, whether it be the space game or not, and just write a GDD for it.
You may be getting bored because you're swaying from game to game and saying, "Maybe I'll design this one instead" once you're only 5% of the way through designing one that you've suddenly lost interest in.
My opinion is find the game idea you like the most and start designing it. If you really feel for the game, you'll want to design it more and make it even better.
And designing a demo of the basic features of the game (for example, combat, flight, trade, whatever is really important in the game) may also help you get motivated and really want to see your game developed.

EDIT:
Also, writing a GDD will slowly unravel more and more of the game in your mind, which will probably end up making you face some decisions such as swapping out certain aspects, changing things, or adding new things.
And you'll have it all in writing so you can't forget things or deal with the stress of holding all of your genius in your head at all times.
Just don't drop your computer in a pool or anything...

you seriously need to write a GDD, its like the most important aspect of making games. im not all that knowledgeable in the databasing field but i do know that in the games industry nothing is done without a GDD. it's like... as games are another medium (the best) of storytelling you are essentially writing a book or film (i know the writing processes are entirely different) the game play mechanics, missions, items ect need to be related to the story and to do all of this you need to do loads and loads and loads and loads of planning and research, and an easy way to do all of these things is to write a GDD.

its kind of like an overview of everything thats going to happen in game, then if halfway through development you need to change a few elements of it, you can just get your GDD out and make the changes, instead of having to remember everything that one problem hinders. you've got some really cool ideas, and its sounds like your databasing skills are top notch, i just dont want you to watch another project wasted, and it might get your wife off your back

Avi