Hi all...

This seems like a busy community. Lots of people burning brain cycles about games. Me too.

So, instead of searching for specific answers to specific questions, I thought that maybe the lounge would be a good place to have a conversation... a little back and forth... ideas, experiences, brainstorming... specifically about conceptual structures... In the beginners area, there was a whole lot of "where on earth do I begin?", and while there is probably several good answers, I thought that one of them happens way before fingers touch keys...

I'd like to entice those that have experience with making any game... to talk about their experiences with respect to how to think about game structure... pros and cons, gotchas...

Can I count on you to join it? Grab some coffee... hang out.

I'd like to be introduced to new ideas, or be cut off from going down the wrong road -

For me, I've been thinking about what I call transaction systems... player interaction where a systematic approach is called for, especially in things like crafting type game elements...

The first thing I think about is "data". Crafting is really just data that relates to other data, so I started to wonder if a formal database structure is a smart thing to do, right up front.

I suppose in basic form, a list would do... with a few elements to each "line in the list": oven, stone, wood, fire might be a way to know that to make an oven, you need stone, wood, and fire...

But then thinking ahead, what if you want to be able to burn paper, wood, coal, or natural gas? What if you want to change how fast the oven functions, based on what is burning in it? Suddenly... things are getting far trickier.

I guess some generic concept of "strength" for a given item could work - Paper.strength = 1, Wood.strength=2, NaturalGas.strength =5, Coal.strength = 7...

With these weighted items... one could calculate how fast the oven operates.

But wait... wood can be used in other places... the strength value for burning, might be a poor choice for a value when used for another purpose, like making a tool or a bridge or a house.

Now I'm thinking that context matters... Holy crap... what a god-awful mess!

Then my head thinks: Database...

Now, I'm no expert on them... at all. While I'm sure that a db could handle this... I have to wonder if it's overkill... or if it is flexible enough to grow or even fundamentally change if the game evolves a new twist.

Maybe it's a case of maintaining a few tables?

One table can describe all of the basic attributes of an item... how well does it burn? How hard is it? How destructible is it? How flammable?

Then in another table one might have a list of objects, and what goes into them... perhaps using and/or to describe those things.

Oven = stone or sheetmetal, wood or paper or coal or gas, matches or torch or disposablelighter

I suppose for ultimate flexibility, one could write a function for the creation of each kind of object to be crafted... and you could do some crazy stuff... like... what if you wanted to "craft" photographic film... but the film would be ruined of you crafted during the day, or with the lights on...

Suddenly I feel like I went down the rabbit hole...

Perhaps the best design decision would be to set up hard limits to the kinds of interactions possible... just for the sake of sanity!

Did you have to deal with things like this?

Hmm. I normally think of game design in a more top down way. Any game can be described with a fairly short list of features. In my game design tutorial (http://www.gamedev.net/page/resources/_/creative/game-design/developing-your-game-concept-by-making-a-design-document-r3004) I've got this checklist for people to go through when making a features list for their proposed game:

1. Genres: What kind of pet games are there, how are they different from each other?
2. Theme: Story, Setting, Playable Character(s), And How These Should Interrelate With Gameplay.
3. Distribution and Monetization: Getting the game to the player and the player's money to you.
4. Player Registration and Account Creation, Data Storage Within The Game
5. Avatar Creation: Human vs. Pet, Clothing Systems, The Avatar's Role(s) Within The Game, Avatar Equipment Slots, Stats, and Abilities.
6. Inventory Systems: Types Of Items And How Each Type Functions Within The Game, How The User Interacts With Storage, Storage Limitations And Expansion As Gameplay.
7. Gathering and Crafting: Climbing the Tech Tree, Recipes, Skills, Building Up Infrastructure, and Crafting Gameplay.
8. Trading, Shops and the Marketplace
9. Forums, Messaging, Chatting
10. Pets In More Detail: Functionality Within The Game, Capturing, Breeding and Genetic Systems
11. Tutorials, Quests, Reputation, and Levels
12. Combat
13. Minigames, Puzzles, And Other Combat Alternatives
14. GUIs and Controls, Game Modes and Context-Sensitive Behavior

Your example here would definitely be in #7 (not #4 as you might be thinking). So we'd go down a level by asking what the general crafting system for the game is. The general outlines of the system would limit the flexibility and complexity to that which is actually relevant to the game's concept and intended audience. Having already answered #1 and #2 (hopefully) you would know what general type of world the game is set in and what the player's main activities within this world are expected to be. This should give you a rough list of what specific resources could be gathered in this type of world and what specific crafting products would be useful to players in non-crafting gameplay. If it's the kind of game where individual players are gathering resources from the world starting with low-tech things like wood, you probably have a pre-renissance setting where you don't have to include gas fuels because they are too difficult and dangerous for an individual to plausibly harvest and use; instead you might want to consider grass and dung as potential burnables. On the other hand if you want to have players commonly trading each other containers of gas or mana batteries (maybe in a steampunk setting) then they probably don't bother burning wood. In neither case would anyone use paper as a fuel, because that would pretty much never be economical.

Then you want to consider your audience and game type. A lot of sandbox survival games like Wurm and Xsyon choose to emphasize the player's level by making gathered materials have a quality number based on the player's skill at the time of gathering. Personally I think that would be a bad choice for a more player-friendly sandpark type of game like I'd prefer to design and play. Why? Selling to other players, for one thing. If you intend to have a global marketplace, you would expect to see lower level players (who need money) who want to sell basic gatherables to higher level players (who are tired of gathering those). That's impossible if low level players are incapable of gathering the same quality basic mats as higher level players. Your intended audience would also affect whether you want to show them a piece of wood in terms of 12 different numbers, or just say that as far as burning is concerned, wood is wood, and as far as carpentry is concerned, all wood has 3 simple stats: hardness, flexibility, and color.

Now for something like making film, that's pretty much chemistry or alchemy. You could make "current light" a standard part of the chemistry/alchemy UI, and simplify light into 4 or 6 distinct states: dark, full sun, dawn/dusk, fire/candle/lamp, etc. Then the crafting recipe or skill entry in the tech tree could have a little symbol for what kind of light requirement the recipe had, or whether there was no light requirement. One you have a shore written description like this of how light-sensitive crafting would work, then you assess it for whether it would be fun or whether it would be better to simplify it out of the system. If there's only one or a few light-sensitive crafting recipe(s), perhaps instead an appliance like a "darkbox" could be required for crafting those.

Edit: I wanted to add, editing/revision is also important to developing a concept into a solid game design. General design principles, like condensing a semi-random brainstormed list into an orderly set with the minimum number of objects for full functionality, are much easier to apply as a revision step than as a restriction during the phase where you are brainstorming and generating a rough draft of your design. Just like in writing fiction you may also need to "kill your darlings" - eliminate or change something that's ok by itself but doesn't fit correctly with the rest of the design or your design goals for that particular project.

But wait... wood can be used in other places... the strength value for burning, might be a poor choice for a value when used for another purpose, like making a tool or a bridge or a house. Now I'm thinking that context matters... Holy crap... what a god-awful mess!

Some of my best game designer friends and co-workers had a simple philosophy:

Make the game design and the user manual at the same time.

If writing the user documentation for a feature is complicated, or if you as the designer have a difficult time explaining it to a potential user in an easy way, the feature is too complex.

Good games are narrow but deep. The small number of choices allows a player to easily wrap their brain around them.

They might be a set of simple supply chains. One chain might be fields --> wheat --> grain --> flour --> bread --> happy people. Some supply chains produce raw materials, like Woodcutter produces wood, sawmill turns wood into lumber. Other supply chains might be more complex but are still easy for players to wrap their brain around: (wood + tools) --> mine --> ore. Wood --> charcoal. Ore + charcoal --> ingots. Ingots + charcoal --> tools or weapons.

Another might be a selection of weapons and armor or other features. These are usually kept imbalanced. You get a heavy weapon at the cost of armor. You can have heavy armor at the cost of speed. Then you get games based around the mechanics where the teems need to constantly re-balance the selection of characters and attributes to counter what other players are doing; as a Team Fortress 2 example, if everybody chooses to be a Heavy they'll be weak against snipers and spies, quickly losing the game. All the roles are in a state of imbalance, each has strengths and weaknesses so they all remain viable play choices.

Write the manual along with the design. When a play mechanic no longer fits on a 6x8 page it is too complex.

The first thing I think about is "data". Crafting is really just data that relates to other data, so I started to wonder if a formal database structure is a smart thing to do, right up front.

Don't do that. When doing design you might talk with programmers about building sets of data to tune and adjust. Unless you have formal training and at least a CS degree, stay out of database design. Without a degree it is okay to build your own file formats and similar simple structures, but good database design takes training and experience. When people start specifying database design in the GDD they usually don't think about concepts like data normalization and canonical sources, data locality, and data storage response times. At the design step you should not be thinking about the internal details of representation. Knowing what data you need and where to put it should come after the design is figured out and feels fun. The specific details of what data goes where doesn't happen until the design is quite solid.

First thing that came to mind is scoping. What exactly are you designing for? If you are thinking of a simple game like the Settlers/Agricola, then you can come up with any rule you want: Need 2 wood, 3 concrete to make an oven. Need 10 concrete for a house. Doesn't make sense, but it is what it is.

But if you are talking about Minecraft, then it should be designed from the molecular level (or pixels, or blocks if you like them) How does a block of wood work with other blocks? What is the strength and weight of each block of wood as a supporting structure. I wouldn't use wood as a material for ovens because it's flammable. It's not that wood has a relationship with ovens, wood has a relationship with flame, another material. Once you create the relationship between all materials, the combination of these materials creates depth in your game. Players will want to try things out, to see if they can build things.