This is a pretty good “I could have had a V8!” moment. As soon as I begin thinking about what I need to do to make a prototype of the Cold War Game... Duh... They forgot our little corner of history, of course they don't know how we made games! No wonder they don't understand how many of them I have made... at least 100. Duh... Like I said on my blog, I was lucky enough to meet a couple of the original Avalon Hill guys at a few different conventions in the early 1980s. The same two, always together. This first time I met them was a major epiphany moment for me, I was only 15 but had already essentially been designing games for half my life. Mostly in my head, like you think we do it. That's not how we do it. These two guys told me how we did it on that day, and now I will tell you. This isn't just about me. You aspiring game designers out their can use this to actually put what skills you may have to use, or learn that maybe you might not be right for this whole game design thing. And you industry veterans will understand what a valuable tool this is for you, as well, for certain types of games that you make. This won't help you with FPS, of course, but strategy games, RTS, lots of different games... it is a very valuable tool.

So I'll just show you how I will make this Cold War board game prototype, and you'll understand the whole thing. It really is very simple. I am going to have to buy a new “toolset”. That is what this is, no different than a mechanics rolling Snap-On tool box. What do I need? For the most part... Poker Chips and Dice. Cards. A map. That's pretty much it. I can do just about anything with this stuff. I haven't really needed this to write design docs for strategy games for many years, having countless combinations of things over 20+ years with my original toolset. But if I wind up succeeding this time I'll be needing a new toolset anyway... especially for Game #7! So this isn't just for this game, these toolsets last a lifetime.

It's a Cold War game. And a big map always makes things easier, so here is my map. The Cold War connection is actually irrelevant. This is the map I have always used for grand strategy wargame prototypes. There are two sizes. You normally use the small one because only big and successful games can have a big map. But for computer games, I would use the big map like I am. You have no reason to “contain the size of the design to the small map”, and this is always a lot easier on a bigger map. There is a large F&E map like this that comes in handy for space games:-)

https://boardgamegeek.com/boardgame/2851/supremacy-mega-map

Thank you, Robert J Simpson! The perfect prototype map of the world!!!

I've certainly already have all the dice I need. Cards are a lot easier these days... with a computer to print them instead of having to hand write them. I lost most my “toolset” in a move about 10 years ago, so I'll have to go buy at least 3 huge sets of poker chips (small, medium, and large). I'll get the cheapest ones there are that are just different colored plastic chips. As many different colors as I can get. If I wanted a more complete toolset I would then get the same poker chips sets all over again, except the second set has numbers on them.

I don't need anything for a board game version of this Cold War game, this is it. The small chips are the military units (they fit on map easiest). Different colors are different units. The large chips are money. The medium chips are stacked along the side of the map and represent “strategic level information/tracking”. In this cold war game, each minor nation needs to track “relationship level”, which superpowers side they are currently on. There are 5 levels... stack of 1-5 blue chips if on US side, stack of 1-5 red chips for USSR. The military units, can be a single stack... the “rainbow edges” show you what is there. Out at Sea... SFB counters. Done. Don't need anything else for this... and it is a VERY complex game. Axis & Allies x20, kind-of like the game I got this map from was:-)

Now for the “production version”, that if anyone out there wound up being interested in this later you might actually play. 2 copies of Axis & Allies (minor nation pieces). 2 copies of Fortress America (superpower pieces). Little pyramids, little blocks, and little rectangles to represent units not in A&A or FA. 2 copies of Supremacy... for the 24 little black nuclear mushroom cloud pieces. And with Supremacy I also get both the squares and rectangles from above, so now I only need the pyramids. Now I will get some decently nice numbered poker chips to represent the money. Sorry, I'm no artist, you'll just have to use the black and white text cards I was using all along.

That's it. The “production version”. Maybe now our methods are becoming a little better understood. As for my design documents that I write with computer games in mind. I said this to someone in e-mail and realize it's never been said here either...

My philosophy on my version of a computer game design doc. My design documents are designed to make a game the SFB Staff way with a modern game dev team. They are the staff. Your industry begins with what we would call a summary, but that is really all you need for the system you use which is a very valid system for your necessarily different process. My far more complete design documents are not taken to what you call “Beta”, ready for playtest, like my board game docs are. Instead, Pirate Dawn and other computer game design docs are taken to what you call “Alpha”. All of the components are there with their core content, and proven to function. My theory with this has always been that I help your process in doing this (and I did work at GameFX to experience that process). I am simply moving the bar of the starting point. You start with a summary, I start at Alpha... to begin your same exact process of the entire team, just like the SFB staff, continuing to evolve the game from that further ahead starting point. Almost like you normally start at a summary and work from there, where I am practically taking it to Pirate Dawn 1, so the game we end up producing in the end is closer to Pirate Dawn 2 because it was almost as if we already had a game out and are actually re-making it as a second version. Almost, because we started at Alpha instead of with a shipped game. So that has always been my theory behind this type of a design doc for a computer game. It's just a further ahead starting point for your own process.

So, if you are out there as a young person wanting to make games, this is how you do it for real. To experiment. With many types of games, not FPS or RPG or Adventure games for example, but you can make many types of games with these methods. And more than just strategy war games. This is only the beginnings of a tool set. The one I lost was 20 years of accumulation of buying stuff like this when needed. I don't even need anything with numbers on it for this game, so this is a very cheap setup. I really have designed at least 100 strategy games in my lifetime. At least. I often had three going at the same time all over my room to switch back and forth between as I had ideas for them, or they influenced each other!

The thing is, I gather from your posts that you have an approach to creating a "product"(for lack of a better word) that, frankly, *no* industry uses that I'm aware of...books, music, films, games, etc...

That is, I see you believe in a top-down approach, where some "genius" designer writes a huge detailed design document, that is essentially a complete game - from there on it's simply a matter of putting all that into the computer. The game is guaranteed("proved"? how?) to be enjoyable and fun and interesting, because the designer has a "secret formula" that guarantees that.

The thing is, when has that ever worked in *any* entertainment industry? You say, in a deregatory way, that today's game makers are "walking in the dark" and "tweaking" and practicing "trial and error" and such. While that is not completely true - the games *are* designed by dedicated designers that have honed their craft and have their own ideas and principles - in the end, it is true that an iterative and "trial and error" process is used, because, AFAIK, that is used *everywhere*. Musicians write a lot of stuff and see what works and what doesn't. Writers write a lot of stuff and throw away most of it. Directors shoot a lot of stuff and keep what works. The end product is usually not what they had in their mind when they were starting - all sort of real-life factors change it and they simply have to adapt as best as they can. Nobody(or almost nobody, the Mozarts of this world aren't exactly born every year) has everything in their mind(or on paper) perfectly arranged and don't need to see it in motion in order to do corrections. Heck, even the programmers that write the technology behind the game most time don't formally verify their code - and this is something that's actually possible, unlike all the others - I don't think you can ever formally "verify" that a book/movie/song/game will be enganging and interesting. You can only try and see where it gets you. I honestly disagree with this top-down approach on a fundamental level.

This reminds me actually of a scene from "Amadeus" :

Now, I don't know if you are a "Mozart of games", or even if you claim you are, a genius game designer that can put everything on paper and be perfect from the get go, "a game already finished in your head", to paraphrase, but even if you are, it would be unreasonable to expect the entire industry to change its ways around such extremely rare individuals - in the end, checking if Mozart's piece "worked" was easier than producing a multi-million dollar game.

I think that's what most people here mean when they say that implementation is everything - humans just aren't able to 100% assess beforehand how a complicated system will work, and, most of all, if it will result in other people's enjoyment. I see it as kind of ridiculous if one claims they have "verified" that other people will find the product enjoyable. That's why most designers insist that you have to have a playable, working version of your game as soon as possible - to see what works and what doesn't, when, and how. I get an impression that you see that process as "beneath" you - that you can indeed follow a complete top-down approach without having to experiment and tweak with an actual game. The thing is, as I said, it doesn't work with music/books/movies/whatever(without that meaning of course, that there aren't various schools and principles for those artforms and they're all pure magical "inspiration"), I don't see why that would work for games either.

I had just said just about exactly the opposite of all of this in the last paragraph of the post you are replying too. Read the last paragraph again, because it is already most of the response to this.

You don't seem to understand that this is EXACTLY how it was done for many decades before the computer game industry existed. SVC was unique in that industry, almost all games of the board game industry were made in exactly the way that you are saying "cannot be done". That is, in fact, exactly how it was done for more decades than your industry has yet to exist. And it is both an art form and a science. I would think that you would be wondering to yourself if you actually are any kind of expert at this kind of thing if you honestly believe it is "impossible" for a single person to design a game and write complete rules for it. That doesn't even hint to any of you that you may not be as "professional" as you thought you were... Really?

The computer game industry has institutionalized what we called "design by committee". A phrase that translated as "the worst possible way of making a game". "Too many cooks spoil the pot." It is also, very clearly, a "trial and error process". I would think that would be blatantly obvious to all. Another mantra everyone in our industry had heard... "Game design is a benevolent dictatorship, ruled by an Iron Fist". You seem to think these things are a part of my personality or something. These are the philosophies, beliefs, and mantras of the 50 year hobbyist board game industry, not me. You just read my way of "fusing" these two belief systems together. By NOT writing a finished design document, but intentionally leaving it "open" in an "alpha state" so that... So in the end, my process would do it BOTH WAYS. Just like SVC, First the artist does his work, THEN the committee chimes in... after he is done.

Me and a modern dev team could use that "cooperative deign method", that SVC INVENTED and that I WAS AMONG THE FIRST PEOPLE IN THE HISTORY OF THE WORLD to use. Remember, I was a part of the group that INVENTED YOUR METHOD. Believe me, I understand it. I understood it before your industry existed. You seem to be forgetting that. Read the last paragraph of my previous post. That's the "fusion" I came up with, "the best of both worlds" as I see it. And I have just a tiny bit of experience to be making decisions like that.

You also forget that I see your games. I know what you do, how you do it, and the end result. They are in a primitive state. They really are. Forget about us and SFB... go compare ASL to your RTS games... then get back to me about what experts you are, and how we were so wrong in our methods. Really, the arrogance of your industry is without measure.

EDIT: And I just HAVE to add...that part about "getting to a playable game as soon as possible"... Read the part about my "toolset" again. If any of you think you can win that race, I'll be happy to even bet on it. Me, my poker chips, dice, cards, and an Axis & Allies map against your entire team... your code, and your 3D models. I can have a good, functioning game unlike any of my existing design documents in 3 or 4 hours. Does this sound to you like a race that you can win? I really have made more than 100 games in my life... and I am being carefully conservative there. It wouldn't surprise me at all if that number were over 300. Anybody want to race me to a playable game? Our industry was still about twice as old as yours has yet to exist. We had twice the experience you have yet to gain. And it's not just SFB that had USAF Colonels from US space command, a general, scientists, and engineers making them. Over at Avalon Hill... a LOT of those games were made by real world Generals, Admirals, and soldiers who had actually been in wars. We really did know what we were doing.

Let me try an example here as well. By your system when someone says "I have an idea for a game, it's an RTS". Your process then has everyone in the room chiming in about how that RTS will work. So you have already begun to make a "generic RTS". Bland, generic, inevitably a lot like the last few ones that were successful. What happened to the actually specific idea that first person had? It's been forgotten and lost during the very first discussion. The design doc is to present the specifics of that idea, so that the committee can discuss that specific idea... and not just RTS games in general as your method results in. This results in your method evolving at a snail's pace, every idea is immediately made to be like the last few successful games. The person with that original idea, if they actually had a really good idea, was thinking of something fundamentally different than those last few releases... and that was exactly what had made it such a good idea. But you will never even hear it, because your discussion begins with demolishing it right back to a "generic RTS" before the actual good idea is even understood.

Our system "presents innovative new ideas". Your system practically prevents any discussion of them from ever even taking place. This is the very definition of "design by committee" and it is not me or my personality... it is our "belief system" compared to yours. Our way IS better. But SVC's blending of these two ways... NOTHING ELSE COMES ANYWHERE CLOSE TO THAT!!!

And, what was I thinking... I have the perfect response for your Amadeus clip. Here is the hobbyist game industry's response:-)

"Computerized clinic for superior cynics, who dance to a synthetic band,

In their own image their world is fashioned... no wonder they don't understand." - Neil Peart, Natural Science.

:cool:

(paraphrased) I will use a copyrighted map made by someone else, the rights for which are presently held by a company that very recently released a new edition. The type of game that I'm doing is even similarly themed and shares some (many?) of the game mechanics.[/quote]You don't think that this might possibly, just possibly, get a bit troublesome? Maybe you want to read through Tom Sloper's stuff, specifically item number 39. Besides, that kinda contradicts the "can do everything, control everything, know everything" claims you made previoisly, if I'm allowed to say.

You don't seem to understand that this is EXACTLY how it was done for many decades before the computer game industry existed.

Really? Tabletop games just sprang from the minds of the designers, and were immediately fun with no balancing iteration on them whatsoever? I find that difficult to believe.

I would think that you would be wondering to yourself if you actually are any kind of expert at this kind of thing if you honestly believe it is "impossible" for a single person to design a game and write complete rules for it.

Ah, but that's not really what he's saying. mikeman's point appears to be that the production of any kind of interactive media product will involve some amount of "design iteration." Even single-designer products have iteration. Authors don't go to "gold master" (or whatever the literary publishing equivalent term is) with their first draft.

It is rare even for video games made by one person (which are rare in and of themselves because modern video games are sufficiently big and complicated) to be constructed from a single, unchanging design document that is written up front before any sort of production occurs. It is maybe plausible that with a lot of time and work, one could get a tabletop game ruleset right with the first draft. That's completely unbelievable with a video game. There are aspects of the video game experience one cannot anticipate until one actually runs the game as a video game - unless there is nothing original about the game whatsoever, or it's just a video game that implements a board game ruleset that was worked out beforehand. And even then, testers could still have trouble with the game, necessitating changes to the interface (which is as part of the game as its ruleset).

But surely, with the amount of experience you have, you know this already, and all of what mikeman and I are saying isn't necessary except to clarify our intent. :)

EDIT: And I just HAVE to add...that part about "getting to a playable game as soon as possible"... Read the part about my "toolset" again. If any of you think you can win that race, I'll be happy to even bet on it. Me, my poker chips, dice, cards, and an Axis & Allies map against your entire team... your code, and your 3D models. I can have a good, functioning game unlike any of my existing design documents in 3 or 4 hours.

Sure, this is believable. But remember, "making a game" to most people here means production as well as invention. As you know, producing a game is more than just inventing rulesets.

You seem disdainful of video game iteration times, so I guess I won't bother asking if you could produce a functioning video game in 3-4 hours - never mind that on a small scale, people can and do just that in game jams. So:
Can you produce a functioning tabletop game that's production ready (as in, ready to go to the manufacturer, with all artwork, miniature blueprints, and manuals completed) in 3-4 hours?
Can you produce a video or tabletop game that is both fun and unique in 3-4 hours, without any iteration whatsoever?

Getting some random shit together and inventing some rules might be "making a game" on the most literal of levels, but it's not what I think of when I think of "game development." A game at that stage is still in "preproduction."

Samoth... No, that is a prototype. That is how this has been done since the 1950's. If the game were published, obviously it's own map would be made for it at that time. I have a lot of respect for Tom Sloper and have certainly read his site before. My grandfather was a "tough as nails" WWII drill sergeant and I have always loved Tom's "hit them over the head with a hammer and hope they are smart enough to get it" style that reminds me of my grandfather. But I am pretty sure I understand how table top games are made and produced a little better than he does.

Oberon: No, I said writing complete game design documents themselves is how they were made. We had a playtesting phase, sometimes. About half the times we didn't. For example, I could EASILY make a game similar to Axis & Allies that would most likely not be playtested before it was published because that would not be necessary. This was not unusual in our industry, games that simple to the designer making them don't need playtesting. All of the things in it were already playtest... 50-70 years ago. So I guess the answer really is... "Yup, that's how we did it a lot of the times. Because we were 'trained professionals' that knew EXACTLY what we were doing."

For the rest of it, you are simply re-writing what I said. I don't need to respond to any of that, because I would just be pasting and clipping the post you are quoting. What you are replying too is the response, because all you did was re-write what I had said so that you could attack your own words.

EDIT: Oberon... in 3-4 hours I can make something along the lines of MegaSupremacy. Your Civilization is the "next generation" of Axis & Allies. You have since yet to ever even take the next step. In 20 years, Civilization is still the game you make. You should have arrived at MegaSupremacy, the next generation from that (translated to computer game anyway, not the board game itself)... 15-20 years ago. I can do "Big Three Axis & Allies", the next generation of what you know as "Civilization" in about 3 or 4 hours. That game would need playtesting, obviously, but I could have a functioning prototype ready at the starting position in 3 or 4 hours to win that race I had mentioned. If this game were actually going to be made... I would mess with it for another 2 or 3 months. The me and the others that work at the company would play it for weeks tweaking it more. Then it would go out to our "trusted playtesters" (or "staff") both to get their feedback, and ensure that "everything they need to figure out how to play the game is in the box" because "you won't be there when they open the box". The, we would play the "final" version of it ourselves a few times back at the company again... and it would be ready to go. About 6 months after I had finished the prototype.

And for a more simple example of a game going straight to publication with no playtesting, since doing that with Axis & Allies is most definately pretty much an "Avalon Hill or SFB Staff only" type of thing... If you can't send Stratego to straight to the printer, we would say that you are in the wrong line of work.

That doesn't even hint to any of you that you may not be as "professional" as you thought you were... Really?

Just for the record - I'm a programmer, not a game designer, so no, I'm not claiming to be an "expert" or even very knowledgable in game design at all. I have to wear the "designer" hat for my own indie game(which is just a racing game, nothing overly complex) because...I simply can't afford to hire a proper designer. For some reason, you seem to think AAA games are made by programmers and artists alone, which just tweak things until the work. That couldn't be further from the truth - every game company of signficant size has dedicated designers - though their job is a bit more involved and day-to-day managing than simply churning out a 500-page design document and giving it to programmers and artist to "put it into the computer". You might ask, if I'm not a designer, what gives me the impression I can judge how game design works - well, as I said, I'm not aware of this top-down approach working in *any* other art form. But even if I'm mistaken, you jumped right to the gun to come to the conclusion that the "game industry" is not ran by professionals, even though I'm sure I already mentioned I'm a programmer and not designer.

So yeah, since my profession is simply writing the technology and tools that designers will use, and I haven't been fired by the lead programmer yet, I consider myself professional, thankyouverymuch. :P

One side note: Have you ever thought that, even though the videogame industry does has its debts to the tabletop industry, it has its own history now and it makes the games using different methods *for a reason*, and you just don't want to accept those reasons have merit, because you understand tabletop games very well, but not *videogames*? Why are you so focused on the videogame industry anyway? Why not just stick to the tabletop games you know so well? Is it because you think there's not any money in them? What is it?

Interesting description of how the design process for some features of a AAA game went.

Note that user experience features like "feel" and "discoverability" are featured prominently, particularly when it comes to input methods. I have a hard time picturing a 500-page design document having anything more substantative than speculation regarding "feel," even if said speculation was based on prior experience. After all, small details can sometimes have devastating consequences on user experience.

Interesting description of how the design process for some features of a AAA game went.

Note that user experience features like "feel" and "discoverability" are featured prominently, particularly when it comes to input methods. I have a hard time picturing a 500-page design document having anything more substantative than speculation regarding "feel," even if said speculation was based on prior experience. After all, small details can sometimes have devastating consequences on user experience.

This is what I don't get, basically. What you can verify, at the very best case, is whether the ruleset is consistent and results in a non-broken game. I have no idea how a game designer can verify if a game is actually fun and/or enganging for other people, which is the goal here, without seeing it in action with all its myriad moving parts and verifying that it "feels" right. Unless they make an exact "reskinned" clone of an existing game - and even then, they may fail miserably.

Sure, for my racing game, I may have a rule that, when colliding with a wall, a craft loses 15% of its speed and takes 2% damage. That's a rule alright - it doesn't technically break the game and the game is perfectly functional. It also may mean that new players may collide with the walls too much, keep ending up way behind the opponents in the first races, and completely lose interest in the game - so it's a working game alright, except not a fun/enganging one. So, adapting to that, I reduce that value to 10%, and suddenly new players find it easier to play and have fun with it. It's one of those "small details" that can have devestating consequences, and the consequences in a real-time simulation may be heavily dependent to even things such as how many times per second you're running the physics simulation - let alone the friction or collision model you use(or the middleware you licensed uses). It's baffling to me is how can anyone claim that they know that number(5% or 10% or 12.75% speed loss per second of impact/friction) results in the most "fun" gameplay possible *beforehand*, without playing the game and giving it to other people to play and seeing how all the moving parts - the physics model, the enemy AI, the actual tracks, interact with that rule.