In the recent past I had a few discussions about the question whether it makes more sense to write the GDD in a classical Word format or in a Wiki. I have personally worked with both in the past but decided that I prefer a Wiki in nearly all points that matter. In this article I will present to you a bunch of reasons why I think that writing Game Design Documents in Word should be an act of the past.

Maybe I have to define first what I understand as a Game Design Document. For me, a GDD is the one place where you have detailed descriptions about every feature which needs to be implemented by artists, programmers or designers. It is not a document used for external communication, instead its only purpose is for your team to get the information they need to complete their tasks. No marketing stuff, no style guide, no planning and no story script should be in this document. I still recommend Word for fact sheets, pitch docs, high concepts, etc…, but the design document used in the production phase should be in a Wiki.

20 Reasons to use a Wiki

1.     Hey, my table of contents is half as long as my design document!

Do you know the feeling when you open a design document and the first thing you encounter is a five pages long table of contents paired with the thought to close the whole thing as fast as possible? Navigating with long tables of contents is not very comfortable and it gets worse when they have more than three layers. When you work with a Wiki make sure that you have a table on the first side linking to the main feature categories which should be within the first two layers. Take care that no one has to scroll on this page; it should be possible to get an overview with just one look. You can offer a hierarchical index on a different page if you want to show people the structure of your design but they shouldn’t use it for everyday navigation.

2.     Good Morning!

What’s the first thing you do in the morning after you boot up your computer? I bet besides checking your emails you will start your web-browser (and not word). This is the perfect moment for your game design document to say hello. You just have to take care that it is everybody’s start page. Believe that a lot of people will find it very comfortable if your GDD is part of their everyday tool. With Word people have to search for your Word file and start the program (or vice versa) which is not something they necessary have on their morning agenda.

3.     What happened last night?

When you use a wiki, make sure it has a recent change section on the front page. This will make sure that everybody from your team knows first thing in the morning when a feature they’re interested in has changed in your design. It also gives people the opportunity to read other features because it’s just a click away. This will raise their interest in the overall design.

4.     You can’t ignore me

Even when someone ignores the last two points, a good wiki has still the option that people can chooBse to get informed about changes via email or RSS. So there shouldn’t be any excuses left when someone is not up-to-date about a feature he is responsible for. But make sure that you can decide when someone should be informed and don’t use it for every spelling correction or layout change, because otherwise you will just spam their mail accounts and not gain many friends.

5.     Ohh, when did that changed?

A nice thing when working with a wiki is that your changes are tracked automatically and independently for every page and for everyone to see. In a word document it’s easy to overlook a change happened three versions ago.

6.     Ohh, maybe I shouldn’t have written that.

When you notice that the design changes you wrote on the previous night around three o’clock, doesn’t look that fun this morning than this is no problem, if you use a wiki. You can just restore your previous version and still leave all the rest as it is. In word you need to pull your old version from your subversion server and copy&past the changed part if you do not want to lose all your other recent changes.

7.     Links

When you use a wiki, try to put every feature on a single page. This will give your producer or project manager the option to just put the wiki link in a task description or backlog. There shouldn’t be any need for him to copy/past single parts of your design document. This a wiki-only feature because you cannot link to a specific page in a word document.

8.     Who the **** wrote that?

With a wiki, everyone can see who wrote what (or at least the recent changes). In a word document this is nearly impossible, because you would have to update it manually.

9.     Multi-Tabbing

Everybody loves to use multiple tabs in a browser and this is also perfect to work with a wiki. People do not have to scroll from one section to another like they would in word. Make sure that you have a link section on top of every page, linking to parent, children and other relative features. This way a programmer can easily collect all the important information he needs from other features to implement the current one.

10. Size doesn’t matter

When you have a three hundred page fully pictured design document, the file size will be so big that your email account will probably not let it send you or the other one’s account will not accept it.  Even if it works it will consume a lot of time. With a wiki, all you need is to send a single link and a guest account password.

11. My personal gallery

Most Wikis have all the nice thumbnail and gallery features to get a quick overview over a lot of pictures. In a word document you have to create a column of pictures, taking away lot of pages, or scale them down.

12. License to write

Everybody in your company has a web-browser but I guess that’s not the same with the Office pack. A few people will use open source programs like Open Office or just a word viewer but believe me when I tell you that this will lead to some problems. One simple example is that you cannot comment with Word on Word docs exported with Open office.

13. Ahh, there you are

Searching with a wiki is way easier because you get a nice overview of all pages relevant to the search. In a word document you have to jump through all chapters to get the desired information.

14. Too many cooks spoil the broth – Not!

I have to admit that I never worked with a lot of people on one word document but as far as I know there is no easy way (if at all) to do this. I know that there are some new online tools available to allow this but I know that it isn’t a problem at all in a Wiki. With the rising complexity of our games, most projects already need far more than one designer to document all the features and decisions. If more than one guy is writing in your wiki, make sure to have good guidelines and templates to establish a constant layout and style. Also make sure that not everyone of team is adding stuff to your design document, otherwise it can get very chaotic very fast.

15. Working from home

Maybe one of the biggest advantages of a wiki is that it allows people to work from home or when on a journey. This makes it the perfect tool for distributed teams where each team member may work in a different country.

16. Sharing the knowledge

With a wiki you can allow external people to get access to your Wiki without sending them the entire document. It also allows you to restrict their access to special pages and take it away if the relationship ends. You don’t need to send your GDD physically or digitally without having control what happens with it.

17. Works for every team size

Although a word document is mostly enough when you work with a few people on a small project a wiki will grow together with your company. Doesn’t matter if you have 3 people in your team or 50, a wiki will work for every team size.

18. Comments and Discussions

It’s far easier for your team to give you feedback when they have the option to comment your features directly and start a discussion about it without doing it directly in your document. People can also give point out problems concerning the implementation or balancing issues in an early phase of the design.

19. Small looks better than huge

I have experienced it myself and I know that there a few other people who share my opinion that there is a psychological obstacle to work with 300 page-strong documents. In a wiki, you don’t really see the full picture because you explore the design in a different way and you only need to see what’s relevant for you. This makes it much easier to read huge documents.

20. Multimedia

One the best Wiki Features at last. You can use all the nice multimedia features we all love so much. Embed videos or flash games to make your point or integrate your GUI prototype. It’s all there.

As you can see, I am really fan of wiki-based-design docs but I still have some problems when working with a wiki.

What is still missing?

1.     Working with tables

Maybe I just worked with the wrong Wikis but all of them sucked when it came to the point where I wanted to create large tables and work with them. In the end, I always did them in EXCEL and linked the file for Download in the wiki.

2.     Exporting

Exporting the Wiki as PDF or Word was always a total catastrophe. It’s okay if the Publisher is satisfied when you just give him an html export but if they really want to have a document you need to put a lot of effort into creating a nice PDF.

3.     Spelling Correction and usability while writing

All Wikis I worked with didn’t have a good spelling and grammar correction and lacked a lot of usability features I normally use in Word, especially when it comes to auto-formatting via short keys.

4.     Mark Ups

Although it’s not a real problem to work with Mark Ups because they are fairly simple, in the end I don’t really want to work with them and I hope that the WYSIWYG editors will be so good that I never have to format the layout with Mark Ups in the future.

5.     No Sentence-based comments

You cannot comment directly without changing the layout like you can do in word. This should be something I hope more Wikis have in the future.

Some links

In the following you will find a few links on this subject although there aren’t many articles about it on the web.

• http://gamecareerguide.com/features/737/four_ways_to_write_your_design_.php
• http://bbrathwaite.wordpress.com/2008/11/30/creating-a-game-design-document/
• http://www.gameslol.com/2008/12/13/game-design-101-rant-over-reliance-on-documentation/
• http://www.gamasutra.com/view/feature/4094/learning_the_ways_of_the_game_.php?page=1

Conclusion

I hope you can understand now why I prefer Wikis over Word GDDs and maybe you will choose a Wiki now for your own project. I would really be interested in your experience with a Wiki. Do you agree with most of the points or are there some things which really speak against using a Wiki? What Wikis did you use? Do you think that there are any other valuable alternatives to a Wiki except of Word? I heard a few people try to write their design documents in a blog or use google docs. Do you have any experience with that? Let me know!

I added a research section. On this page I will collect all links relevant to rational game design. If you have some links I missed or if you think that some links on the page are bullshit than email me or leave a comment.

Hi and welcome to the second part of “Weapon Balancing based on on Gameplay Situations” series. If you missed the first part you can find it here. (I also updated the resource list). In the last part I described that weapon balancing can be divided in eight single steps. The first step I took was to define my weapon system. The main questions were the restrictions I want to have in terms of number of weapons the player can carry and the way he will get new weapons and ammunition. The second step I described concerned my balancing goals, focusing on the domination of weapons and their different use for different situations. Let’s continue with the third step.

Third Step: Define your weapons attributes

In this step I will define which properties my weapons should have. I this is one the most important steps, because it will determine the grad of realism and skills needed by the player to handle the weapons. It is also the base for all further balancing because if I don’t know the attributes of my weapons I don’t have any values I can balance.

The following list will describe the attributes I chose, what they mean for the gameplay and why I chose them. It is important to note that this list is based on a personal concept for a shooter which is set in a realistic scenario.

Damage per Projectile

This value defines how much Health points one projectile will subtract from the health of an enemy. This is a fix value. You’ll properly ask how different body parts will affect the end-damage. My Hit-zone-system is currently divided into different body zones and each body zone will automatically add a percental value of the current enemy’s health to the damage. So if the player makes a heat shot hundred percent of the current health will be added to the damage, so that the enemy is dead. If the player hits the lower leg, only 15 percent of the current health will be added to the damage. So the overall damage is damage/per projectile + percental damage/body zone.

Rate of fire

How many projectiles/per minute. This value affects if the weapon is suitable in situations against larger groups of enemies because you can spread the damage, a weapon with a higher shoot frequency requests lower aiming skills and the less bullets per minute the more time the player will spend defenseless which makes it hard to use in situations where the player will be under attack. It also determines if a weapon is still useful despite a very low base damage.

Magazine Capacity

Affects how many projectiles the weapon can shoot till the player needs to reload. The smaller the magazine capacity the more often the player is defenseless.

Reload time

How many seconds a weapon needs to reload. This is important because it defines the time the player is defenseless and needs to take cover, start bunny hoping, changing the weapon, hide, run, etc.

Velocity

This defines the speed of the projectile when it leaves the barrel. The higher the velocity the less skill is needed to successfully hit the enemy, because you don’t need to project the current location of the enemy into the future based on his current movement speed.

Velocity loss per second

This defines if you’re weapon has a ballistic flight path or if the bullet just flies straight. If you want to have an ultra-realistic weapon system you will have a velocity loss per second for every weapon to simulate friction. I personally think this only makes sense if you create games solely for people who have a solid sniper-training. If you want to have a bigger audience for you game only weapons like grenade launchers or throwing weapons in general should have a value above cero. These weapons will have the advantage that players can use them to attack enemies hiding behind cover.

Damage loss per second

This defines how much damage a projectile will lose over time. I know that this sounds like a very realistic approach which simulates that projectiles with less speed also deal less damage but the reason I chose this value is to have another tool at hand to make weapons like pistols stronger in close combat situations by giving them a high base damage but also a high damage-loss/per second but other weapons stronger over long-distance combats.

Area of effect

This determines if a single projectile deals damage over a larger area or not. The larger the area of effect (like explosions) the more effective is a weapon against groups of enemies and the less precise the player needs to aim to hit enemies. But is also makes a weapon inefficient in close combat situations if the player can deal damage to himself. (Bioshock took this feature and used it for weapon upgrades)

Bullets per shoot

This defines how many bullets the weapon will shoot simultaneously with one pull of the trigger. Besides increasing the damage per shoot, this value is important in combination with the spreading. (Shoot gun)

Accuracy

This value determines how strong a bullet will differ from the point the player will aim at. This value highly determines how useful a weapon will be over distance. A large spreading makes precise aiming at enemies nearly impossible but in combination with a large number of bullets per shoot it can be used against close moving enemies because the probability to miss them will be strongly decreased and it also allows to hit more enemies at once. Spreading can also be an exponential value. I also think that the spreading of a weapon should be feedbacked via the size of the aiming cross.

Vigorous effect

I called this value vigorous effect and what I mean is the physical reaction of the enemy when he is hit by the bullet. A weapon with a low vigorous effect will only cause a slight hurt animation and weapon with a strong effect will cause a large recoil or at least a stronger physical reaction. This value is especially important in large group combats because it allows the player to temporarily immobilize an enemy and focus on the next one.

Recoil

How strong the aiming cross will move per shoot. This value can either be linear or exponential. It is one the attributes which will determine how much skill the player needs to handle the weapon because he needs to readjust his aiming. Because my concept focuses mainly on a single player game this value shouldn’t be too high for a single weapon. My goal is that the player chooses a weapon because it is the most effective one for the situation and not because it can be easily handled.

Special attributes

I also have some special attributes like the ability to zoom with a weapon, penetrating bullets or the sound intensity.

There are also some values I did not choose for my list.

Weight

My weapons have no different weight and do affect the movement speed of the avatar. I know that it would be realistic but I don’t think that movement should be part of the balancing. My aim is that the movement of the avatar feels responsive and has a good pacing and I feel that constant speed is important to keep the player in the flow. I don’t want to use it to balance my weapons. It’s hard enough to create a good pacing without this additional burden.

Maximum ammunition

My weapons have no ammunition cap so the player can collect as much ammunition for a weapon as he likes. This has two reasons. I think ammunition is an important short-term reward and is provided when the player overcomes a challenge. If you cannot collect the ammunition you have no reward, but rewards are what keeps us going. The second reason is that I don’t want to force the player to use a different weapon because he is out of ammo which maybe is not effective for the current gameplay situation.

Responsiveness

I also don’t include responsiveness into my balancing values which means the time between the player’s input and the shot. The reason for this is the same as the reason I didn’t include weight. If the responsiveness of a weapon is bad, it doesn’t matter how useful it might be on paper in special situations, it will just be no fun to use it. So my aim is that each weapon is responsive and the time between input and reaction should be as low as possible.

As you can see this list only contains very basic values. This is caused by the setting which determines the borders of realism I can move within with my design. If the game would take place in more fictional setting I could add a lot of properties like damage over time, stun or maybe the ability to draw health from enemies. All this would add a variety to the gameplay and the possibility to make the weapons more different so they would be more useful in special situations but I would destroy the suspense of disbelief.

In the next step I will set up a system to classify our gameplay situations but this will be part of the next article.

I would like to hear your opinion on these attributes. Do you think I missed any important values or are some values unnecessary? Do agree with the impact each value has on the gameplay or do you think there are more or less situations where an attribute plays an important role. I would also be interested in your experience. Did you use different attributes in your games? I hope you liked the second part of this series If not feel free to say what you dislike and if you did, I am always happy for some friendly words.

This is going to be the first post in a longer series of articles I want to write about the balancing of weapons in shooters via gameplay situations. I was rather frustrated about the lack of information I found about this topic, may it be balancing at large or the balancing of weapons specifically, so I thought it could be a good idea to write some of my thoughts and approaches here and maybe create a forum for a more detailed discussion and exchange on this matter.

Let me start with a short list of the most interesting resources I found on the web:

Dave Sirlin on Balancing Multiplayer Games.

Dave Sirlin, game designer of Streetfighter 2 Turbo HD Remix, has written a very deep and interesting four part series on the matter of balancing multiplayer games and I am seriously thinking about getting his book.

Part one: Definitions, Part two: Viable Options, Part three: Fairness, Part four: Intuition, Overview (Handout, PDF)

Brandes Stoddard on Balancing Weapons

Brandes Stoddard is System Designer for the upcoming MMOFPS Fallen Earth and shares some of his experience in this Dev. Journal.

Part one, Part two

Eric Heimburg on Balancing for Awesome

Eric Heimburg wrote an article called Balancing for Awesome describing the problems of system design and why you should try to balance for awesome and not for the sake of your excel sheet.

Tom Cadwell on Techniques for Achieving Play Balance

Tom Cadwell was apparently working for Blizzard on WC3 and WOW and has written a good article on balancing.

Techniques for Achieving Play Balance

Brian Reynolds on “The Poor Get Richer: The Ancient Art of Game Balance”

Brian Reynolds, former CEO of BigHugeGames and currently Chief Designer of Zynga, talks about balancing but focuses more on the long-term experience and multiplayer aspects. But it is a good source if you want to define youre balancing goals.

The Poor Get Richer: The Ancient Art of Game Balance

Wolfire Games on Game Theory Applied To Game Design

Game Balancing based on game theory. Very Interesting, especially for all people who design strategy games.

Game Theory Applied To Game Design

If you know some other good resources please tell me and I will update the list. But for now let’s continue with the approach of balancing weapons via gameplay situations. First I think you can split the way to balance weapons into eight single steps.

First Step: Define your weapon system.

This is the first step you have to make. How should the weapon system work? The most important question is the limitation of weapons a single player can carry. Can he carry all weapons at the same time like in a classical shooter (Half-Life, Unreal Tournament, etc.) or is the number of weapon slots limited like in most modern shooters? (Gears of war, Dead Space, Resident Evil 5) This will determine how valuable a single weapon should be and in how many gameplay situations one weapons must be useful.

If the player can carry all weapons, each weapon can have a single purpose because the player can switch between weapons and adjust his equipped cannon to the specific situation. If you’re weapon system is limited either by the number of slots, inventory space or weight than each weapon must be more useful in different situations because you want to avoid that the player can’t overcome an obstacle because he hasn’t chosen the right equipment. (Even if you provide the right weapon in front of the challenge, a player could still decide to go with his old armory because he invested too much money in upgrades or simply because he likes them)

Another important point is the way player gain new weapons and ammunition. Do you have a shop system, a weapon upgrade system or does the player need to search rooms and loot corpses? There are a lot of different options to choose from and I think the decision depends on the way you want to reward the player and the restrictions of your game world. (A shop system in a WW2 shooter can easily break the immersion of a game)

Second Step: Define your goals

The next step I took was to define my balancing goals. An important matter for me is that I don’t want to have a dominating weapon, meaning a weapon which is better than all the others in every situation and I also want to avoid dominated weapons, which are worse in all situations than at least one other weapon. Based on this system I think you can create two categories of weapons. The first category I called special weapons, which are the best in at least one situation but also the worst in others. The second one I defined as mixed weapons, which are good in a lot of situations but also crap in others. When you think in these categories all weapons should be useful in the game but in different situations, challenging the player to choose the best weapon for each situation and by this creating depth to the gameplay because you cannot just rush with the weapon of your choice through the game.

The next point I would describe as aiming for maximum difference. The player should really feel that each weapon feels and behaves differently. This means that the differences between the ingame values should not be in a small percentage area because than the player will not notice them.

I also decided that I want to balance my weapons internally, which means for me that the balancing is not based on global variables set by the level design a.k.a. the ammunition available. A lot of games feature dominated weapons but force the player to use them because the ammunition he finds for better weapons is rather spare which sometimes work in survival horror games but I personally think it limits my choices as a player and takes away room for interesting decisions.

I also want that all weapons should work the same in multiplayer and singleplayer modes, because I think the system gets intransparent for the player if weapons behave differently in each mode.

Third Step: Define your weapons’ attributes

In the next step one should make a list of all attributes concerning the behavior of weapons. I will write more about this step in the next part.

just wanted to tell you that Nico Grupp’s presentation is online at the session page of the GameCamp. The presentation is called Balancing in Strategiespielen (mit Methoden der Spieltheorie) and is very interesting for everyone who is concerned with the problems of balancing, either in RTS games or in general. For more information on the content of the presentation read my last post.

Yesterday I spent my time at the GameCamp in Munich, the first BarCamp I ever visited and the first time ever that Microsoft opened it’s gates, because the whole event took place in the Microsoft headquarter in Munich (or better Unterschleißheim), which is a cool location to talk about games.

At first I feared that it will be a waste of time, because a BarCamp has no planned program, instead all sessions are decided in the morning together with all attendees, which I thought could be a bit tricky. But I must say that I was rather impressed by the quality of the lectures, at least the three ones I saw.

First Session: Charaktergetriebenes Geschichtenerzählen in konvergenten Medienwelten by Benjamin Feld.

The first lecture I saw was by Benjamin Feld, who talked about character-driven storytelling in convergent media worlds. Benjamin is a local producer and founder of Synergetic Crossmedia Concepts.

Starting with a general talk about convergence leading to the insight that games take a special position, because they are the intersection between all mediums, Benjamin came to point which interested me most, namely how a convergence of media affects the role of characters in games.

Benjamin said that characters need to be interesting on the one hand, because only interesting characters can create a platform for identification and identification with the character is needed to create emotions, which is true for all mediums. On the other hand a character needs a recognition value, which works on three layers. A character can be recognizable by its visual design, by the way its acts or on a psychological layer.

If you have a look at all the different forms of media you see that games have a trend to create characters which are strong on a visual basis (Kratos, Mario, Lara Croft, etc.), movies are king when it comes to action (WallE is a perfect example) and literature can create the most psychological deep characters (Faust, Hamlet, Dorian Grey). Special cases are comics, where we find characters that are rich on all three layers.

When we try to convert characters from one medium into another we will soon stumble upon some problems, because most game characters are not psychological deep enough to work in movies or literature, whereby characters in literature are mostly visually not appealing enough to work in games or movies.

To solve this problem Benjamin proposed a “Iconography of Things”, meaning that we should equip our characters or the world they live in with recognizable elements which work in every medium, like the hat and whip of Indiana Jones or Sherlock Holmes’ famous pipe.

I personally agree with Benjamin that a good story is driven by its characters, but I think that creating characters for game are a special case and primarily shouldn’t be designed with other medias in the back of one’s mind, because characters in games need not only be interesting but they must be designed in a way that the avatar’s motivation of acting within the game world is the same as the player’s. Only when the motivation of the avatar and player are correspondent will the player be able to fully fall into the story and emphasize with its characters. I think that’s the key to good characters in games. But nevertheless is the Iconography of Things a good way to enrich your character and increase its recognition value.

Second Session: Balancing von Strategiespielen (Spieltheoretische Ansätze) by Nico Grupp

Nico Grupp is student at the LMU in Munich and talked about the balancing of strategy games with a approach based on the game theory. He chose this subject for his degree dissertation so he was rather well prepared.

First he defined what it means for a game to be fair and I think his definition is very good because he said that in theory a perfectly balanced game, played flawlessly by players with the same skill, should go on till all eternity.

The easiest way to achieve this is a by a symmetrical game design, meaning that the both player have the exact same start resources and units on symmetrical map. But, and I fully agree with him, this is just plain boring in most games and the goal of good game design is an asymmetrical design which is still balanced so that players have the same chance to win the game although they play with different units.

He also said a game designer should avoid dominant strategy, meaning a way to play which is better than all other ways, or a dominated strategy, which is worse than all other strategies. He also explained the difference between strict dominance, when a unit is better than another unit in every case, and weak dominance, when a unit is only better in one case but still equal in all other cased. He also explained the fragmentation formula, which describes that a player should always choose a single unit over two units, even when they have the same values.

Nico explained that he came up with a way to balance a strategy game on paper, based on the insight that you can estimate the outgoing of a fight when you know the system it is based on. Nico’s idea is to balance a strategy game by estimating the choices the player’s have at each moment and the outcome of their battles, whereby each a battle is a sub-system in a decision-tree.

I have some personal experience with a similar approach I used to balance my student game Dawn of Bugs and I think it is a lot of work to find good balancing values. I also think that you can use such a system only to get a good start but it will never fully replace a long testing phase. Another point is that the time is takes to create a table to fully balance the game based on the estimation of sub-systems takes nearly as much time as testing. But I also know that Nico’s approach can discover a lot of conceptual mistakes before time is wasted to implement them. I am curious about the outcome of his dissertation and hope that maybe he will present them next year.

Third Session: Start-Up experience by a browser game company.

The third session was by a small browser-based company who successfully survived their first year in the business. For me the most interesting facts were that they get ninety percent of their players through mouth to mouth propaganda and only 5-10 percent of their income is generated via advertisement, the rest via micro-transactions and premium features. They also stated that 20 percent of their players use premium features which is rather much. Another important point was that they do not have any exclusive premium content and warned exclusive content would rather be a bad deal because they would lose more money by players leaving the game than gaining money from players who would buy the exclusive content.

Summary

Although I did not participated the second day, because my head felt rather large this morning due to the long evening at the aftershow party, I think that the GamesCamp was a good experience and I hope they will do it again next year because after yesterday I lost my fear of BarCamps.