Skip to Content

Design Process Loophole

14 replies [Last post]
larienna
larienna's picture
Offline
Joined: 07/28/2008

I am trying to design some elements of another of my game in design and while I do this, I tried to analyze the design procedure I took in order to optimize the process or the future games I design.

I know that game design is an iteration process where each iteration contains new rules, prototyping, risk evaluation and play testing. That is not what I want to talk about. I want to talk about the game design process only.

-----------------------------------------------------------------------

Step 1- At the beginning, there is the abstract of the game. I made a vague description of how the game would work. I defined various elements like the space, objects and actions, and I set up the goal of the game.

Step 2- The 2nd thing I did is identifying which components I want to use. Dress up the turn order process and determine the rules of each step in the turn order. This is what I call the rule draft.

Everything good so far. Of course, with multiple play testing, the elements defined above will change and evolve. So let's continue to step 3.

Step 3- Design the data of the game. Game contains information and it needs to be defined. For example, if you have a deck of event cards, you need to determine what events are going to be on the card. So you need to list the data to design, define the structure of the data, like in a database, and create the content.

-------------------------------------------

All the steps above, especially step 2 and 3 are repeated after each iteration. Now here starts the loophole

The loophole I want to talk about is especially true when you start a new game. It is also the reason why making a variant is way much easier than making a new game. This is also the concept of foundations I was talking about way in the past ( if you design a game on some foundation, the design process is easier, better and faster).

Let say step 2 is done. I have a good idea of the actions that the player can do and how the components are going to be used. Now, I must start step 3.

I need to design for example, the special event cards in my deck. I can determine the structure of the data according to the rules determined in step 2.

But it is very hard to define the content because the content influence the rules of the game, but the rules of the game are not solid enough to actually design all the event card data. On the other hand, you need to define the card's data else you cannot test the rules of the game.

So you get in a situation where each side of the design depend on each other. So you can't design any of the side because none of the sides are clearly defined since they each depend on their counterpart to evolve.

Example of situation I want to avoid: I took 1 week to design hero characters which would influence the production system. After the first play test, the production system was wrong and was redesigned from scratch forcing me to drop all the characters I had made.

------------------------------------------------------------------------------

So my question is: Do you have any suggestions for getting out of this loop hole?

My solution so far is to make a dumb data design to be able to test the rules of the game. When the rules gets more solid, you can design a selection of data that makes more sense and is more balanced to what you want to achieve.

Various ways I found so far to make dumb data so far:

- make a random selection of stats
- use components from another game that looks close to your game
- Use the void: Use empty or almost empty information on your components.

Any other ideas?
Besides designing dumb data, do you have other solution suggestions?

Arvin
Arvin's picture
Offline
Joined: 05/29/2009
Let me get this straight.

So what you mean is this: (correct me if I'm wrong)

You try to make a new game by borrowing a system from a previous game. You did this by removing everything (or some part of it) from the previous one, but when you try to change some part of the system to make a new one all the other part must change too, it's like starting from scratch again. Right?

Which is like trying to change the theme of the existing mechanic. Once you have done this, something tells you that it's not right and something must change also so that it could work on it's own.

Ex. I tried to make a variation of the game "Risk", change some parts of it. Once I've done that it doesn't feel right. what I do is change another part but it still doesn't feel right, until I come to the point where everything is changed or about 90% of it is completely new.

hulken
Offline
Joined: 04/18/2009
It just sound to me like you

It just sound to me like you have invented a problem where there is non... Borowing components as you describes in the last part to me that is playing pices, game board and so on. Borowing a mecanic that is somthing compleatly difrent. Taking macic card into youre new game that I would say would be borowing a mecanic. (this is my take on defining components and mecanics)

If it is the borowing magic cards that is truboling for you then I would recoment borow the card and make up the rules. Play test. If it do not work the way you want it find out what is the problem and change that, it can be as easy as changing a card to make it less powerful or changing a rule...

Youre 1, 2, 3 to me just sound alike a lot of typing for saying a fue things.

1. Game idea (abstract)
2. How do you want the game to play, what featurs do you like in the game.
3. Make the game. (this includes fintuning and posible major reconstrutiv curgery if that becomes nessisary)

So to me this is the 1, 2, 3 you want or did I miss somthing?

Ewain
Offline
Joined: 05/21/2010
Use the loophole

I recognise the problem (mainly from troubleshooting computer networks), where there is one part of the design that I absolutely have to have in a certain way, or the entire thing will have to be rebuilt from the ground up.
Usually the solution is either very simple and comes quickly, or complex beyond belief and take a team of confused techs to solve...

In game design terms I guess that it would be this theme or mechanic that I want to make into a playable game, and we're back with the "simple or complex" situation.

For what it's worth, I believe that your design process need the loophole because you do 'playtesting in your head' as you define how rules and data should work together. It sounds as if you have become very good at finetuning that interaction, and I can appreciate that it chafes to have to redo a lot of stuff over and over again -but it may be the price you pay for improving.
So to answer your question; I don't see a reason to change what isn't broken. If dumb data works for you, stick with it!

larienna
larienna's picture
Offline
Joined: 07/28/2008
Ok, for post 2 and 3, I think

Ok, for post 2 and 3, I think you misunderstand me.

I am creating a new game from scratch and that is basically the problem, there is nothing.

I want to make a new game. Lets take for example magic the gathering.

Step 1: I design that I want a collectible card game, that will mostly use the cards as components. I have a vague idea of how the game is going to be played.

Step 2: I decide that I want cards and tokens in my game. I determine the turn order procedure and I describe the rules for resolving each step.

Step 3: Design the structure , the type and the content of the cards

Problem:

  • The cards change the rules of the game. So I can't design the cards because I don't know if the rules are actually working because I have not tested them yet.

  • But I cannot test the rules because I do not have any cards to test with.

that is the loop hole, one depends on each other.

Solution:

Random: Make random cards, add the few effects that comes to my mind, use random stat distribution for the monsters.

Scavenge: Use components from another game. Here it is impossible because when MTG was created, there was no other CCG yet since it was the first CCG. So you can't scavenge components from another game.

Almost nothing: Design cards with only casting cost so that you could test a portion of the game.

I hope I made my self more clear

RogueKoi
RogueKoi's picture
Offline
Joined: 07/29/2009
Chicken and the Egg

It seems to me to be just a problem of: "chicken and the egg".

This happens alot when one programs things as well, which also happens to be an iterative process. You need to build a system yet the system requires data to be built to run.

I would have to agree with Ewain, you need "dummy data" in order to get the system running. More often than not (and this comes from both programming and developing a ccg as well) you will get to a point that you cannot go further with out further developing the dummy data (or objects or bit or whatever you might be needing at the time). After developing the data you can return to the main rules and tweak them to fit what you have learned about what you really want from the data being pulled in.

So in effect the solution becomes not one of: design this, then this, then this, in a sequence; but more: develop all you can at once and then switch between each as you go building as needed. In the end the system will be what you wanted.

So... after that ramble it comes down to basically: "its not a bug, its a feature" (without a hint of irony mind you :P)

On a side note; if you are looking to increase productivity, or whatnot, you may look into agile methods and see if those can apply to your end goals.

Arvin
Arvin's picture
Offline
Joined: 05/29/2009
I suggest...

larienna wrote:

I am creating a new game from __scratch__ and that is basically the problem, there is __nothing__.

__Solution__:

__Random__: Make random cards, add the few effects that comes to my mind, use random stat distribution for the monsters.

__Scavenge__: Use components from another game. Here it is impossible because when MTG was created, there was no other CCG yet since it was the first CCG. So you can't scavenge components from another game.

__Almost nothing__: Design cards with only casting cost so that you could test a portion of the game.

larienna wrote:

Various ways I found so far to make dumb data so far:

- make a random selection of stats
- use components from another game that looks close to your game
- Use the void: Use empty or almost empty information on your components.

This is what I do when I design my game. I use the "void" where there is nothing inside the component except for the initial contents that I intuitively put there. What I mean by this is that before I start my game I don't just build a part of the system, but I build a small system which could later be changed, removed or improved.

Solving your problem with random beginnings is good but first you should have a working system. Once it starts it will continue to develop.

Here are my suggestions:

1.) Build on an existing system which is on it's core elements. When this is done, start adding other components that you would like in the game. Let this process be based on Intuition. (I know you know this already)

2.) Randomizing is good but doing this on the initial system wouldn't work (or it will be very hard to make it work) because you have no idea what it would do.

3.) There is another thing that I do. I try to build on existing simple mathematical equations then from that I build the initial system.
Then I add random things to try to make it work (What I add are also simple chunks of mathematical equations). I choose math equations based on how they best represent my idea.

4.)Instead of making random things to add to your system, as you say: borrow it from other systems. but the problem when borrowing from other systems is that it has it's own, what you must do is make it basic but not empty (when you do this the problem starts all over again)

5.) I don't know if this would work but try it.
Let's say you borrowed from an existing game mechanic from another game. Try to put a different theme on it and try to make it work, change it so that it will make you forget that you were making the first one.
(so basically put a new theme on a mechanic). When the other game is starting to work, Use those mechanics and put it in the first game and see what it would do.

You will now be working on two games. If the other mechanic works on the other one use it there. The trick here is when your creating the second one forget about the first one.

Ewain
Offline
Joined: 05/21/2010
Good point

You're right, I missed the point..

On further consideration, I think that you put the finger on the basic problem:
But it is very hard to define the content because the content influence the rules of the game, but the rules of the game are not solid enough to actually design all the event card data. On the other hand, you need to define the card's data else you cannot test the rules of the game.

Unless the rules are in place (i.e. What is supposed to happen in my game?) you are fighting the entire process of creating the game.
Usually a game is based on either the theme or the goal, and the rules are what defines How the goal is achieved or How the theme affect the gameplay.
What I read is that the rules you've decided on are not supporting the goal of your game -thery're still too flexible to aid the design process.
I suggest you return to the rules sheet and try to 'cast in stone' what is, and what is not, allowed to happen in the game. Perhaps keeping the game abstract for another iteration (voted The buzzword of the day :P ) will get you through this hurdle...

hulken
Offline
Joined: 04/18/2009
larienna wrote:Ok, for post 2

larienna wrote:
Ok, for post 2 and 3, I think you misunderstand me.
Problem:
- The cards change the rules of the game. So I can't design the cards because I don't know if the rules are actually working because I have not tested them yet.
- But I cannot test the rules because I do not have any cards to test with.
that is the loop hole, one depends on each other.

I still say youre finding a problem where there is none. The cards that change the rules are ok, playtesting will show you if the cards ar to powerfull or if they ar ok. You still must have youre basic rules. If you have eventcards, playing cards or in som other way let players "brake" the basic rules play testil will tell you if the effect of braking the rule is to powerfull.

You might still find that one of the core/original rules is wrong and you have to change it ut it is till part of the design process.

It sound to me that you want to find a way to design a game that playes good whitout playtesting it. The onley way I can thing of doing that is if you make a game based in math and probebility. (rummy games or set colleting) and if you include ways to breake the rules al players should have the sake ability, somthing like a "use once per game" and the ability is the same for every one. That way I think you can design a game without playtesting. But the brake the rules might, just might be to powerful but that is somthing you should easaly be able to se by playing out al scenarios invalvilg the rule braking.

Have I still missed somthing?

Pastor_Mora
Pastor_Mora's picture
Offline
Joined: 01/05/2010
One step at a time

I usually design one step at a time. This means adding one mechanic at a time. For example, if I try to design a Magic like card game, I could start with the lands. I add, say, 4 land types and give a basic attribute to them (1 mana of a color). Then I go for the creatures. I set a basic creature for each land and give a basic attribute to each (do 1 damage). Each element of the game will spawn the required mechanic to add them to the game. In this case, the card drawing, land controlling, creature summoning and creature attack. Then I could go for spells, etc.

Keep adding elements to your game one by one. Playtest after you added EACH element. And for whatever you love the most, DON'T add elements just because you can, but because they would actually add something that the current gaming experience severely lacks. Many games have elements that don't really add nothing to the game iself, they are there just because the designer fancy them. These irrelevant elements can make the overall balancing process much more complicated and make the game more complex without giving it more depth, just more complexity and a harder learning curve.

That said, I don't think you can skip dumb data at all. Almost none of the initial attribute's values in my starting elements endure to the final version. Everything is dumb until everything makes sense.

Keep thinking!

larienna
larienna's picture
Offline
Joined: 07/28/2008
Quote:It sound to me that you

Quote:
It sound to me that you want to find a way to design a game that plays good without playtesting it.

I think it should rather be called designing without scrapping everything you have designed as soon as something changes.

It really depends on the king of game you are designing. When I designed Fallen Kingdoms, I did not have this problem to start the design because the core of the game simply consisted in moving units in territories. So besides the map design there was no data to define. It's only when I had the idea of adding Event cards, action cards or technologies that now I had to design and scrap a lot of things. But still here it's not so bad because what I was designing modified the core of the game which is move units and control territories.

But let say you design a game like "San Juan" or "race for the galaxy" where the cards are themselves the core of the game, now it becomes much more complicated to design the cards. I had a "race for the galaxy" like idea, I tried designing the cards but ended up with so few cards. My first reflex was to actually look at "San Juan" and "Race for the galaxy" set of cards to get ideas for cards of my own.

I think I should use the little cards I have designed so far to give myself something to playtest with. Since there are few cards, it will be easier to change, and as I playtest new card ideas will eventually come it.

bielie
Offline
Joined: 11/05/2009
Object oriented programming

Larienna

1) Lew Pulsipher mentioned your game Fallen Kingdoms on his blog. I think it is a fantastic endorsement. Congratulations!
2) The problem at hand
You have two components: Procedures (rules) and Data (cards). Data and Procedures influence each other, so which is first?
I think the answer lies in object oriented programming (as in Java or C++)
-Each card contains it's own data and procedures in one "capsule": This means that the procedures on the card deal with the data on the card, and describe its implementation in the game. The data and procedures are therefore created simultaneously.
-Data and rules can be inherited from parent classes

Step one
Define the tree structure of inheritance:
1) Root class: Cards
Define data that is common to ALL cards in the game.
Define procedures that apply to All cards in the game and their data
-Data: How many cards in the deck.
-Procedure to shuffle the deck. How are the cards dealt. Hom many cards does each player have in his hand etc.
-how are the cards played (Turn sequence)
2) First generation classes:
Characters, Objects, Actions (For example), Encounters
Define the data and procedures for each class on this level.
Example - Character class:
-Data: Abilities, Race, Skills
-Procedures: How many abilities and skills can you have. How do the abilities and skills numerically affect play (For instance combat)
Example - Object class
-Data: Type of object, price, weight etc.
Procedures: How does the data affect gameplay.
3) Second generation classes
The second generations classes inherit all the data and procedures from their parents.
Example - Children of Character class:
-Abilities: Power, Luck, Humor etc
-Skills: Swordplay, Magic, Acting, etc
Children of Object class: Weapons, Armour, Tools etc.

Step 2: Design the actual cards

An actual card could fit on any of the levels of the inheritance tree.
It will inherit all the rules and data of its parent, grand parent and so on.
IT WILL ALSO HAVE UNIQUE DATA AND RULES JUST FOR THAT CARD.

For instance
Sword <- Weapon <- Object <- Card
Sword: Unique data and procedures: + 1 damage for sharpness. Use 1 mana to make in burst in flames if it has a + 2 advantage
Data and procedures inherited from Weapon: Play when you attack a foe. Attack advantage of x. Does y amount of damage.
Data and procedures inherited from Object: Costs x amount of gold. What is the weight. Can you carry it if you already have a grand piano or a gatling in your back pack?
Data and procedures inherited from Card: Draw the card from the draw deck. Place it in your hand etc.

Step three: Playtest
--Is there a problem in gameplay?
--On what level is the problem: The card, its parent, grand parent or all the way up at the root?
--Fix the problem at the appropriate level
--Playtest again.

Following this structure should allow you to
1) Develop data and rules that govern it at the same time, thus making it easy to guess the interaction, test your theory and change it.
2) Find the exact place where a rule or data needs to be changed.
3) If you use the board game plugin for InkScape you can change the data and rules at any level in the spreadsheet and print a new deck of cards in a matter of minutes, ready for the next iteration!

ReneWiersma
ReneWiersma's picture
Offline
Joined: 08/08/2008
I understand the problem. In

I understand the problem. In order for the game to work, you need stuff like event cards, hero characters, etc. All kinds of detailed stuff based on the the core mechanics. However, if you change the core mechanics, you also need to rework the event cards, hero characters, etc. Usually this costs a lot of time, because a lot of work went into this stuff, and everything depends on everything else.

I don't think there is a neat solution to this, other than try to design a game without these things ;) It will always be a lot of work. You could, however, try to come up with a bunch of generic "items" (for lack of a better word), just enough to make the game work, and then just continue the iterative process. Once the core of the game settles down and doesn't seem to change that rigurous anymore, you could add a level of detail and hopefully you don't have to redesign that much anymore.

Summary: yeah, it's a lot of work, board game design.

larienna
larienna's picture
Offline
Joined: 07/28/2008
Replies

Quote:
Lew Pulsipher mentioned your game Fallen Kingdoms on his blog. I think it is a fantastic endorsement. Congratulations!

Cool, that is awsome. I wonder how he found my game?

If you use the board game plugin for InkScape you can change the data and rules at any level in the spreadsheet and print a new deck of cards in a matter of minutes, ready for the next iteration![/quote</p> <p>What board game plug in? (link please)<br /> What does it do? (Or link me to a list of feature)</p> <p>I am not used to inkscape yet, that should be one of the next thing on my learning list.</p> <p>[quote wrote:
I think the answer lies in object oriented programming (as in Java or C++)

I did a lot of oriented programming, so I know what you are talking about. Still, I did not thought it could work for board game design. I'll have to visualise it better to know how I could take advantage of this.

Still, the idea is to work from general to specific. Start with general information and as the playtesting works, get into the details.

bielie
Offline
Joined: 11/05/2009
Inkscape

larienna wrote:

Cool, that is awsome. I wonder how he found my game?

He's on this forum.

Inkscape plugin:

http://www.lysator.liu.se/~perni/iboardgameexts/

Syndicate content


forum | by Dr. Radut