Hi all.

Since my last post was rather huge and interested readers will have to wait 'till their weekend to sit down with a hot cuppa and a bikkit to read it at their leisure, I thought I 'd speak a little about the other Big Idea I 've been working on. In fact, the other Big Idea, is the one Big Idea I 'm working on and the point were all the others are converging.

I call it the Game Development Kit, or GDK. What it is, is a tool for game designers- primary board-game designers, and I use the term in its broadesy sense, so as to include CCGs, RPGs, wargames, boardgames, traditional card games and everything in between. I guess it could be of use to designers of video games, and even outdoors team games, but that's a bit of a stretch there.

Now, the GDK is not a theoretical model, nor does it analyse the content of games, or their function, in any way. What it does is outline a number of components that seem to be common in most game designs. That part of the GDK, which is the one I 'm in the process of re-working after a first draft, I call the Basic Framework. This will be followed by the Game Building Procedures, the instructions for using the Basic Framework to actually design a game. There will also be an example of using the GDK to build a game, though I haven't decided what that will be yet.

What I wanted to do here, was present, very briefly, the components proposed in the Basic Framework to start a discussion. In my latest version of the Basic Framework text, some of the components are finalised (as far as I can tell in any case!), some are being reworked and some I have just realised I need to include, so are practically just a general, vague idea. I 'm going to list each component below and indicate at which of those three stages each is, at the moment. Last time I worked on the GDK was a week ago; I gave myself a break, and I intend to continue in about a week from now, when my university exams are over.

So, without any further fanfare, here's a brief introduction into the Basic Framework, as per the version 1.1.1 of 2006 (version number, btw indicates: first general concept. first design outline. first substantial amendment) :

The text begins with the following general description:

The Basic Framework defines the fundamental components of a game, as perceived by the Game Development Kit. A game is seen as a Game Environment, in which a number of different Game Elements interact with each other, following the instructions presented by a set of Rules.

Then the particular components are explicitly named and described:

1. The Game Setting defines the game's subject, or thema. What is the game about? Is it an abstract game? Does it have a concrete Theme? If there is an elaborate narrative construct on which the game reality takes place, that is defined as the Background for the Setting. [reviewing]

2. The Game Environment is the context in which a game is interpreted from a real world perspective. It contains everything that must be used to play the game, including rules, players, dice, cards, objects and so on. The contents of the Game Environment are categorised into Game Elements and Rules. [finalised]

3. Rules define the Game Elements and their interactions. The current definitioin of a Rule by the GDK is:

A Rule is a set of instructions to be carried out during a Game [finalised]

4. A Ruleset is the definitive document outlining the game Environment and Setting. The Ruleset explains how the game is intended to be played. [finalised]

5. Game Elements are the distinct parts of a Game Environment. They can be either physical, like pawns, dice, a playing board; or conceptual, like character classes, unit types, Attributes and Abilities and so on. [finalised]

5.a A Game Element will have a State, a property, or set of properties, used to quantify its interaction with the Game Environment. [finalised]

5.b Game Elements can be defined by other Game Elements. We then say that the defined Element is Contained in the defining Element. Elements can contain one another in a Nested Hierarchy of Game Elements defining each other. [finalised]

5.c. Structures are collections of Game Elements contained in nested hierarchies. We note that a Structure is itself a Game Element, its State defined by the Elements in its collection. [reviewing]

6. Players are the entities participating in, or contributing to a game. They interpret and carry out the instructions of the Rules. Their constant interaction with the Game Environment advances the game towards completion. For all intents and purposes, Players are a Game's sentience. [finalised]

6.1. Player Roles describe the contribution of each player to a game's proceedings. Players may share the same, or have different Roles. [finalised]

7, Game Variables are values used to define other Game Elements. The value of a Game Variable can be either a Quantity or a Quality. A quantity will be a number, whereas a quality will be a set of concepts arranged on a scale. A quality can also be a reference to another Game Element. We say that Variables are Set to a value. When a Variable is set to a new value, we say that it is Modified. [reviewing]

7.1 Modifiers are numerical values used to perform basic arithmetic operations on the value of a Variable, when that value is a quantity. The Variable's value is then set to the result of the operation. We say that Modifiers are Appplied to values. [finalised]

8. Resources are a special case of Game Variables. A Resource is always a quantity, measured in units known as Resource Points. Resource Points can be added or subtracted from the value of the Resource, rendering the Resource Expendable. [reviewing]

9. Game Time is a fundamental Resource, considered to be a Game Constant. It is measured in Turns, each of them comprised of a number of Time Segments. Anything that happens during a game, happens during Intervals of Game Time Units (either Turns or Time Segments). The State of an Interval can be either Elapsed, or Not Elapsed. [finalised]

10. Game Pieces are the playing pieces of a game. They may or may not be physical playing pieces. [finalised]

11. Effects are Game Elements that cause the values of Game Variables to be modified. They are said to Apply to the Variables they cause to be modified. An Effect may apply to other Effects, therefore applying to any Variables the latter is applied to. An Effect's State can be either On (being applied) or Off (not being applied). [finalised] 

12. We say that Effects are Generated when they will be applied. An Effect will have a Source, a Game Element generating the Effect and a Target, a Game Element containing a Variable the Effect will be applied to. [finalised]

13. Game Elements interact with the Game Environment by means of Actions and Events. Both generate Effects and have a Source and a Target, like them. If an Element is the Source or Target of an Action or Event, it is the Source or Target of the Effect generated by it. [finalised]

13.a. The Source of an Action, must be a Game Piece. We say that such a Game Piece Takes an Aciton. [finalised]

13.b The source of an Event must not be a Game Piece. It may be an Action taken by a Piece, or an Effect generated by such an Action. We say that Events Occur during Game Time, or are Caused by a Source. [finalised]

13.c. Sometimes a Condition will be delineated, that must be found to be true before an Effect is generated or an Event occurs. We then say that the Effect was Triggered by the Condition and the Condition is the Effect or Event's Trigger. [finalised]

14. Controlling Game Pieces and Events.[reviewing]

14.a We say that a Player Controls, or is the Controller of a Game Piece when a Rule allows that Player to decide that the Piece will take an Action. We say that the Player Activates that Game Piece. The Conrtroller of a Game Piece, controls the Actions taken by the Game Piece and the Effects generated by those Actions. [reviewing]

14.b. We say that a Player controls, or is the Controller of an Event when a Rule allows that Player to decide that the Event will occur. We say that the Player Manages that Event. An Even'ts Controller is the Controller of the Effects generated by the Event. [reviewing]

14.c An Event may not require the decision of a Player to occur. Such an Event's Controller is the Game;  those are known as Spontaneous Events. [reviewing]

15. Effect Resolution. Effect Resolution is a technique used to quantify the application of an Effect to a Variable's value. Techcniques used may include randomisation by use of dice, or cards, or other devices; expenditure of a Resource; Player decision; and others.[vague/ concept stage]

16. Order of Play describes the order by which Players Activate Game Pieces and Manage Events. [vague/concept stage]

16.1. Actions and Events are Inserted in the Order of Play. When the Order of Play is Finalised, each Action and Event inserted into it generates a number of Events. We then say that the Action or Event has been Completed. The Action or Event is then Purged from the Order of Play. [vague/concept stage]

17. Mechanics. The definitions of Game Elements by the Basic Framework may be modified, and new ones described, by the us of Mechanics. This is the Game Development Kit definition of a Mechanic:

A Game Mechanic is a subset of a Game's Rules.
[reviewing]

Hi, welcome to the forge!

These are very much component parts, aren't they? Take chess for example and say all boardgames were like chess. Now, the point of chess is to see which player wins. BUT you could write down all the component parts that seem to be needed - kings move one square, rooks go in straight lines, knights do that stupid move, pawns take one step or two at the start. But none of it addresses the games goal - to determine a winner. If you have all that movement and stuff but no rules for winning, it just goes on forever.

Now, 'determine a winner' is one goal - did you have any plans to discuss the games ultimate goal, after identifying components? Like, what sort of goals you could have?

Erm, yes, Objectives. They 're in my notes, along with Play Area (the chessboard). But not in the version I used to write the post above. Work in progress and all that.

So, 'ere goes:

18. Play Area is the physical space occupied by the Game Pieces, while the game is being played. [vague/concept]

19. Objectives, define a set of conditions which, when found to be true, may assign a special State to the Players, or the game itself.

19.a Victory Conditions, indicate that a Player is the Winner of the game, when an Objective is found to be true.

19.b Elimination Conditions, indicate that a Player is Eliminated from the game when an Objective is found to be true.

19.b.1. When a Player is Eliminated, that Player may no longer follow the instructions given by the rules. That Player may not further interact with the game, until the current game reaches completion and a new one begins.

19.c. Closure Conditions, indicate that the game is Over, or complete, when an Objective is found to be true.

19.d. When a game is over, play stops and the game ends. When the game ends, and until a new one begins, the Rules are not observed; no instructions are followed that will advance the game towards its completion. [vague/concept]

Now, could someone please explain to me about the edit button?

Forum changes: Editing of posts has been turned off until further notice.

To answer your question, "what does it do", I 'll redefne the GDK, as I will probably do a lot anyway.

The theory behind it:

A Game is a Turing-enabled machine.
- The Rules are a set of instructions, that explain how the game should be played.
- The Players interpret the instructions and carry them out, changing the state of the Game.
- The Play is the sum of all possible states the Game can be in.

If you give a different set of rules to the players, they 'll play a different Game. You can give them any set of rules and they 'll play any Game. This is what makes the machine turing-enabled.

That's the theoretical part. To implement it in practice, you need a structure that can actually do all of the above. Define the Rules, Players and Play of the Game, any Game. The GDK is one such structure.

An analogy: If A Game is a computer, the GDK is a software development environment. The Basic Framework, outlined above, is the standard for a Game programming language. The next bit, "Game Building Procedures" will be a compiler for the language. Designers write their game's code in Basic Framework terms, then feed it to the Game Building Procedures to come up with an executable text that can be run by A Game.

To the extent that it outlines what I want the GDK to be, I believe this is a solid analogy.

Do I think that it answers your question? You ask, in short "who is going to play your game?" Because the GDK itself is of course a game too.

Your question has the connotations of "how will you market your game?" Well, I 'm not going to. What I 'm going to do instead of defining a target audience, is find a clear, concrete description of what the GDK is and make sure as many people as possible can come across it. Anyone who's interested in something like it, will then have a chance to know it is there.

That is actually a strategic decision. I can't know who will be interested in the GDK. I don't I know what it is that different types of gamers and designers like or don't like, or what they are interested in. I might be able to find out, but at a cost, in terms of the resources in my disposal.

As the resources in my disposal consist primarily of my motivation to design well, the profit I make is in terms of whether I consider the design itself successful or failed.

Instead of squandering my resources on trying to address an audience I don't know, I 'll concentrated on designing a tool that works. If it works, someone might use it. If it sort of works a bit and is kinda cool for a few people who might be interested a little in something more or less like this... noone will.

The tactically correct decision is, I think, clearly outlined.

Now if you 'll excuse me, I have a university exam to do horribly in. I 'll be back in a couple of days.

Btw, my question about the edit button is why it isn't there.

Hi

This is interesting. I think it is nice to have some tool that can help you designing games. I am also working on some rpg design tools/methods/procedures, though I take an different approach.

There are one thing that bug me a bit: In you framework you seem to only describe the low level rules - the gaming physics - the rules that tells exactly how the different "pieces" moves  around and interact.

When I approach rpg design, I am more interested in the high-level rules; rules for dramatic interaction and storytelling.

For example a rule like: "A player can add a NPC or event to the story, if it relate to his character's personal goals."

Can the Basic Framework account for this type of rules?

Another thing. To prevent possible confusions, I think you should take a look at the "The Provisional Glossary" (http://www.indie-rpgs.com/_articles/glossary.html). There you can see how most people around here define terms like "rules", "system" or "mechanics".

I look forward to see your Game Building Procedure.

- Anders

I think "what is the GDK for?" and "who is it for?" are questions that are more designed to help you narrow down the goal of your design, rather than to challenge its possible applications.  Think of it like this:

The GDK is a tool.  Tools are used to help accomplish tasks.  What is that task that the GDK helps to accomplish, and how does it do this?

By answering this questions, particularly the implied question "what problem does the GDK help to overcome?", I think you'll be able to more acutely focus your design skills.  It's like, you can't design a good hammer without first knowing what sort of jobs you're going to do with it, and what's wrong with existing hammers (answer - they keep going missing.  I blame the gnomes).

With regards to the Edit button, I believe it might be disbled to prevent heavily or repeatedly edited posts from confusing discussion.  I know from experience that it's hard to follow a discussion that references an Original Post which is edited to match with ongoing discussion.  Also, it can stop "he said/she said" arguments from getting really confusing.  This is just my best guess though.  If it's a serious issue for you, raise it in the "site discussion" forum, and you'll at least get a comprehensive answer to your question.  It might already be answered in a sticky there too. 

Btw, my question about the edit button is why it isn't there.

Hi YeGoblinQueen,

Interesting. I've developed something similar that is not quite as thought out as your GDK and posted it on my website for my podcast today.  I think I'll add a link to here.

As far as editing,  I don't know the actual reason, but I would suspect it's to prevent intellectual dishonesty. I've been to some forums where the participants are so concerned with being the "winner" that they would go back and re-edit posts to remove parts of their posts that someone else had used to make valid points attacking the editors position. That or get angry and remove all their posts leaving this gaping hole in the discussion.

Joepub: On reading Simon's post I realised I might be coming across like an arrogant twat in my reply to your post, so please excuse me if my tone annoyed you, that was not my intention.

Anders. (high level rules quote here)

The idea of the GDK is to establish, precisely, the low-level rules, the physics engine as you put it, but not for RPGs. Instead, I 'm making a language (like contracycle says) that will enable us to speak about games in general. Board games, Card Games, wargames, RPGs, everything.

That means that the language must necessarily be low-level. Otherwise it will be incompatible with different genres. If I define a rule by which an NPC can be added to the story, I have to define PCs and the story- but those are not elements, of, say card games, at least not universal ones. The GDK must be relevant to as many genres as possible, so it must avoid being exclusively relevant to any one, at all costs.

Yes, there is overlap between the GDK language and the theory at the Forge. But that just means I 'm doing my job right, if you know what I mean! Besides, the Forge theory is theory, and it's RPG- specific theory. The GDK's purpose is practical and generic.

Simon C: The problem is that I can't explain how exactly the GDK will work without explaining how the Game Building Procedures will work, but I can't explain those because I haven't got them yet. I have general ideas and guidelines and I know what they 're supposed to do, but I haven't began writing them yet. I 'm waiting for my exams to be over, when I have some more time in my hands- and when my courses will actually help me decide how the Game Building Procedures should work.

But, to give you a vague impression. What do you generally do when you design a game? I ask myself what the game is going to be about and what's gonna be in it- but, in terms of characters, as Anders said, in terms of drama and high-level design.

The GDK would work instead as an underlying template, a scaffolding on which to base that high-level design. I would ask myself "What are the Game's Elements? What Variables do I want to define?" If I wanted to make an RPG and have characters I would ask "What are the Game Pieces?" And I 'd answer "A Game Piece: Character is defined by a Structure: Characteristics, containing the Variables: Attributes, Equipment, Background."  Then I 'd define the Variables in the Structure: Characteristics and the Mechanics that describe their interaction with the Environment.

Then, I 'd known exactly how to fit my Game Piece: Character into the Game Environment, because the Game Building Procedures would tell me how to do it- and the Basic Framework, to a certain extent, explains what the fundamental relationships between the Elements involved are. For example, a Game Piece is defined by a Variable, a Variable is defined by a name and a value. A character is defined by a Strength Attribute variable and its value determines how the character uses their Strength to interact with the game world.

And what niche would that fill? Aha, see, you 're doing it too. You 're thinking in marketing terms, in terms of offer and demand. That is not the point, but if you insist, damn you, here it is. The GDK is a game for the people who enjoy making games. When you play it, you make a game- in that aspect it's much like the d20, or GURPS or FUDGE or the Hero System or what have you. But the GDK is more ambitious, in that I want it to be a game for all categories of games, board games, card games... oh, I 've been there already. So it's a GURPS for making GURPSEs, and Runequests too, and also Magic;The Gatherings and Monopoly's and what have you.

So why is it better than existing GURPSEs? It isn't. It's wider in scope and since it doesn't give you a game engine (as in dice rolls, character stats etc) it's deeper in level. There's nothing wrong with existing GURPSEs. But they are GURPSes. You won't get to design your own card game if you read a GUPRS rulebook- the idea is that, with the GDK, you will.

It may appear, at this point and to some readers, that the restrictions placed upon game design by the GDK would parallel those of designing a setting for D20 by the System Reference Document. However, the GDK's design goals are to avoid that- game design should be facilitated, not restricted. I hope this will become more apparent as the GDK's design progresses, but I think it can already be seen by the mission statement: a tool to design any kind of game..

Anyway, I really thought my Game as a computer/ GDK as a programming language explained my purpose. Are you sure it didn't help at all? Oh well, I guess I get so caught up in my own metaphrs sometimes, I think they 're self-explanatory. Hope I didn't do that again just now, huh?

I did something quite similar with my Myriad system, excepting that I'm providing a toolbox that's specifically tailored towards the creation of an RPG with a core nucleus system to build upon.

Ash

as i look out into this broad feild of game design, i see something odd. i remember haveing a hard time trying to lock down my ideas. still do in fact. but to consider that i also wanted guide book that told me how-to make "SOMETHING" so i could have a base to work from and change as needed, i see the concept of haveing a "GDK" as being both tricky, and needed. but the rules need to be more basic, easy to grasp, and fewer than what you got. but excellent concept.

Just a quick note.

I think I 'll have a definition of "Game" in the Basic Framework after all. It will be along the lines of the "Turing-machine game" I posted above, but probably not in those same words, although, why not?

Also, with the Game being the top node in the Basic Framework, the Game Environment will be moved up a level to encompass the Setting and the System (or Engine, or Mechanics, or Machine or whatever)- so basically I 'll just rename what is now the Game Environment to "System" (or something).

The Setting/System classification is very RPG though so I might rename "Setting" to "Theme" which is more generic.

Btw, I 've not done any work on "Setting" so if anyone has any ideas on where I should go with that, what are the basic elements of game themes and subjects, I would really like to hear about it.

YGQ (have I missed your real name?), this is a noble endeavor, but I think you might have misidentified it. You're not building a toolkit here, exactly; you're doing theory, and plenty of it has been done and is in progress. More general gaming theory doesn't see a huge amount of play here at the Forge IME; others can probably do a much better job than I could of pointing you at resources here. But I'd point you at two things: <a href="http://mitpress.mit.edu/catalog/item/default.asp?ttype=2&tid=9802">Rules of Play by Katie Salen and Eric Zimmerman, and Ben Lehman's weblog posts about social context (<a href="http://benlehman.thesmerf.com/?p=56">1, <a href="http://benlehman.thesmerf.com/?p=193">2, <a href="http://benlehman.thesmerf.com/?p=194">3, <a href="http://benlehman.thesmerf.com/?p=195">4). I think that both will help put what you're doing in a stronger context, and point you to still more to draw from.

I disagree. I am well aware of the theoretical work done here at the Forge and I consider myself too courteous a person to barge in with my own, misinformed or half-formed theoretical schemes.

To treat my GDK as a theoretical tool, or the result of an analysis of play of RPGs is the miconception, not my describing it as a practical tool.

I will, once more, attempt to show the difference here:

The GNS and The Big Model developped at the Forge, are concerned with the aspects of RP gaming from design to play; they refer to content and context. What are RPGs like? How are they played? Why do people play them? What do they get out of it? And what do they put in?

The GDK, in particular the Basic Framework, is concerned with the aspects of general-format gaming, before and up to design; it refers to to components and function. What constitutes a game? How do a game's parts work? What are a game's possible states? What processes choose a game's state? What instruments are used?

Johnweed: Thank you, that is encouraging. What you say is true, ease of use is important if the GDK is going to have the parctical purpose I maintain it does. However, this is only the first part of the first version. I imagine it will take me a couple of years to bring this idea to full bloom.

Oh, I 'm going to release a first version before fall this year. But, well, first versions must be buggy. Otherwise, what's the point of getting a second one? ;)

YeGoblynQueenne wrote:
I disagree. I am well aware of the theoretical work done here at the Forge and I consider myself too courteous a person to barge in with my own, misinformed or half-formed theoretical schemes.

To treat my GDK as a theoretical tool, or the result of an analysis of play of RPGs is the miconception, not my describing it as a practical tool.

Okay, so, reading this thread over again I have mistaken your intent. Nevermind me, carry on.