Philosophical Game Design. And Raptors.

Presentation finished, Demo - nearly!

2011-11-11T22:33:00.000-08:00

Okay, Presentation is done - read it here:

https://docs.google.com/present/edit?id=0AWu12LJfJsACZGM3bmgycV8wc2dkNTh2aGs&hl=en_US

Demo's showing off most of what I need, but can still be improved in a few ways!

Off to Melb soon!

Research Project Update

2011-10-28T17:19:00.000-07:00

I have been working on my Research Project more and more recently - though with job applications and Clo wrapping up it's been hard.

I have started writing up my final presentation and once it's done, and I know exactly what I want to show with my project - I will start really focusing my project towards that. Not to say that I'm going to be delaying work on the project in favour of the presentation.

Topics I want to cover in my Presentation:

Behaviour Trees vs. Scripting

Pros and Cons of BTs

Creating tools to aid the creation of BTs. (Tool Investment vs. Ease of Use)

Optimising BTs (esp. with multiple entities using the same BT)

Interesting BT uses. (Genetic BTs)

Conclusion

So yeah, going through and writing that now!

Research Project Update

2011-09-18T16:22:00.000-07:00

Hey guys, update on my research project.

I had a big break from it - mainly because I was focusing on the group project (too much, perhaps) - but, it has come to the time when I should have started really digging in a month ago, so I'm still, as always, behind.

I started looking over my project again about 2 weeks ago - looking at areas where I could improve, and the implementation I have now is not very good.

The choices that leaders and people seem to make almost seem random because of the ridiculous number of factors I've implemented (usually only affecting one-off choices too...) - and so it doesn't really seem like there's much AI at all - there's no cohesion.

Similarly, many interactions within the game don't make sense, for example, when a natural disaster strikes, it cuts off Tech Trees at a random point in the city's investment - wiping out not only say, road infrastructure that makes sense, but... also potentially the civilisation's knowledge of making musical instruments.

Similarly the code is starting to get bloated with poor planning and one-off variables and functions that don't do much. It's getting hard to expand upon.

So I guess what I'm trying to say is that my current project is stupid because I rushed in, just trying to get the programming done - rather than properly designing the system and the data/choice interactions... which frankly, if you're coding AI - seems really obvious. My bad.

So, I'm going to be redesigning my AI system from the group up - paying particular attention to all the relationships and the effects of choices like I should have been. Similarly, I will design my rulesets now as well, ensuring that every variable in each AI entity has a significant purpose. If I want to code in intricacies, I can do that when I'm done.

Similarly I'm thinking of coding a program to create Behavioural Trees. For example, a simple drag and drop interface and such. While this might be a risky detour, it could potentially benefit me a lot in the long run.

So, see how that goes!

Clo Prototype is finished!

2011-08-05T06:50:00.000-07:00

Hey guys, remember that not-very-fun Clo prototype?

Well, we spiced it up a bit!

Play it here:

There are 3 resolutions to choose from, you'll need the Unity player.

http://edibleweapon.wordpress.com/protoypes/

I am the Lead Designer from this project - most notably, I designed a couple of the levels and mechanics, as well as making design decisions (or at least bringing them to the attention of the group. I like to make sure everyone has their input.)

As we develop the game (now that we're done prototyping), I will be designing far more levels, and hopefully bringing some more mechanics to the table - to ensure that the gameplay experience is exciting, and frankly amazing.

Have fun! I hope you like it!

Update on... me!

2011-07-17T05:33:00.000-07:00

What's up guys?!

I just want to update you on what's happening with me and my video game designing and such and such.

Currently I am in a bit of a high work period.

I have the programming task which has been in my recent updates, which I'm still behind on. I'm going to try to dedicate 2 days a week to it until it's due. That should catch me up.

Clo

I am mainly focusing on a group project for college - where the project is to make a complete game. My group's game is called "Clo". It's a puzzle platforming game based on the idea of changing the seasons around you to manipulate puzzles within a level.

We ended up with this as our final prototype that we submitted to the industry:

http://www.mediafire.com/?7odlo2ka4ew59al (Also included is our pitch presentation)

We went in with high hopes as the teachers and students seemed to like it, but, it didn't actually perform so well. The judges did not think that the prototype was fun - but, those are the breaks!

Their main suggestion for improving it was "Add more mechanics" - which we were planning to do anyway, so it wasn't so bad!

Either way, we're still struggling through the prototype. During the holidays, the group programmers did a substantial amount of work, now it's just down to finishing it up, and resubmitting the prototype this week.

Hopefully it does well this time!

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

Captain Catnip and Challenges

I have found I am starting to enjoy prototyping and implementation more than typing up long hypotheticals on game design.

It is much more effective to code up a mechanic, and test it - rather than typing up how you hope it will work, and then finding it doesn't.

Plus, it's something you can really show people, and it makes me feel happy because I am programming. I enjoy both programming AND design - I don't like to focus on just one.

Anyway, each week I try to set myself a design and/or programming challenge - a few weeks ago I made the game "Captain Catnip" - it was a 7 hour, 40 minute prototype made by just me - and it was mainly made to see how fast I could code a game in Unity, rather than as a big design show-off.

That said, it does give some insights into design - such as, why boids need a lot of work to be a fun game mechanic - and not just something pretty to watch.

Here's Captain Catnip. Copyright blah blah.

http://www.mediafire.com/?w4v80757boi4h77

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

Digital Alchemy

My project for this last week of the holidays (as said, I spent the first week focusing on our prototype), has been to make a Forum Adventure game. I am making it with a friend from my high school, another aspiring game designer.

Forum Adventures require no programming, and are mainly a design exercise. Also heavy on writing.

In fact, the first games I ever made were forum adventures, so this is a nice "back to my roots" exercise.

Forum Adventures are a fun genre as they are limitless - you give players the situation, and players say what they want the characters to do. Players generate their own content, and running these is an amazing way to study players and how they wish to interact with the environments presented to them.

Click here to check our Forum Adventure named "Digital Alchemy".

http://pokemon-universe.com/index.php/topic,3311.0.html

My forum name is Level5Pidgey, and my friend (Shadowfred) helps out mainly with pictures and behind the scenes as we decide the plot and what happens to the player.

It starts slow, but, the most recent part of the story details the main backstory to the game, and one of the main mechanics which is crafting. Upcoming are stats, and battles.

So far the whole experience has been great - as said, studying players!

The biggest thing I've noticed are that, you can lead a horse to water, but you can't make it drink.

I used to operate under the idea that, if you subtly hint to a player what they should do - they will probably get the idea and take your bait, while not feeling forced into it - but, as I have found, sometimes they just want to pick up heart rate monitors and smack guards around with them.

As said, I'm learning a lot about players - and something I really want to try to work out, is a solid method for both offering players as much control over the game as possible - while still telling a linear story that you set out.

Will be interesting.

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

Pokemon Universe Balance

Pokemon Universe is going great on the balance side. We have set up a testing server for members to test on, and they seem to be having fun with the balanced Pokemon metagame.

We seem to be 40% of the way through, so, cool!

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

Game Design Pitch - A History of Asskicking

I held another AIE Game Design Comp - and I submitted this game idea.

I hope you like it.

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

Challenges

Anyway, so, I will leave you with a list of challenges I wish to carry out in the future:

- Make an RTS in one day.

- Make an Escape-The-Room game in one day.

- Make a Single-Button game in one day. (Bring it on, Tiny Wings)

- Try to make a fighting game in one day.

These challenges are meant to challenge me design-wise, and programming-wise. So, I'm sure I will fail a couple of these, and many challenges I set for myself in the future. But that's okay, because I'll be learning from my mistakes and successes all the way.

If you have any suggestions for challenges, send a message or leave a comment.

Still behind on my research task.

2011-06-20T22:49:00.001-07:00

Okay, it's been another month, and I'm still implementing the core framework for my research task.

I can't say I'm proud of that.

That said, I'm really starting to make progress - I've started working (as in, occupation) less, so I have more days free to program, and my progress is much faster than what it was a month ago when I was working 3 days a week, at AIE another 3, and I just wanted to have fun on the last day.

The progress I'm making on the task is also becoming more and more fun, so, I'm enjoying the programming more than when I was just starting out.

So, hopefully it's full steam ahead from here.

Update on Programming Research Task

2011-05-20T16:45:00.000-07:00

I haven't started implementing much of the framework for my research task, which is a problem since I did plan to have it done for the 25th (4 days).

So, I'm a little behind.

What I have done however, is implemented A* - which will be useful for Tree navigation, and I've started researching heuristics for specifically trying to take into account how likely it is for a research to lead to other research paths down the track.

So, if a political goal was researching C, and further down the line they wanted to also research D - they might take research A, which leads to both - rather than B which reaches C quicker, but now not lead to D.

I am programming this task in C# - because it is extremely quick to get off the ground. I already have a simple GUI going, with inputs.

The only issue is that it is slower than C++ - so, my efficiency calculations will have to consider this. It is possible that as C# and C++ are pretty similar, I could try to quickly port the code over, and test it on C++ as well.

I am using XML for the research trees - and loading in of other data items, for example, "Area" templates which define temperature ranges, local materials and such which define the initial products that a civilisation can create (such as rice, fruits, and metals).

While, again, XML is slow, it only really needs to be loaded in at the start of the application for skill trees, and, depending on whether I allow the saving and loading of past simulations, they can be accessed on the menu screen when selected.

On the plus side, XML is very quick and comprehensive to edit.

To make up for the time I've lost, I'm going to implement a very basic skill tree, and expand it as I go.

This blog will be home to my major research project.

2011-04-18T17:40:00.000-07:00

It totally will.

So... ummm... this is late!

2011-04-18T16:32:00.000-07:00

Hey guys!

The Game Design comp finished a week ago - and, so, here are the entries!

Tales of Berefriszia: The Knighting of Delacroix

By Wafik Salim

Impending Ascension

by Matt Jones

PROJECT neverWAKE

by Raymund Serrano (This one had to be cut down for submission)

A.N.T.agonist

by Adam Taubert

Cyberelm

By Greg Lennard

Zombie Hallway Dash

By Justine Colla

Sloth

By MEEEEEEEEEEEEE! (Zanda Cetinski)

Project: Element

By Sean Evans

Chino

By Josh Dobson

Dropper

By Adam Vieira

Watch them all, they're all awesome!

Best College Ever?

2011-03-24T03:23:00.000-07:00

Today, the head of my college campus help a PSP box just outside my room, and motioned towards a poster I had up saying "First prize?".

Yes, that's right guys, AIE Sydney has officially donated a PSP to the competition as first prize!

That should certainly motivate people!

Thanks to Neil and the other staff at the AIE for spicing up my poor-college-student prizes with something much more awesome!

Metaphor for Skill vs. Imbalance.

2011-03-19T05:39:00.000-07:00

Introduction

Do you ever find yourself arguing over balance on forums?

Damn right you do - or at least I do occasionally.

One thing I find in every single gaming community is that many people (new to the game and experienced alike) don't understand that when discussing balance, you must eliminate skill as a variable.

Hence, most discussions are like so:

"X is too powerful"

"Just use [unreliable attack] to kill him!"
"But that assumes he just stands there and lets you use it!"

In this situation, someone defends a unit by assuming a player of low skill is playing it.

Or
"X is too powerful"
"I find it to be balanced as when I'm playing, other people kill me with [unreliable attack] all the time!"

"That attack is easy to counter if you are aware of your surroundings, though."

In this situation, people often degrade their own skills, or give examples of extremely strong opponents to defend the unit.

Obviously, all of this argument is invalid, because, your test subjects should be at an equal skill level, or, as I posted in a previous article ( http://zandagamedesign.blogspot.com/2010/02/skill-ceilings-and-floors.html ) - they should be at the skill ceiling of their respective units to accurately judge absolute potential.

Anyway, I'm not going to dive into all that and restate everything - this article is made so that, if you ever do need to explain to a person how skill relates to a unit's potential, you can just refer them to this article.

On with the Metaphor!

To balance two units, you MUST measure their potential at their skill ceiling (or peak human skill if the skill ceiling is higher than the limits of human qualities).

To demonstrate this, I will be discussing the fine art of carpentry.

Firstly, imagine that instead of complex characters, the units in your game are simple tools, that you as a player, utilise to win the game.

This is exactly what they are. You unit in a game is a tool. Nothing more.

So, let's say we have two Hammers, the "Craptacular Nailpusher 101" and the "Super-Gold-Hammer Deluxe 5000". We'll assume that, as their names suggest, the 5000 model is far superior to the 101.

Let's say that "Balanced Hammer Co." wants to measure up the hammers against each other - as they are unsure of whether the Deluxe model really is any better.

So, they pick two carpenters from the local area, Tom and Dave to test out the hammers.

The thing is, Tom has been hammering for an odd 20 years now, and specialises with his Nailpusher 101, while Dave is completely new to the trade, and was frankly dropped a few too many times on his head while he was a baby.

The test begins, and Tom immediately takes the lead. He finishes the task deftly and with prowess, while Dave manages to hit himself in the face more than the nails he's supposed to be hammering.

The company records these findings, but obviously note that Dave was a really bad test subject, and so they discard the reports.

To relate this back to balance briefly, this shows that just because a unit is overpowered, it does not necessarily mean that new and unskilled players will immediately dominate skilled players with it. Even in unbalanced scenarios, a wide skill gap will still favour the more skilled player.

If it doesn't, then the balance issue should be so plainly obvious, it would have to be intentional.

So, back to the hammers.

Balanced Hammer Co. goes back to the drawing board.

What could they possibly use to test the hammers?

They search around, and find another carpenter - Adam, who has the same degree in hammery as Tom, and has been hammering for exactly the same number of days as Tom.

As far we can tell, Tom and Adam are both skilled at carpentry, and they are both about equal in terms of skill.

So, the competition starts off again, and, Tom, who now gets to try out the 5000 model, wins by a mere nail.

The company takes the results, and concludes that their new hammer isn't worth the 200% markup over the 101 model, and agrees that they must add more and more features to the 5000 model.

Seeing as Tom has been a willing participant in two tests, the company give him a free 5000 model as thanks - and guarantee him a discount on the model when they finish superpowering it.

So, Tom goes home, and, decides to use the hammer full time. It did win the competition, so why not?

Anyway, 3 weeks later, he's hammering some nails when he realises that on this particular model, the handle has a flat base that, on every 3rd swing, can be used to strike nails harder than usual.

Conducting his own test, he decides that this feature should be raised with the Hammer Co. company, to help them with their designs.

What does this show us?

Just because players aren't currently bunnyhopping with the Sniper class, headshotting every player they encounter with quickscoping, doesn't mean that the unit cannot do it. Players will often gain more and more skill until a large portion of a unit's potential is realised.

When judging balance, you cannot just use "good" players, you must go further, you must evaluate the unit's absolute potential.

Back to hammers.

So, Balanced Hammer Co. take this last lesson in their stride, but unfortunately they're still unsure of how they can measure up the two hammers.

But, one of their engineers has been doing some searching, and he finds the contact details of a couple of Romanian Hammer Brothers who are said to have such amazing skill in carpentry that they can immediately take one look at a hammer, work out every single trick with it, and utilise the hammer and all its features to a near perfect degree. The degree at which they can utilise these hammers is at the absolute limit of human hammering ability.

So, the company flies them in, and hands them each hammer.

The brothers take a quick moment to analyse the hammers, and the competition begins.

The result is that the brother with the Deluxe Super-Gold-Hammer 5000 wins by a land slide. He found many more tricks to this new hammer, than the other brother could find with the older one due to the new design's slick form, useful handle, and other features.

The brothers were completely equal in skill - and both were at the peak of human skill in hammering terms - so what happened?

As we started at the beginning, the Deluxe Hammer was simply better.

If we liken this to games, you can have a player at the skill ceiling of a Machine Gun class - but, if the machine gun class only deals 2 damage per second, while the others deal 100 damage per second, all that skill does not matter. The class is inferior to the others.

Conclusion

So, Balanced Hammer Co. choose these results over all others - why?

We are not comparing a bad player to a good player.
We are not comparing two equal players, that cannot utilise their units properly yet.

We are comparing two players, who use the units to their full (human) potential - and they demonstrate how powerful the units really are in comparison to each other.

This is how you evaluate balance.

I hope everyone enjoyed this post, and I want to try to follow this up with more skill vs. balance articles really soon.

AIE Sydney Game Design Competition!

2011-03-18T22:09:00.000-07:00

Okay guys, I've been talking about this for the last year or so, but I've decided to finally get off my butt and set it all up.

Not all details are finalised, I'm just putting this up now so that everyone can get started.

In the spirit of the competition, I've decided to lay this info out as its own game pitch.

So, let's get started:

AIE Sydney Game Design Competition

Basic Concept:

Participants must submit a video pitch for a video game idea to be judged.

The video should be of 3 minutes or under in length.

The design can be any original design, for any style of video game.

The video should detail the concepts of the game, its tone, its gameplay, and etc.

The competition ends on 3/4/11.

The winners will be announced on (to be decided)

Gameplay (Specifics):

Information and updates on the competition will be displayed in my statuses, notes, and on my blog. (link below)

This competition is only for AIE Sydney students (first and second year)

No implementation is required, and any additional material will not be considered during judging.

Any video style is fine, whether it's full video, audio over animation, or a simple powerpoint.

Submission:

Videos must be uploaded to Youtube.

When the video is uploaded, post the link to my wall, or email it to alexander.cetinski@gmail.com

Submissions close on 3/4/11.

I will showcase submissions on my blog, and on my wall.

You can only submit one entry.

Multiple people can work on the same video, but the prizes are not negotiable or multipliable.

Submissions > 3:10 mins will be rejected. The extra :10 is to protect against youtube length issues.

Please include your year in the video description.

Win Conditions:

The competition will be judged by our amazing and wonderful game teachers - Conan, Dan, Epona, Matt and Mike.

The Judging Criteria Are:

- Concept

- Gameplay

- Fun Value

- Sellability

You will get a rating out of 10 for each criteria, which is averaged for your final score for that judge. Then the final scores are averaged for your over all mark.

Rewards:

Overall Awards

1st Prize: "Game Development Essentials: Gameplay Mechanics” - http://www.amazon.com/Game-Development-Essentials-Gameplay-Mechanics/dp/1418052698

2nd Prize: $25 in Steam games

3rd Prize: $15 in Steam games

Prizes are not negotiable or multipied for group submissions.

Year Specific Awards

First, Second, and Third Best Submissions will be announced for each year.

There are no year specific prizes however.

Additional Awards:

Best Original Protagonist

Best Original Antagonist

Best Game World Concept

Best Tone (Comedic, Suspenceful, Dramatic, etc.)

Joke Awards:

Most Likely to get Cease + Desist’d by Nintendo.

Most Likely to get a terrible movie adaption.

Most likely to require a Valve-Time release date.

Most likely to be refused classification in Australia.

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

An example entry that won me a similar competition 2 years ago (2009):

http://www.youtube.com/watch?v=YL294g3svr0

So yeah, spread the word, and start with the entries!

I want to see lots of them. LOTS OF THEM.

This comp will be useful for getting your skills up to pitch for the major project coming up!

Risky Design: Plain Sight

2010-12-25T19:40:00.000-08:00

Introduction:

All games have design flaws. Some are major, some are minor. Some can be fixed, others can't without changing the game greatly. This is just a reality we all get used to. I doubt any game could have perfect gameplay, pacing, balance, or interface - but all great game designers aim to limit their game's flaw's impact on gameplay as much as they can - so they are barely noticeable.

An example of this would be for example that in many modern games and sports that are objective driven and focus on simultaneous attacking and defending (such as Capture the Flag), once a team has the lead - in some games it may be more effective to defend said lead, rather than attacking and trying to get a larger lead.

This is a flaw, yes, as part of the main idea behind Capture the Flag is balancing your offense and defence - but most games will just allow it - why?

There are very limited ways to actually fix it.

You could separate the offensive and defensive elements so that each team takes turns trying to get each other's flags (kind of how Rugby-styled football games do, or how Counter Strike's CS maps play out), but that's not capture the flag. It would in fact completely remove the balance that we want to achieve.

Another alternative is maybe buffing the losing team slightly so they can break through defences easier - but then you could run into balance issues, and teams being wary to get the first point in fear of a strong counter attack - which, could lead to stalling until the clock is very low and then trying to win.

So, Capture the Flag is flawed - but we all live with it and enjoy it still, because there are few ways in which the game style could be slightly tweaked to fix the issues surrounding it, without completely changing the game type. The problem is also fairly minor, as most teams will continue to pursue the flag even if they have the lead.

Still, there's room for improvement.

Moving On:

The point of this article is to talk about the game "Plain Sight".

Plain Sight is an amazing game developed by Beatnik Games, and the reason I'm writing thisarticle is because Plain Sight takes many features that have very easy to recognise flaws, and actually mashes them together to make for a greatly fun, near-seamless game style.

Before I dive into it, check out Plain Sight here: http://www.plainsightgame.com/

And I greatly recommend you buy it from Steam here: http://store.steampowered.com/app/49900/

Plain Sight uses the following flawed systems:

"Big Head" mode from Goldeneye.
Progression through death
Exponential power growth
Transparent player actions

"Big Head" Mechanics.

Explanation: In case you haven't played Big Head mode in any games such as Golden Eye, Unreal Tournament, etc. - it is a supplementary game style where, you still pick "Deathmatch", "Capture the Flag" or the like, but in Big Head mode, when you get a kill, your head gets larger so it's easier for people to headshot and kill you.

Pros for Gameplay: A fun silly mod for people to mess around in.

Cons: People can be reluctant to go for a large spree, and will sometimes commit suicide to make their head smaller.

In Plain Sight: Characters get larger and larger as they get kills, and as they do this, they can be targeted and tracked from a wider distance. Also, players who are larger yield more rewards for those that kill them, making them not only an easier kill, but a more sought after one.

Progression Through Death

Explanation: Progression through death is where a player feels that they gain more from relentlessly pursuing a goal and dying over and over, rather than trying to stay alive. Think of it like a player using a character with high area of effect damage running in a group of enemy players over and over to slow their progression, rather than taking them with skill and planning on as the game designers would intend.

Games can reward progression to death, they can punish it heavily, or any measure in between. It depends on the game.

Pros: The only time when death should be rewarded is where death is the objective - which is extremely rare. So, if "Death" is considered the failure condition, there are no pros to rewarding it.

Cons: Again, if death is the failure condition, it is bad to reward it.

In Plain Sight: Plain Sight is the first game I have played where death is the objective. In Plain Sight, you must gain energy by killing opponents (and getting bigger), which, then, when you commit suicide - gives you the fruits of your labour in your past life. Dying with a lot of energy (being a big fat robot), gives you far more points than dying with no energy.

Exponential Power Growth

Explanation: Exponential power growth is the term used to describe when players are rewarded for their achievements in the game, and so they are more effective, and are rewarded more. The cycle repeats until the game is unfair because one player (or team) is completely dominating with overwhelming power due to a couple of early achievements.

Pros: None. You never really want exponential power gain - though, in any game where you level up, it's a given. As a player gets stronger, they'll naturally be more capable when dealing with the same threats. Most games balance this out by making it so that over the scope of a 'round' or 'match', a player will never gain permanent advantages that an 'unlevelled' player cannot overcome with skill. For example, in Monday Night Combat, a non-upgraded player can still kill a completely upgraded one with skill.

Cons: An unbalanced game.

In Plain Sight: In Plain Sight, as a player gets kills and energy, and gets bigger, they also get stronger, they can jump higher, acquire targets at a larger range, their suicide detonation is bigger, etc. That said, they do not gain defence, so while they become a killing machine, it still only takes the regular dash attack to kill them. Also, as a player detonates with more energy, the points they gain is increased greatly. So, detonating after one kill yields next to nothing, while over 10 kills is a real game changer.

Transparent Player Actions:

Explanation: When a game makes player actions transparent, it means you can see and understand what the enemies are doing easily, and there is no real element of surprise.

Pros: Forces players to play in the open, without worrying about flanking, camping, stealth, etc. Depending on the style of the game, this can be good or bad.

Cons: In most games, removes strategic depth. Like it or not, camping, flanking, and sneaking are all valid strategies.

In Plain Sight: Players emit energy trails, that other players can follow to the player. Similarly, when players step on a part of the level, the ground lights up so that other players can see where the action is. The trails and ground light up more as you gain energy - so it's far easier to find more valuable targets.

How These Features All Come Together

So, Plain Sight implements all of these pretty flawed concepts, all in the one game - but it comes out great! Why?

They all cover each other's weaknesses.

The Big Head Mechanic and Exponential Power Gain mechanic work together to make for a very risky game style.

As you get more kills, you get more powerful, more deadly, but - you also get easier to kill.

Progression through Death allows the person to capitalize on the risks they have taken if they wish - or continue on, as the risk builds up higher and higher. As the risk builds, so does their reward if they are successful in committing suicide.

The Transparency of Player Actions is important as it increases the risk. An energy-filled player cannot hide and camp, they can only run and kill.

Conclusion:

The concepts above all work together perfectly to make a game style that is all about risk, greed, and chasing the most valuable players. And I love it.

It's great fun, it's an adrenaline rush whenever you have a long streak going and - I love how the game's gameplay almost seems to mirror its design. Beatnik Games took a gamble on mashing these features together, but it completely paid off.

I think this article is just saying that, well, first off, Plain Sight is designed masterfully - but also, that with enough thinking and creativity, you can find solutions to design problems anywhere, and even mash them together to fix each other.

Who knows? You could create a better Capture the Flag one day!

Lord of the Rings Online vs. World of Warcraft

2010-11-26T13:00:00.000-08:00

Introduction:

Well, I finally got some inspiration for a post. I have been playing Lord of the Rings Online recently - well, for the last couple of days, and it was certainly an experience.

It's very similar to WoW in some ways, but in other ways, not as much. The main difference being that WoW is far better with pacing, and that's why I'm writing this post.

My thoughts on Lord of the Rings Online:

I originally had here a full run through of what happened during my playing experience, and how I felt about it - but it ended up as being extremely long, so I'll just make a simple list.

Things that surprised me in a good way:

It's a free to play game, with solid graphics, and stable gameplay.
Each character has a very unique play style, and the ones that I tried were all very strong when you got their core abilities.
A strong crafting system.
A lot of quests and instances.
The game gives you a quick taste of power from the start by giving you some Novice items, and a free Rental Mount (that lasts for 24 hours)

Things that surprised me in a bad way:

A lot of awful quests, with very few fun and rewarding ones.
In fact, too many quests full stop - leading to a grinding game style.
Sprawling zones full of lots of little towns, with lots of quests - it's impossible to decide what to do first, or at all. It's overwhelming.
Too much running, (often) not enough action.
The game has you completely strapped for cash in the beginning, as your expenses for gaining new class skills gets too high for your level.
An unstable GUI.
Many limits on even basic features without using Turbine currency - which can be paid for with real life currency. (Fair enough, the team has to make money, right? Still... it annoyed me a bit)

The main things I want to talk about ais the Pacing. So yes, expect me to be criticising LotRO a lot in this post - but, before I do, I will clarify that when it comes to free MMOs (that are legal - not private servers), Lord of the Rings Online is probably the best I have played. And I don't mean - "No monthly subscription", I mean, free all over - you don't even need to buy a serial key.

It's a great game, so if you don't want to be forced to pay for an MMO - I'd go straight for it.

Pacing Problems:

Lord of the Rings Online has some pacing issues as I described before - mainly that you're often running around aimlessly just trying to complete the crazy number of quests - and most of your quests are based on talking to people across the map. Then when you find them, you find 20 more quests.

It's overwhelming - badly structured, and as you run from place to place - somewhat boring. Towards the end of my recent play time, I spent most of my time with Auto-Run on, just avoiding monsters as I gazed up from MSN and saw I was running into them.

Similarly, every quest you get is often a part of a quest line - so it's hard to just skip one because you may have done 3/6 parts of the line, but you have not yet gotten your final reward. Similarly, it can be kind of infuriating to be finishing off a quest that has had you running around for an hour, and then talk to who you think is the final NPC only to have them send you back to the other side of the map again.

A map of what my time in "The Shire' probably looked like is as so:

Most quests are in red, the particularly annoying quests are in other colours.

Light Blue: You run around as a chicken, you cannot fight or anything - you simply have to run slowly from waypoint to waypoint. You have to do this twice-3x, with no difference really except for the waypoints.

Indigo: You have to talk to the man in the lower left, then the woman in the lower right, then the man in the top right, then the woman in the lower right, then the man in the top right, then go to the top left to find an item. Show it to the man in the top right, show it to the woman in the lower left, go back to the man in the top right, go with him to an instance in the top left, beat the instance, go to the man in the lower left, talk to the woman in the lower right, talk to the man in the top right.

And I'm not joking.

Yellow: You have to carry pies from all over the region to this one woman while avoiding particular hobbits (who steal pies). You usually have to go a long route, through enemy infested territory, and, while you're holding the pie, you can't attack or ride your temporary horse.

Green: Similar to the Pie-Carrying, you have to carry mail all around the region and avoid a different kind of hobbit that steal mail. Again, you cannot fight/ride a mount.

Pink: A crazy quest like Indigo - a lot of talking and running, with a tiny bit of fighting in the middle.

And as said, the Red are all the other quests - which, heavily outnumber the other colours. I think, if I had have truly represented Red, it would have been more of a smog than a bunch of lines.

Now, this would be... somewhat okay... if you could run from one end of the map to the other in about a minute. Well, unfortunately I timed it, and it took me nearly 10. So you can see how I spent about 15-20 hours in the last few days on this game, and only finished this area.

Now, you certainly have the option of doing the good quests - and then leaving the rest, but as a newbie - you cannot make the distinction, and, there are a lot of rewards for finishing a lot of quests in a region - so you feel that it's what you should do, while my friends have had a lot more success just picking and choosing.

It's also a lot hard to compartmentalise the quests when so many have nearly 10, or even more steps in them.

How World of Warcraft does it:

This is where WoW comes in. WoW has similar areas (where you start out as a newbie, get your professions, and leave the Novice level, choosing where you go next)

But, their areas are always (or at least, almost always) far better designed.

Let's take a look at how you'll traverse the starting area of "Durotar".

Your spawn point is the Purple X, then the green is your starting zone - for levels 1-6.

After that, you are asked to go to a little camp just outside the starting zone where you start getting some more quests - after you finish the key ones, (you don't have to finish them all to progress), you're asked to go to Razor Hill (Red), where the Yellow X denotes that you can set your teleporting (Hearth) stone to teleport there - which is useful when you've just finished many quests in the one area.

Once you've finished the key quests there - you're asked to go to Orgrimmar (Purple) again, you can set your Hearth Stone.

The key things to note is that all areas are somewhat self contained. The Starting area only ventures out when you've finished it. The Camp deals with the areas outside the starting zone and the Echo Islands. Razor Hill, being the main object of levelling inside the area covers the most ground - but even so, most quests are roundabout in the same area (meaning, you can complete them at the same time). Orgrimmar deals with the North.

Also note that all quests expand out, and then return to the single 'Town' in which you got them. They rarely go between towns - and all of your valid quests in the one area, meaning you can see them all rather than finding new ones everywhere.

I always like to praise WoW on pacing, but this is why - it's so easy to understand, it's well encapsulated - if you know the quests, you can do many of them at once to save on time. As the quests don't roam the country side, and aren't all quest chains 10 long, you can just do a couple, and then go to another area if you want - which is used a lot for speed levelling (example, if you hate the small camp outside the starting zone, you can travel to another starting zone, and finish a few quests there before returning).

Note:

At this point I'd like to recognise that a couple of weeks ago, The Shattering happening in World of Warcraft - and many zones were changed. And, Durotar is even faster, and designed better than the picture shown, if you would believe me.

Conclusion:

In closing, both World of Warcraft and Lord of the Rings Online are great MMOs - but, in order to be more competitive with World of Warcraft, LotRO has to work on its quest pacing and over all progression.

The most important factor with MMOs is getting players to play for long periods of time, so that their characters are strong enough to utilize end-game content, and when it comes down to it, I feel that for most players, LotRO is missing that gripping factor.

To improve, it should:

Cut down on the number of individual quests in each zone, so players are less bored by the end.
Shorten some quest chains, and split some up into individual quests so players can pick and choose easier.
Restrict quests' objectives, so, for the most part quests are all in a small area. If they do move to another area - prohibit them from moving backwards. Players should be able to draw a line from questing hotspot to hotspot.

This means that a player will likely feel like they are progressing faster, and they likely will be - as they won't be wasting time running from on end of the map to the other, and doing boring quests.

To put this into perspective, in 16 hours I can:

Get a character from 1 to 15 in Lord of the Rings Online, or
Get a character from 1 to 25 in World of Warcraft.

Which would players likely prefer?

If you've been wondering where I've been...

2010-10-27T16:42:00.000-07:00

That explains it,

Been doing lots of work on Pokemon Universe!

I will make a real blog post soon!

Power Creeping and Power Shifting

2010-10-02T01:36:00.000-07:00

Introduction:

Well, I haven't posted in a couple of weeks - and I've been feeling guilty. That said, I've got a splitting headache, and I'm a bit angry... so we'll see how this goes.

Anyway, this post is about balancing to a certain level of power - if you have one character who is much better than everyone, do you nerf him? Or buff everyone else?

If you have half of your units being too strong for the other half - what then?

Finding a power level, then rebalancing your units to that power level is called Power Shifting.

What is a Power Creep?

"Power Creep" is the term used to describe one solution to the problem of balancing units - where idea is to buff all units to the best unit's level of power, meaning that the average power of units in the game increases (thus, 'creeping'). The term is usually used in a negative tone - to give the idea that the changes were poorly planned - though a Power Creep isn't necessarily a bad thing.

How should units be balanced?

The thing is, this depends entirely on the game, and the current balance situation.

It can't even be generalised, for example - say you had a roster of 34 characters, where one was generally more powerful than the rest - then you had maybe 5 or 6 under it, that could stand a chance against it. Assume that the rest of the cast are unusable against these 7 characters.

What should you do?

Most people would logically say "Nerf the 7 units, and leave the other 27 as they are", assuming the other 27 are on par with each other - but, this is not always the best solution.

What if the other 27 characters are ridiculously bland, and no fun to play because they have limited options and strategies in battle?

What if the 7 characters up the top of the list are the game's only saving grace, and, the existing metagame and matchups between these characters are amazingly fun to play?

Nerfing them would be a mistake - you're taking away all the fun.

So what's the secret?

Always have fun in mind when choosing what power level you're going to balance to.

There's no use nerfing all your characters to a boring, pathetic level - and similarly you shouldn't be buffing all of your characters to such a height that the game loses strategic depth in favour of button-mashing, camping to punish, sheer luck, etc.

With each game individually - you must think of which characters have the balance of reliability, power, and fun - then move characters up and down to their level. Hopefully, you'll have a good group of characters at this level who are balanced with each other - but, other times, you have to form the group unit by unit.

Speed is Opportunity.

2010-09-13T04:03:00.001-07:00

Speed is Opportunity

If I were to ask you what's the most important stat in your favourite game, I'd get a range of answers depending on the game, and the playstyle of the person at hand.

But, chances are, after a bit of investigating, maths, and some analysis of the competitive format of the game - I'm 95% sure that with any given game, the correct answer would be "Speed".

Why Speed?

Because Speed is Opportunity.

Let's take the most common forms of speed, "Movement Speed" (mobility), and "Attack Speed".

Movement Speed

In every game, Movement Speed, and general mobility are extremely important.

Mobility is Control.

In an RTS, if you outmaneuver your opponent, it's often called Flanking.

In a Fighting game, it's Spacing.

In an FPS, it's Zoning. (Or gaining weapon advantage, flanking, spacing, etc.)

Whatever the tactic is called in each game, your ability to utilise the geometry of the playing area, and use the distance between you and your opponent is a domination tactic. It's controlling. It's fighting on your own terms.

Now, usually I resent people quoting Sun Tzu with regards to video games (it's overdone), I love his work otherwise - but really, the best way to express myself is through his quote:

"And therefore those skilled in war bring the enemy to the field of battle and are not brought there by him."

Which is precisely what I'm getting at.

Superior Mobility offers:

Control over the terms of the encounter.
Control over your enemy's options.
Greater ability to scout the enemy's strategy.
Superior options and opportunity to counter the enemy's attacks.

Attack Speed

Attack Speed is less important as mobility in most games, but don't get me wrong - it sure helps.

When you think about it, in most games, no-one is attacking without pause. Guns reload, characters guard, and attention is given to other priorities - so, nobody is really attacking at their highest speed, they are choosing to attack at designated times. With a higher attack speed, it's far easier to slot your attack into these times.

So, when you think about it, a character whose standard attack speed is a single attack in 0.2 seconds, will be able to shield until the time is right, and be shielded again after 0.2 seconds - giving his opponent a small window to attack him - in which case the opponent will usually have to attack through a hitbox.

Contrasted to a character who has an attack that takes an entire second to deploy - its opponent will have a much larger window to seize the opportunity to attack.

In this very simple case, it's obvious to see that the 0.2 second attack is superior, and, if these characters were to fight each other, the first could likely read the opponent's attack, and hit it 3-4 times in this window - which in most games means that the opponent's attack would be interrupted.

Think of it this way - every attack animation has foreswing, and backswing.

Foreswing is the lead-up to the attack, whether it be the charging of a strong attack, or the time between the input of the command, and the attack's full potential being reached.

Backswing is often the recoil from the attack. The sword going back into the sheath, the gun being prepared for the next shot.

The addition of these is what gives you the speed, or time of the attack. For example, the speed of an attack that has 0.5s Fore and Backswing, is the same as one that has 0.25 Fore, and 0.75 Back.

A lower Foreswing is mainly important for preventing your opponent from guarding against your attacks - if the punch comes out in less than 0.2 seconds, the opponent will generally have to input the guard command before they know that you've punched. In the same light, a move with a large foreswing (such as 0.8 seconds) can often be recognised, and shielded before the attack is even close to hitting.

A low Backswing is important to prevent the attack from being punished.

The act of punishing an attack is where an attack is blocked, or dodged, and the opponent seeks to attack back before the original attacker can regain control of their character. This is heavily aided by mobility, but simply having an attack with a lower Foreswing than the opponent's Backswing will do the trick.

So, a High Attack Speed:

Gives you the ability to punish attacks.
Gives your opponents little chance to punish yours.

So, what are you getting at?

You know the slow and heavy, but powerful units in games?

Time and analysis has shown that across many games, across many genres - they rank lower than faster units on average.

This is poor balance, carried by the widely-spread, flawed notion that "Slow but Powerful is equal to Fast but Weaker".

Due to the Control afforded by Mobility, and the Opportunities afforded by Attack Speed, this will likely never be true unless paired with higher resistance to all consequences of being attacked (such as flinching) and, at least some attacks that break the mold.

It seems that many developers are starting to see this, and that's great - but, they are still falling into the biggest trap, which, is continuing to give the units slow Movement Speed to compliment their slow Attack Speed.

To be blunt, this can rarely work, and is unnecessary.

To start with, have all your units start with the same movement speed, and then alter them individually as needed.

Summing Up:

Movement Speed gives one the ability to control the terms of engagement.
Attack Speed gives the opportunity to attack with less chance of being countered.
A larger Foreswing increases the chance of an attack being guarded.
A larger Backswing increases the chance of an attack being punished.
"Slow but Powerful" vs. "Faster but Weaker" is a false balance notion.
If a unit is slow in attacking, they will usually need to be compensated with Resistance to attack.
All units should start at the same Movement Speed, and they should be altered after a lot of testing and analysing.
If a unit has a slow Movement Speed, they will usually have fewer options against faster opponents.
Units with slower Movement Speed often have a lower skill ceiling, and lose the competitive edge in skilled play due to the previous point.

Random Chance and Luck-Based Gaming

2010-08-20T03:35:00.000-07:00

Introduction:

My friends and I were playing Super Smash Bros. Brawl which, ever since the 2nd week of me playing Melee, I have always played without items.

At parties though, items will go on on occasion - but, after a few matches, I want to turn them off - due to the fact that when items are on, there is no real point to playing because you have limited control over the way the game is being played, and you have limited ability to judge what might be coming your way.

Basically, the game is less about skill, more about luck.

In this point I'll like to highlight why sure, a little luck tosses it up - but when it comes down to it, skill is the main ingredient in fun.

A Little Luck is a Little Good

Don't get me wrong - a lot of outcomes in each match are due to at least a little luck - even if nobody gets a critical hit, or rolls a random class.

An enemy rounding a corner, a little weighted spray - or the fact that you thought that your enemy would make one move - then he didn't think of this move at all and went for another? There's a fair amount of luck.

That said, skill will still weigh in a lot on these issues - complimenting them. If you position yourself well and are aware of enemy locations, you will be able to effectively battle the enemy around the corner. With better aim, you have a better chance of your spray hitting the opponents. With good knowledge of the game, you can use moves that, regardless of what the enemy is thinking, have a good deal of success.

So, in every well balanced game, there'll be a bit of luck - but skill will still affect the outcome of a match over luck entirely.

So, why on earth would you want to add more?

Why Skill Reigns Supreme

Skill is important in games, especially in ones where you compete against other players.

Many players get satisfaction from exacting a task with proficiency, and showing off just how much they have learned about the game and how to play it - even against computer opponents.

It builds the player's self esteem, and gives them the feeling that they are having fun.

Many designers have analysed this feeling - one in particular being Raph Koster, the author of "A Theory of Fun for Game Design", who argues that the experience of fun is derived nearly entirely from the experience of learning, and trying to perfect facets of a game's gameplay.

I don't agree entirely - but I absolutely believe that learning and gaining skill is extremely rewarding to players, and as such is a main element of the experience of 'fun'.

Repeat the mantra, learning is rewarding, and rewards are fun.

You Did What?

Another aspect of luck is the negative side, where players feel cheated if they are beaten through luck-based occurrences, which is fair enough.

One second, you're beating some guy down with a well timed sequence of moves, and, the next, he gets a lucky critical and you're down. Despite the skill difference, or how well you executed the attack, the luck trumped your skill in determining the outcome of the encounter.

That's bad - it's as if you might as well have just played Paper, Scissors, Rock with the opponent. And everyone hates Paper, Scissors, Rock.

Something that I see a lot of designers do is have little occurrences that can determine the outcome of an encounter - and justify it with the fact that it's only a 1%, 2% or 5% chance - but all this does is have no effect on most encounters (so why even include it), but make the ones that it does affect completely based on chance and rage-inducing for the player on the receiving end.

Do not do this.

As explained - it's useless (it doesn't achieve anything) and bad game design at the same time.

No-one even notices if you don't include staples of random events (crits, etc.) in your game. The only time I've heard someone say "That's odd there aren't any critical hits", is immediately before "and I love it!".

If you want to include random chance in your game, do not use "Low Chance vs. High Payoff" chance.

To ensure that your game is balanced and fun, use "Moderate Chance vs. Moderate Payoff" or "High Chance vs. Low Payoff" chance.

Triggers

To define Moderate and High Chance, I need to define Triggers.

A Trigger is simply an event, that can cause a random event. It's the event that causes the proverbial die to be rolled. For example if every time you shoot a bullet from your weapon, it can critical hit for 3x damage, shooting your weapon is that event's trigger.

A trigger's Trigger Occurrence Rate is how many times this event will happen in an encounter (or in a given time period) - and will affect the random chance co-efficients you use.

For example, if you shoot 10 bullets per second, and they have a 10% chance to crit, that's effectively one crit per second.

If you want this one crit per second, and your weapon fires on the half-second, you would give it a 50% chance to occur. It's as simple as that.

For this reason, it's hard for me to define what I would consider Moderate and High Chances.

I simply do not know the Trigger Occurence Rate for the games that this post applies to, as each game has its own balance, pace, and encounters.

That said, I generally aim to have my lower limits of occurence at 12.5% or 16.6% (1/8 and 1/6), as any lower and unless your triggers are occuring rapidly, there is a rather low chance of the event occuring and it falls in the reals of "not useful but really annoying" features.

Anyway, "Moderate Chance vs. Moderate Payoff" and "High Chance vs. Low Payoff" chances offer the following advantages:

You can more easily judge their effect on game balance.
Players will more easily judge their effect on encounters, and will adjust their strategies in turn.
Something that has a higher chance of happening appears to be far more useful to players than low chance occurrences.
Something that has a higher chance of happening is actually far more useful to players than low chance occurrences.

The first advantage is actually really important - as I too have falled for the "Low Risk v. High Payoff" trap before, and, I'm in the middle of rectifying it for Pokemon Universe.

In PU, a few Pokemon have some abilities that have a tiny chance of activating, but, could win a match. Put them all together (each Pokemon had a few of them each), and I realised that these could decide matches more than team layout and skill a lot of the time.

The scary thing is, I put them in the game a while ago and it took me this long to realise how bad it really was.

As a designer, it's so easy to say "Oh, it'll only have 5% of the time, that won't affect anything," and "That makes it just a filler", but - the amount of grief it could give your players is tremendous, and could make the difference between having a game with a skilled design and a possible competitive future - and a casual party game that isn't even fun at parties.

Higher activation chances increase the transparency of a feature's effect on game balance - making it more enjoyable for both you to work on and players to play.

Conclusion

So remember:

Games with few random parameters usually have enough luck in them as it is.
Skill should always trump luck in deciding the outcome of an encounter.
Gaining skill and learning is a rewarding experience for players.
Low Chance, High Reward feature often don't happen enough to affect balance, but when they do happen, annoy players greatly.
Use "Moderate Chance vs. Moderate Payoff" and "High Chance vs. Low Payoff" chances.
These chances are easier to factor in your balance.
These chances are easier for players to factor into their strategies.
These chances increase the transparency of your luck system, increasing the quality of the game.

And that's why I think you should turn items off in Brawl.

Simple Balance Rules.

2010-08-05T22:19:00.000-07:00

Introduction:

Balance is a big topic - and each game will require different balance strategies, but there are a few simple principles that are common to all games. These mainly pertain to winning conditions, and equal opportunity for all parties able to win. Also, David E. Kelley.

#1: All parties that can win a match, should have equal ability to win a match.

This one is blatantly obvious - whether you have two teams in an FPS, two armies in an RTS, or four players in a Fighting game, all should have the ability to win from out the outset of the match. It should be up to each party to make the choices, and use their skills to win or lose the match. The maps, levels, and other match settings should benefit each party equally - such as in the RTS, one player shouldn't start with a huge wood supply, while the other has all the rock.

Basic game settings and maps shouldn't determine the outcome of a match to any degree.

#2: Basic initial player choices should for the most part hold little significance to the outcome of the match.

In simple Player1 vs. Player 2 games, their choice in unit should not be significant to the outcome of the game. For example, in an RTS, one player should not be immediately in a losing position because they chose the Elves while the other chose the Orcs. In a Fighting game, a player shouldn't be disadvantaged because they chose Johnny Cage and the other chose Bridget.

Players should be able to choose any character, army, etc. that they want, and be able to win the game.

That said, in games where there are teams of players, the situation is a little different. For example, if Team A's players all choose pistols, while Team B's players choose a variety of Sniper Rifles, Pistols, Machine Guns, and Assault Rifles - the team that chooses their units to more actively reflect the nature of the game should win.

#3: Ensure that there are no dominating strategies that ensure that one party will win the match.

This is a mixture of the above points. You must make sure that with the mechanics of the game, the designs of different levels, and the features of different characters can't all mis together to make a perfect strategy that dominates the game.

A common problem in some games is where defensive options are so strong - that offensive strategies would be punished heavily. This creates a campy style of game where strong defensive characters are kings.

To guard against this one, you have to ensure that the game's mechanics are designed with equally viable offensive and defensive strategies and counter-strategies, while ensuring that your game modes and maps don't favour a particular play style.

Similarly, you need to design maps with your unit's capabilities in mind, a good example being Team Fortress 2, where there are "Magic numbers" that denote important figures such as a Sentry Gun's range.

Unit Balancing Strategies:

These ensure your game in itself is balanced - but doesn't say much about the individual units. We'll go to those next.

One point I'd like to make is that every designer has their own criteria that say that a unit is balanced.

I have read some criteria that simply say that "If something is beatable, it is balanced" - and others that say something like "Each unit should have to exert as much force to kill itself, to kill an opponent".

I absolutely cannot stand the "If it's beatable, it's balanced" argument - as it pretty much validates any unit with a health bar that can reach zero. It's a very ignorant justification.

The other seems to be somewhat useful - particularly if you relate it to hit-counting, but I prefer my own definition.

What Criteria does a Unit have to fit to be Balanced?

Considering each player has equal skill, and the circumstances don't favor any unit:

A balanced unit must have a variety of other units and simple strategies that can reliably defeat it.
Corollary to the point above, if a unit is heavily specialised such that few units have innate ability to effectively nullify it, its specific counters must be extremely reliable, and commonly employable.
The unit's absolute power must accurately reflect the effort required to use it.

I think they're pretty self-explanatory.

The second point is basically saying that if you have a unit that is supposed to be hard to kill for many units, the ones that can kill it should be readily available, and very potent.

A good example would be Stealth units in Real Time Strategies - if you don't have an anti-Stealth unit, your groups of units can easily be ripped up without being able to fight back - but, with an Anti-Stealth unit, the invisible unit is visible - and can be attacked to exploit their often-low defenses.

My favourite thing about these criteria, however, is their versatility. While they are often meant to check for units being too powerful, with some quick word changes, they can be used to evaluate if a unit is underpowered, like so:

Considering each player has equal skill, and the circumstances don't favor any unit:

A balanced unit must have a variety of features and simple strategies that can be used to reliably defeat other units.
If a unit is heavily countered such that many units have innate ability to effectively nullify it, its specific features must be extremely reliable, and commonly usable.
The effort required to use the unit must be accurately reflected in its absolute power.

Now you have some good criteria to ensure that none of your units are rendered redundant during play.

Anyway, I'm ready to tie this one off, so I just want to make a note that I will hopefully be doing more articles very soon, and perhaps even some 3-minute-pitch videos.

I want to write about

- Balance Through Common Traits and Mutual Exclusivity.

- Sloth (game idea).

- Shapeshifter game idea.

- A Trick of the Light game idea.

At the very least.

I swear I had some others... I'll need to remember them.

Counters: Short Explanation.

2010-07-09T21:42:00.000-07:00

It took me this long?

I just realised that while I have referenced counters in many of my articles on balance, I have never explained them.

I really though I had already done this... perhaps I accidentally deleted an article that has all of this information in it. I hope not.

What is a Counter?

A counter is a situation where a Player Controlled Unit has an advantage over another, and can be applied in a number of different situations.

A unit may counter another if it:

Limits the other player's options. (The simplest instance is where a unit will avoid a unit that counters it, limiting its maneuverability)
Appeals to the other unit's weakness, and thus excels at eliminating it. (Example, a Sniper unit will often excel at killing a slow unit)
Removes the other unit's main strengths, or nullifies its advantages. (Example, a 'true-sight' unit countering a steal unit by removing its invisibility)

Badly designed Counters usually result in:

Content Redundancy. (Limited choices when deciding what units or content is viable to use)
Fewer viable in-game choices, and fewer strategies that a player can employ. (Players have a harder time playing how they wish)

Soft vs. Hard Counters

A Soft Counter is one where a unit has a statistical advantage over another, but skill and circumstance still determine the overall outcome of a match-up between a unit and their Soft Counter. Most game balance should be based on Soft Counters - as they help to enforce balance between units, but don't limit the countered player too much. Soft Counters are often described by saying that a unit "has the edge" or a slight advantage over the other - but the main feature of a Soft Counter is that skill still prevails.

A Hard Counter is one where there one unit has such a one-sided advantage over another, that the countered unit is seen as redundant and useless when the counter is in play. More often than not, the only way a unit can beat its Hard Counter is when there is a massive shift in power due to luck, or circumstance (finding your hard counter unaware, for example - or getting a lucky critical hit on them).

These should be avoided like the plague for the most part, as they create Content Redundancy. Still, if planned and executed perfectly, Hard Counters can be used effectively to stop dominations by exceptionally powerful, specialised units. And example of where hard counters are acceptable, is in RTS where invisible units can easily dominate players who do not counter them with anti-stealth towers.

A counter in between Soft and hard counters are often called 'Solid' or 'Tough' - and more often then not rely on circumstance as to where the counter is Soft or Hard.

Rewarding Players and Item Management

2010-07-08T21:39:00.000-07:00

Introduction:

Torchlight is an amazingly fun game - it's simple, easy to play, well paced... and monsters drop rare items like there's no tomorrow.

Torchlight rewards its players for playing, there is no doubt there. Hell, it rewards you for letting your pet kill everything.

But is it too much?

The following is a fairly common sight in Torchlight, especially if you have just killed a boss ora large mob of tough enemies:

Many players when discussing Torchlight say "It's great fun, there's a lot of loot!" but then "There's too much downtime when trying to sort your loot".

So, while Torchlight is great fun as you're accumulating all these items, trying to sort through them is a bit of a chore.

How much Loot is too much?

Well, this depends on the game - but there is rarely such a thing as a severe case of "too much reward" as long as some basic systems are implemented.

First let's look at the cons of over-rewarding, with the cons of under-rewarding.

Over-Rewarding:

Can make players too powerful for their current place in the game.
Can make challenges easier than was intended.
"It's too noob-friendly"
Can overwhelm players.
Can lower player's excitement when loot drops.

Under-Rewarding:

Makes players feel as if they haven't progressed in the game.
Makes players feel unrewarded (well.... of course)
Can force players to grind for rewards, rather than playing the game and enjoying it.

As you can see, it's better to over-reward than under-reward.

Simple System to Combat Over-Rewarding

Out of the 4 problems, the first two pertain to the player outgrowing the current state of the game - and becoming too powerful, or having alternate ways to navigate puzzles and challenges that defeat the purpose of the challenge.

The 3rd isn't really a problem - but a faulty attitude that some developers have. Developers shouldn't have it in for new players, and they shouldn't force players to jump through hoops to play their game. They should encourage different styles of play. End of rant about anti-player developers.

The fourth and fifth points are problems associated with Torchlight, and can be fixed in a couple of ways, which I'll get to later.

The best way to fix the player becoming to powerful for the game are:

Level Caps (in a random drop system)

Level caps make random drop systems. You cannot have a random drop system without some kind of level limit on equipment - otherwise yes, a level 8 Zombie might just drop a level 10 Hand Cannon. Other systems rely on level limits as well, such as trading systems - so that veteran players cannot give newer players their high level gear.

For looting systems, I think a good idea is to make a double-security system.

You can limit players from obtaining high level items by:

Stopping them from dropping.
Giving items a level cap, so only players of a certain level and higher can use them.

The second part is simple, and essential. I don't feel like I need to explain it at all.

The first can be more complex.

Many developers will instinctively say "Well, restrict drops to be that player's level and under." Though, while this works, there are definite reasons for making the system a little more complex. One such reason is that when a player gets an item that is really useful - but that is of a higher level than they are, they strive to wear it, and in fact make it another goal to aspire to.

Since they already have the item, and the goal is made up by the player, it's like a freebie reward that keeps the player playing with no additional work from the developer.

Just be mindful, you must restrict the items that can drop for the player. A Level 8 player is probably going to have forgotten about a Level 60 Chest-piece by the time they are able to wear it - and if all items are in the pool to be randomly dropped, your player may not find any relevant to his current place in the game, when he needs them.

A good idea is to make it so that only items a maximum of 5-6 levels away (though, this depends on your game and the speed of leveling) can be dropped. Also, a good idea is to make the system such that items 6 levels higher than the player are quite rare, while, items one level higher are more common.

Clamping the drop system around the lower limit range is important too, as, players don't want to be finding Level 8 items as a Level 10. For this reason, you may want to make it so no common items (of low standard) are dropped when the player is of a higher level. Rare items with special traits though, can perhaps take up a part of the random drop pool.

Common Sense (in a fixed drop system)

If there is no randomness to your equipment acquisition system, and your player is gaining items before they should - then... well.... that is a problem easily solved.

If you know a player shouldn't get a Rocket Launcher before Level 20, and you feel you need to reward them more... do not give them the Rocket Launcher during Level 18. Balance is the top priority - use your common sense and work out another reward to give your player.

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

If the player is suffering from having simply too many items, the following systems could be implemented.

Selective Item Drops:

This system involves altering the probabilities that various items will drop, and is often accompanied by the drop rate being lowered. This essentially gives the effect of dropping all of the good items that the player wants (they feel rewarded), while hindering the probability of a 'trash item' dropping (the player has less to manage).

Obviously, items of a lower level than the player are going to be seen as trash, unless there are very unique traits on the item. As already explained, low level items should be somewhat uncommon.

A smart way of weeding out irrelevant item drops would also be to evaluate the player's character. Essentially, lower the probability of items that the player cannot (or will not) use, and raise the probability of a more useful item dropping. An example would be a player playing the staple Mage, rarely getting Plate and Chain Mail drops, while still finding Cloth armour.

This is simple, Class > Class-usable items. An even smarter way of selecting drops would be to analyse the player's actions. If this Mage is always using its fire spells over its ice spells - give it more equipment with fire damage.

Remember, in terms of rewarding players:

Quality of Item Drops x Frequency of Item Drops = Reward.

So that you can have great items dropping sparsely, good items dropping commonly, or terrible items dropping a lot - and, the total gain of power is somewhat the same.

Obviously, there is an optimal amount of items that a player wants to hold, and so it's your job to find that.

Note that frequent drops feel more rewarding than rare drops however. Find the right balance.

Easier Management of Items:

Players need to be able to easily manage the amount of items that they possess.

Depending on the number of items that they possess though, the systems will change. An FPS will likely only require enough item slots to carry weapons, grenades, and health packs - while a resource based RPG may have a bag spanning over 100 items.

Depending on the game you may want:

Multiple item selection
Stacking items
Item sorting
Item categories
Item comparison

It's really up to the designer to know what tools are best for managing the items that their game gives to the player.

Storage Handling

Many games have a 'Safe Deposit Box' or 'Bank' where you can put items that you'll rarely use, but still want to hold on to.

Others, also have boxes where you can put items to trade them between your individual characters.

Depending on your game, it's something to think about. I would at least recommend a bank. It makes having lots of items much easier to handle.

Conclusion:

I think I'm done now, so:

Over-rewarding is better than under-rewarding.

And methods of dealing with rewards and item drop issues are:

Level Caps
Common Sense
Selective Item Drops
Item Management Systems
Storage Handling

More articles coming soon (hopefully next week).

Concise Writing for Video Games

2010-07-07T06:46:00.000-07:00

First Off:

Here we are, I'm back! I was never anywhere but here, but, I am back in the mood to write design articles.

I think what frightened me off is the amount of work that I'm doing at college, and on Pokemon Universe, as well as working, trying to catch up with friends, and gaming taking up a lot of my time. This coupled with the fact that when I wrote articles they were often a full day investment and usually had over 2000 words, meant that I was struggling to find the time and will to write.

To help myself, I have decided to change my style a little. Though, this is also to help people read my articles. While I enjoy describing my design ideas and philosophies to a detailed extent, it takes a lot of my time to write, and a lot of commitment from a reader to read in full.

Just like I say that a player shouldn't have to work through a game like a chore, readers shouldn't have to work through my articles.

I thought it would be fitting to make my first article back about concise storytelling and instruction in video games.

Introduction

Concise means: "Terseness and economy in writing and speaking achieved by expressing a great deal in just a few words"

Have you ever had a friend who tries to tell a story, or explain a concept - but, who gets so bogged down on the pointless details that you can't understand them?

And you're just tapping your foot, waiting for them to get to the point, and, even if they do, sometimes you don't understand?

Games are headed that way.

There are games that try to tell a story, or explain a gameplay mechanic - but, get so bogged down on the pointless details and backstory, that players don't bother paying attention.

The players just mindlessly tap 'A', waiting for the the cutscene or dialogue sequence to finish, and, when it does, the player doesn't even feel enriched.

It has to stop.

I would consider this problem to be a crime of hubris.

Designers need to always remember that they make the game for the players to enjoy, primarily. Badly designed communication often comes about when a company wants to show off their next generation cutscenes, or, thinks that every player wants to hear as much dialogue as can be thrown at them. Remember, the player is your priority.

Quality > Quantity

Nobody gains anything from lengthy dialogue and too-long-cutscenes. They intrude on the gameplay experience, and simply annoy players. Most players are just mashing their interact button and sighing, or taking a sip of their drink.

Unlike what you may think, storytelling is not enhanced with more words or time alloted to it. In novels, yes, there need to be a significant number of words allocated to setting up scenes, the nature of character interactions and mood - but don't be fooled. As much as you want your game to have a powerful story as if it's a novel, video games are a graphical medium. You don't need to write a novel to make a good story, as a large portion of the description is covered by the graphical elements of the game.

Dialogue, a major part of storytelling, needs to be direct and clear. Players want realistic dialogue - which, for the most part, is very brief in real life. As we covered before, people are irritated by others who cannot express themselves quickly, it is exactly the same in games and movies. Players find it very hard to sympathise with a dying character, who, for the last half of the game, they have been yelling at to "SHUT UP, SHUT UP, SHUT UP!"

Concise writing makes good story telling, and will give you the powerful emotional moments that you want.

Ways to Fix These Issues:

#1 Optimisation of Dialogue

To get realistic, succinct dialogue, look at good TV shows. TV shows have to stay within either a 25 minute, or a 45 minute time slot - and so, the writing has to be very optimised so that an episode can cover however many plot points it needs to within that time limit. Try to find shows with a similar tone and plot layout to your game, and analyse it.

Quick list of some well written TV shows:

Heroes (Season 1) (drama/action/mystery/sci-fi);
Dexter (crime drama/suspense/black comedy);
NCIS (comedy/crime drama);
Scrubs (comedy/drama);
Get Smart (comedy/parody/action);
Supernatural (horror/thriller/mystery)
Boston Legal (legal drama/comedy) (anything by David E. Kelley is good.)
Avatar: The Last Airbender (adventure/fantasy/action/comedy)
Etc. etc.

Another idea you can try is just saying the dialogue to yourself. If the wording sounds clumsy, you can often simplify it just by trying to express the point in your own words. Another idea that can help is imagining that you're saying it to someone who doesn't have much patience - because when it comes down to it, audiences often have little.

Try to also optimise cutscenes - don't make one for every level opening and after every remotely difficult enemy. Players will buy a movie if they want to watch a movie.

That said, some games use frequent cutscenes to great effect - such as Bioware's recent titles Mass Effect and Dragon Age. The main point I'm trying to get across, is that your players aren't playing for movies - and, if they are not well planned and executed, cutscenes can be an annoying, obtrusive obstacle to the player's enjoyment of the gameplay.

Whether they are sparse or common, by making well directed, interesting cutscenes, players will enjoy, and cherish them - considering them to be a great feature of the game.

A good case study for good cutscenes would be Borderlands. The cutscenes are short, limited to important characters and bosses, and have a good sense of humour. Players like them, and they capture the tone of the scene perfectly, while not intruding on gameplay at all.

#2 Make all Cutscenes and Dialogue Boxes Skippable.

Simple, eh?

This one doesn't really have to be explained. Make it so that there is a skip button for cutscenes, and that the 'skip command' will near-immediately go to the next message box when it comes to dialogue. Hopefully, if you've optimised your dialogue well, players won't want to skip text at all, but this means that they can if they want to - and, there won't be as much to skip.

Another point I'd like to make is, if there's an NPC that doesn't say much of value - please, one message box of dialogue only. Players hate to accidentally hit the interact button at the wrong time, and get roped into 5 lines of slow, useless dialogue.

#3 Less Intrusive Dialogue Boxes.

One development that has positively affected communications in games is persistent, but unobtrusive messages. They're usually found near the top of the screen, giving you information - but they do not take control away from your character to close them, and often close when a criteria has been met (you've executed the command that they are instructing you do to, etc.).

These are good.

Players can ignore them if they wish, but they still give information to those who need it. It is a far better system than a message box which takes control away from the character, especially because the player can execute the command as they read the message. Another advantage, is that it doesn't have to pop up to remind the player of the correct key presses, if they fail to do the keypresses the first time.

If you're going to give instructions to your player, I definitely recommend using the less obtrusive message boxes. Just remember to give your players a way to turn them off.

Optimising Messages - Examples

Here I'll just put down a couple of examples of intrusive and annoying messages in games, and I'll try to fix them up. Starting with the queen of painful buttonmashing, Nurse Joy.

(// designates a new Message box)

"Hello, and welcome to the Pokemon Center. //

We restore your tired Pokemon to full health //

Would you like to rest your Pokemon? ( YES / NO prompt) // (YES chosen)

[Animation, as your Pokemon jumps onto the counter and the Pokeballs are put into the machine]

OK, I'll take your Pokemon for a few seconds... //

Thank you for waiting. //

We've restored your Pokemon to full health. //

[Animation, as player puts balls in pocket]

Please, come back again any time!" //

~ Nurse Joy healing your Pokemon in Pokemon Heart Gold.

That's 7 messages, and 2 animations, just to heal your Pokemon. Something that you're doing a LOT in this game. It takes roughly 15 seconds when I buttonmash as fast as I can. That is infuriating.

What is even more infuriating, is that this game's Message Box allows for 2 lines of dialogue at any one time - and yet, Nurse Joy uses only one line for each message.

I would optimise it as such:

"Welcome to the Pokemon Center, would you like me to heal your Pokemon? (YES/NO prompt) //

[Much shortened animation, perhaps a second of the machine flashing]

Your Pokemon have been fully restored, good luck!" //

Finished. It should only take at most, 2-3 seconds.

And really, for an action that players will be doing time and time again - it should be as quick as possible.

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

Another example would be in Final Fantasy Advance Tactics 2 (which, by the way, has a game-start sequence of several minutes that is unskippable, terrible.) - when the main character is being inducted into the clan that he fights for.

"Quick! Join our clan! Your bones may be broken while in our clan but you can never die!"
"Why should I join?"
[Bird pecks at main character]

"Because I can guarantee that you'll get no such offer from him!"

"Okay so what do I do?"

"Swear your oath to the Judge! Say you'll join the clan!"

[Long animation as the judge is summoned]

"That's a judge?"

"Quickly! Before the beast has time to act!" (this sequence has taken so long that really, by now, a turtle could have slaughtered them all...)

"Hey judge, I swear my oath, let me join the clan!"

[Animation]

"Woah check it out!"

[Animation as 2 birds appear]

"Ah, he's brough the little ones along to feed"

"Stand back stranger, we'll handle this lot!"

"Ready yourselves!"

"You're going to fight them?"

"Once you stand back as I've told you, yes."

"Hey let me take a swing at them, I've sworn my oath, right? I cannot be killed as you said!"

"Harrrumph! Spoken like a true greenhorn!"

"You cannot die, but, if you take a peck in the eye, you might wish you had"

"Well I didn't mean I'd go in first or anything. And I'm no fan of getting beaked."

[Battle Start]

Okay I'm actually going to cut it there - it's starting to annoy me. By the time you get to actually take your first action that isn't filling in your character sheet, you've spent 4 minutes and 14 seconds mashing 'A' (like I said, terrible). And, as you can tell, the dialogue, while in character, is mostly pointless.

If I were to alter the above scene, I'd recognise that

a) Luso must be inducted into the clan (or must he? Truthfully, I think that inducting him into the clan so quickly was a bit of a stretch, why not just throw him a sword and say "We'll teach you how to fight, as it's a dangerous world out there"?)

b) The two additional birds must appear.

c) Luso must find a reason to fight.

"Quick! Join our clan! We can protect you!"

[Luso runs to clan leader]

"Okay! So what do I do?"

"Swear your oath to the Judge! Say you'll join the clan!"

[Shorter animation as the judge is summoned]

"Hey judge, I swear my oath, let me join the clan!"

[Animation as 2 birds appear]

"There are more of them, we might need your help!"

"But I don't know how to fight!"

"We'll teach you along the way!"

[Battle Start]

I do respect the humour that was added in to the situation, but, with the fact that the introduction has already spanned over 3 minutes at this point, it should be cut short.

Also, as said, when the sequence of initiation has easily been nearly 25 seconds, the humor of "Oh my God! Do it quick or it'll eat us!" isn't that charming. It's more annoying, at least for my taste.

Conclusion

The Pros of Optimised Communication

Better storytelling.
Players will read and understand your communication.
Experienced players can skip conversation that they have already witnessed.

The Cons of Badly Written Communication

Players will mindlessly buttonmash until they're past the dialogue/cutscene.
Players will feel contempt for the majority of characters who have lengthy dialogue.
Players will feel alienated and annoyed.

How to make sure your Communication is Concise and Well Written

Time your dialogue sequences and cutscenes, and evaluate how long it should take.
Read the dialogue a few times, and see if any seems clumsily worded or annoying.
Look for inspiration from well-written media.
Act out scenes to yourself.
Make sure dialogue and cutscenes can be skipped.
Use unobtrusive message boxes.

I think I'm done.

Another article coming tomorrow.

Upcoming articles.

2010-07-02T01:18:00.000-07:00

I haven't updated in 3 months, and, well, it sucks a bit.

I need to motivate myself a little more, and so I figure that making a list of things to do will help with that somewhat.

- Make a 3 minute pitch for an idea I have, currently named "Sloth"

- Make a 3 minute pitch for an unnamed idea I have... it has zombie seals.

- An article on Game Introductions

- An article on maintaining your games.

- An article on tone (mainly humour) and music in games.

- An article on character depth.

- An article on rewarding players. (already touched on this)

If I don't get these done before Christmas, someone punch me in the balls.

Word Count!

2010-03-22T17:26:00.000-07:00

I just did a word count of all of my blog posts, and the number was roughly 19500.
Cool I guess!

Pacing

2010-03-19T16:53:00.000-07:00

Not updating for a month sucks. I have been a busy guy.

Introduction

Pacing is the rate at which a player progresses through the game, and the way in which progress is measured and rewarded.

I'll be blunt. Out of all of the gameplay mechanics you can consider, pacing is hands down the most important. I know I stress balance a lot - but really, with bad pacing, nobody will play your game long enough to find balance problems.

Pacing is what makes a good game concept a great game, or a total disappointment.

Unlike game balance, in the way that it can only be negative if done incorrectly, pacing influences your game positively. If you have good pacing, it will reward you, unlike if you have good balance that only doesn't fail you.

Why is it so important?

Time is very interesting to humans as while we can't perceive it, it has a profound effect on how we react to mediums.

Have you ever heard a song where the singer has an abrasive voice, the music is not in your taste, and yet... you still have the song stuck in your head for weeks?

You can never pick why you love that song so much - really, it shouldn't appeal to you at all - and yet it does.

Scientific studies have shown that this due to the song having a beat that you enjoy. Beat is pacing in the music world.

Similarly, have you ever watched a movie that really didn't appeal to your interests, the plot wasn't like the kind of movies you usually like, but... still... despite the fact that you hate romantic dramas, you secretly enjoyed this one? (Though you'll never admit that your girlfriend was right.)

Again, it's all the pacing of the movie.

This happens with games. You may think of yourself as a hardcore first person shooter player who loves gore and making 14 year olds cry - but then you'll find yourself obsessed with a simple comedic puzzle game for a week or two, until you finish it and get back to the shooting.

Despite the genre, this puzzle game likely had great pacing, that appealed to you.

Though, this can work against games as well. Let's say that you (the proverbial hardcore FPS addict with a penchant for dismembering babies) have been waiting for the goriest, most anti-baby shooting game EVER. It has rockets and chainsaws and zombies and twitch aiming - all of which appeal to you greatly.

You can pick up this game, and, if it has bad pacing and progression, you will simply find it a disappointment and go back to the puzzle game. You will often say "Ugh, it didn't really work for me" or "It was a little boring" or "It wasn't as fun as I thought it'd be" - and all of these will often point to a pacing issue.

Pacing is a mysterious fundamental to game design - but it is the most important aspect of it. Do it well, your game will be amazing to play, do it wrong, your game will be a disappointment.

Pacing is so important to fun, it's not even funny.

What does Pacing involve?

Pacing is made up of Progression, Measurement and Rewards. I guess we could call them the "PMR"s of Pacing. I've always wanted to have my own 3 letters of something. Now I do.

Progression - Pacing is the rate of progression throughout a game, game level, or encounter. In this post, I am mainly focusing on progression throughout the entire game.

Progression throughout the game needs to be just right. Too fast, and the player feels overwhelmed, too slow, and the player feels bored.

The setting, pursuit and achievement of goals should be timed such that the right amount of player effort is put into each goal depending on its over all importance on the game and the actions that must be taken.

If your goal requires too little effort, the player will feel like you're throwing simple content at them, or that the content was not explored properly ("That's all?"). If too much effort needs to be invested, players will simply feel like the outcome or reward simply isn't worth it, and they may stop playing if too many high effort, low payout plays occur in succession.

This is a problem with designers who don't design games to be fun, but more to control players and make them jump through hoops for the slightest congratulations. They don't recognise that if players don't find a game fun, they will just turn it off, and play one that is.

Remember guys, domineering designers don't hook players. You want your games to be enjoyable.

Measurement - A good practise with pacing is breaking up the game into clearly defined chunks that can aid players in progression consciously, or subconsciously. Most games break up their games into levels, areas, or rounds - all of which can help a player gauge their current progression throughout the game, and help them to decide what must be done next.

The best part is, designers do this without really thinking of it. When they think of a concept, they say "Okay, the game will have 20 levels" - and there you have it, the game has been clearly divided into stages.

When a player understands their position in the game, it helps greatly when they must remember what has already been done, and what needs to be done. If a player loads their save game in Level 13, they understand that they have already beaten 12 levels, and they will likely be able to recall a past level to remember what tools they have at their disposal.

Knowing your position in a game is a memory-jogger.

With the player's memory jogged, they are more likely to understand what is expected of them in the future. This counters that horrible feeling when you enter a game, you look at your main map, and you have no idea of what you have done, or where you need to go.

I will note that you don't need to have numbered game levels. They are the simplest indicator of progression (Level 13/20), but other games have very effectively demonstrated the ability to measure progress through other methods.

A good example is in World of Warcraft, where certain areas have level recommendations. If you know the areas and their general level recommendation, you can quickly remember what you were doing, and what stage your character is at in the game.

Similarly, the games Bioshock and Batman: Arkham Asylum have you exploring themed areas, which can show your progress. The visual imagery of the "Medical Ward" can have the players remember a lot more than a simple fraction - so you can use this to your advantage when creating levels and areas, making them visually distinct from each other.

Just remember, if a player understand their position in the game, they will find the game far easier to get into - which is of course what you want. You want players to enjoy your game, and be able to pick it up quickly from where they last left off - whether they left the game for 5 minutes to get lunch, left it overnight, or didn't leave it at all and have just began the next stage of the game.

You want your game to clearly convey to the player what they are to do.

Rewards - Rewards are great. Rewards are what players want, whether the rewards are implicit or explicit - whether they add onto gameplay, or are simply a progression through a stage of the game.

While rewards are great - you must be mindful to not reward players too much (the rewards will get stale when they should be significant to the player), or too little (as previously explained, if a player feels as if their effort gets unrewarded, they will find the game less fun).

Rewards are important to pacing as they provide feedback for what players have done, they are a cherry on the cake of the player's achievement (you feel great killing a boss, but even better when he drops a massive sword!) - and they often lead into the next part of the game.

Different games offer different rewards, depending on the task that is being rewarded, and the genre of the game. Some rewards are explicitly shown and given to the player as a direct response to the player's achievement (such as defeating the boss and getting a magic item), while others are less advertised to players, but are still very much rewards for their effort.

An Explicit Reward is the reward that players see, and they know is a reward. These are rewards such as "You got 42 exp for completing that battle" and then, "You attained 600 exp! You leveled up!". Similarly, chests found in secret locations are explicit rewards as are items found after battle.

These are the rewards that many designers dislike because they can be intrusive, and can break the flow of the game in intense moments - though, there's no denying that the more explicit a reward is, the more likely a player will feel rewarded for their efforts.

An Implicit Reward is one that is quite subtle in comparison to the explicit rewards - the reward may be invisible to the player, or it may not be recognised as a reward by most players.

One particular example of a reward that often isn't considered a reward is story progression. With the decline of adventure gaming and plot-heavy RPGs in favour of action games, story progression is no longer considered as a reward as much as it was - though, games that reveal plot skillfully, and have great plots that take effort to unfold are still among the most rewarding games.

Implicit reward is preferred over explicit rewards by many designers as they make the game experience more mature, and lend emphasis to concepts and features such as story and theme, where power ups and new game mechanics to explore may not be a viable option.

There needs not to be adversity between designers who favour either reward however, as it is the careful placement of both rewards that will make a great game that appeals to many players.

Despite what you may prefer, using both effectively is far better than only using one.

The Importance of Pacing in World of Warcraft: A Case Study

I want to close through talking about the somewhat controversial game World of Warcraft.

People are always divided on their opinion on this game - some people think it's a time-vampire, others think it's a cost effective means of entertainment (compare the monthly price to seeing a movie at the cinemas - you'll be shocked).
Similarly, opinion is divided amongst designers - some designers think it is effectively designed - and that its popularity is testament to this, others think the design is poor.

Whatever side of whichever fence you're on, you should definitely admit that World of Warcraft is a marvel when it comes to pacing - and is an excellent example of the importance of pacing in games.

World of Warcraft's game play, in my opinion, is too repetitive. You fight the same spiders at level 1, 14, 25, 35, etc. - just with slightly different models, and scaled stats. Some may have a new ability every now and then, but, it's all very similar - and if you are the right level, you will likely fight them in very similar ways, most likely using upgraded versions of the same spells you were using last time.

Similarly, quests are recycled over and over. There are roughly 4 template quests.
- Kill a number of certain enemies
- Go to a position on the map to find an item.
- Gather certain items from the ground.
- Escort this unit from one map position to another (very rare).

There are subtle differences - for example some quest will ask you to kill boars and collect their tusks. Smart designers however, will realise that this is just a slight variation on the first quest.
If tusks drop 100% of the time, and you need 8 tusks, you essentially need to kill 8 boars.
If the tusks drop 50% of the time, this just means that you have an average number of kills to make (with a minimum number of kills, there is however no maximum). You will be able to finish this quest in 8 kills, but you will need to make 16 kills on average, and, there's the chance you'll need to make 100000 kills. (This is of course, assuming there is no Pseudorandom Distribution system in the game which increases the probability of an outcome every time it doesn't happen.)

Regardless, many players and designers still believe the gameplay of World of Warcraft is fairly lacking in variety. This conclusion is also supported by an amazing occurrence in many MMORPGs that at times require grinding - and that is when players pay others to play their game for them.

Why would they do this?
It's simple - the rewards the player wants to attain are considered more important to a player's enjoyment than the experience of gameplay, a player will play merely to get their character to the highest peak in the game.
This is of course, one of the main problems when creating an RPG - you want to avoid grinding.

Now, let's explore why players feel this need for basic progression, over the enjoyment of experience (I like to call them 'progressophiles').
World of Warcraft is ingenius in this respect, its pacing creates this desire for progress by bombarding you with rewards as you level.

Let's look at it like this.

Every level, you get a Talent Point to spend on your skill trees.
Every 2 levels, you attain new spells, and upgrades to old spells.
Every 3-4 levels, you get access to new instances (dungeons with bosses that require a team to complete), and quests in the area.
Every 5 levels, you get access to new tiers in your talent tree, opening up more ways to diversify your character.
Every 10 levels, you get access to a new battleground (PvP), abilities pivotal to your character are gained through the Talent Tree, and you gain new class skills that are key to the definition to your character (for example, the Druid's animal forms, a Warlock's summons, etc.). Every 10 levels, the recommended region for you to level in also changes, resulting in a new environment to explore.
Ever 20 levels, you get access to massive game mechanics that greatly change how how your character can interact with the world - such as through mounts.

Then, at levels 60, 70 and 80, the amount of content that you can access explodes, as they are the end of the game for each expansion, and you can access all content your expansion limit has to offer - with each expansion adding new worlds, raids, and other activities.

You can kind see how World of Warcraft hooks people in, can't you?
You are bombarded by rewards every time you level, all of which giving you access to many new ways to diversify your character and interact with the game.
People love to be rewarded, and this game delivers to an extraordinary degree. This keeps them playing, and playing, often just to get more and more.

With this knowledge of why World of Warcraft is so successful, it's quite easy to see why so many MMORPGs that try to stand against it fail. That element of constant recognition of achievement and reward is often far less present in these competitors, and, as such, the repetitive gameplay often associated with MMORPGs stands out more - which bores players.
And that is exactly what I mean when I say pacing is extremely important - with great pacing, your game is far more fun to play, regardless of some possible shortcomings. Similarly, a game with bad pacing will be no fun to play, despite other features that would otherwise make it amazing.

For all those would-be-rewarders though, I must warn you. While World of Warcraft does deal out great numbers of rewards often, you still should be mindful of over-rewarding players for simple actions.
World of Warcraft is able to dish out the rewards because levelling does take a fair amount of time as you progress. While leveling from 1 to 6 often takes around an hour for experienced players, 6-10 can be several more, 10-20 can take days.
Don't reward players with new swords, guns, and characters every 10 minutes - keep in mind your genre, and the difficulty associated with the achievements that unlock that reward.

Summing Up

Pacing is extremely important to all games.
Pacing can subconsciously affect the player players respond to game.
Pacing is defined by the rate of progression through a task in the game (or throughout the whole game)
Games should move at different ideal paces depending on genre - not too fast or too slow.
Pacing often involves breaking up the game into distinct sections. (Measurement)
When players recognise these sections it allows them to evaluate what has been done, and needs to be done easily.
Pacing also very much deals with the way in which rewards are given to the player for achievement.
Rewards don't have to be explicitly shown and given to the player, though both types of reward should be given.
Rewards should be given according to the effort required to complete the tasks set.
Over-rewarding can work against you when players are used to the rewards given, and as such, don't feel as rewarded when they attain them.
Under-rewarding will definitely work against you, as players will quit your game if they feel the effort is not worth the reward.
Pacing is extremely important to all games.

I hope you all found the post a good read - and I'll try to update again soon.

How to Set Up Balance

2010-02-21T03:31:00.001-08:00

So as you all know, the Undeadables is in development as a Warcraft 3 map.

Hewie sleeps over once a week, and we just make progress, watch movies, stuff our faces, and then as I wake up earlier than him in the morning I sneak out making him feel like a cheap whore.

Err... for the last reference I'd recommend seeing Up In The Air.

Also, a classmate at the AIE kind of pointed out an issue with game design blogs (or more, a personal reason for why he doesn't blog) - and that's because of people possibly stealing ideas.

I made my blog for educational reasons - both for myself and others. I like to clarify my thought by writing it all down, and I hope people read it so they can maybe refine the way they think about games - or, in some cases, they can flat out disagree and perhaps change mine.

That said, projects such as The Undeadables, and any other full game concepts I post here are my intellectual property (and any others who I am working with), and pretty much don't steal them.

Not saying they're good enough to be stolen, but in a world where they're selling L4D expansions as totally new games - I'm just being careful.

Introduction

This blog post is about starting your game, and setting it up to be balanced.

This is something you need to get right from the start. Prepare for it before you start making the first prototype. If you don't set it up properly at the start, you're going to regret it - especially if you don't apply any other methods of balance, or test it extensively.

Test your changes throughly with reference to balance. For every change you make to a player's stats and such, don't just boot up the game and see if it updated properly... makes tests to see how many enemies you can take on at once (for example), in comparison to what you'd like the player to be able to do.

Not testing as you go creates not only potential for massive code errors, but potential for terrible balance problems.

I follow this process when creating a game idea, when thinking of balance.

7 Steps to Ensuring Balance

Create expectations for all basic variables that will affect play, and evaluate how they will affect balance.
Apply any simple balance strategies that will be used.
Develop expectations for a battle between two or three basic units.
Test the match ups.
Alter until expected results are reached.
Repeat step 3-5 for all other units, with reference to step 1-2.
Test over and over and over whenever changes are made.

Now I'll go over each step.

Step 1 - Create expectations for all basic variables that will affect play, and evaluate how they will affect balance.

#1 is extremely important, but very few people even think of it. Most people jump right into "Okay how many backstabs should it take to kill a Mage?" without thinking of variables that will make these numbers vary a lot.

You should consider such variables as:

1. Game Time - The average time total in an instance of the game (such as a 'round' or a 'game'), as well as the rate at which players progress through the game is extremely important when it comes to balance.

For example, A character who slowly amasses massive amounts of power throughout a game will love a full 80 minute game as it suits his play style, while a character who totally dominates early in the game would love a game style that can be beaten within 10-20 minutes.

The game time in a single instance of play greatly affects balance depending on PCU's rate of power gain throughout the curve, so Game Time should be clearly defined.

That said, game time should be clearly defined anyway - as let's face it, most players can't play a 3 hour game, and others won't get much satisfaction from a 1 minute skirmish.

For the most part, most team based player vs. player games are focused around 40 minute times, often split into halves and quarters. For individual versus individual games, the time may be anywhere from 5-10 minutes.

That said, it depends on the game, and its gameplay. An RTS will always be slower than a fighting game, and an RPG will hopefully be even slower than that.

Pick a game similar to yours, and shoot for that game time.

Also, as a little pointer, if you're having trouble finding find the best game time for your game, shorter is better than longer for the majority of players.

2. Number of Players - the number of players in an instance of a game is important. Thankfully, most people will immediately define this, unlike average game time. Like game time, number of players definitely affects game balance.

If the game is based around teams of 2, and one character has the ability to disable another for a long period of time, that player will have a lot of power as he can reduce the power of a team by half, and potentially make combinations of that team's abilities impossible to pull of. Rather, if he was in a game where teams were of hundreds of units, being able to disable one is fairly pointless.

Similarly, Area of Effect abilities become more useful than single target abilities when teams get larger. Common sense.

Pretty much, make sure you know how many players will be playing, and how it will affect your game.

3. Player Skills - How much skill can a player apply to your game? And what skills in particular? Will your players have to out-aim each other, or will other skills be called into play?

If you haven't read my article about Skill Ceilings and Floors, I recommend you do so.

Remember how your effectiveness at your skill ceiling is equal to your absolute potential?

If a unit can reach their absolute potential, and it is far more effective than other units at this potential or skill level - you have an imbalance.

This one can be difficult to test, as you don't know how players will play until you have them playing and developing skills. Still, applying logical reason will at least lower the chances of massive imbalance if players formulate unexpected play styles.

First off, know your genre and how it's played - if you're making an FPS, know that there are Quake players out there who will hit players in the air with rockets from half the map away, and there'll be Counter Strike Snipers who can hit a head with less then half a second exposure.

Research other games and skill levels of players who at the top of these games.

Another concept to understand is... simple inbuilt restrictions. Cooldowns on abilities means they can't be spammed as fast as a user clicks a button. Move speed limits means a player can't zip around the map as fast as they can hammer the WASD buttons.

I feel like I'm babying you all, but - well, if you introduce simple time limitations on each action that require it, you're not going to have strange bugs and combinations of actions that can result in imbalanced movements and attack strategies.

The last point relates largely to the first two - know your engine. If you're creating your own engine, your software designers are going to have to understand the game and what is and is not allowed. You need to communicate properly.
Make sure they are knowledgeable of similar games and bugs/exploits/etc. that were in those. You may want to make a list of possible problems, and you will need good communication to ensure no bugs pop up.

If you're using another engine, play the games that have been made on it- and test bugs yourself. If one has a large following, especially a competitive scene - ask them about any bugs that are due to technicalities in the game (they may call them 'Advanced Techniques').

4. Game Area
The playable area in game also affects balance. This is quite obvious - someone who can maneuver faster will be able to run rings around slower opponents in enclosed areas, while Area of Effect attacks are extremely effective in enclosed spaces.
To limit the effects of game area on your game, you can try to make neutral areas that don't particularly favour any character - this is best for games where a stage advantage will imbalance match ups and can't be compensated for with intelligent play or team strategy (such as fighting games, in which stage balance is required as it's 1v1 and games are often very close and skill based).

There are many other variables that you must consider - and they will definitely change for individual games.
Find these variables then define them and their impact on your game's balance.

Step 2 - Apply any simple balance strategies that will be used.
Balance strategies are theoretical approaches to game balance that don't necessarily rely on number crunching to balance.

1. Role-based Balance
Role-based balance is a widely used balancing strategy - or, at least, it should be.
The approach involves looking at your PCUs, and giving them very specific and different roles within a team - while ensuring that the more rounded PCUs do not encroach too heavily on these roles.
If done correctly, you have a range of units who are not only exceptionally different and appeal to different players, but you ensure that no PCU is considered useless the entire role is considered redundant (in which case you have quite an issue and you may need to refocus your unit).

2. Strength/Weakness-based Balance.
Strength/Weakness-based Balance is where you give every PCU a main area of strength, and an easily exploitable weakness. The weakness is the key balancing point here. With the weakness, the PCU can be outplayed and exploited by hopefully any other PCU, whose own weaknesses can be played on. Similarly, with the different weaknesses come different strengths - and so players strive to battle in their element. The winner is ultimately the player who exploits the other's weaknesses and plays on their own strengths best - or, if both players evaluate the situation properly (and so don't enter situations where they will be weaker), it is defined by other skills.

The only issue is that often encounters will thus be based on luck, and running into someone who's in the wrong place at the wrong time. To counter this, map/game awareness should be highlighted as an important skill to players - and all PCUs should have the opportunity to act on awareness and turn ambushes around.

3. Counter-based Balance
Counter-based balance basically says "If every PCU has a reliable way of countering a strategy, unit or move, less attention needs to be focussed on balancing individual moves, units and strategies."

This is true to a point - but, well, you obviously can't smack an easy-to-use OHKO on a single PCU and tell everyone to "just dodge it" (much to the contrary of what many gamers think). Similarly, this strategy has the limitation of not being usable for all games

The idea is that if counters are readily available, and every player and PCU has access to them - there are no situations in which a player will be totally overpowered by another equally skilled player unless there are ridiculous mistakes (a character starts with 10% of the HP of other characters) or bugs in the game.

A good example is in Guilty Gear XX - where characters have the ability to do such things as

Make their upper hitboxes invulnerable
Emit a force that pushes enemies away.
Do an immediate counter attack from block.

But that's not all, they can also use "Burst" which lets them totally break out of a combo if they are locked - counterattacking their opponent to break the combo.

Now here's the kicker - all characters have access to these moves. This means they have an array of defensive moves that effectively break them out of any situation, so, they always have a way of countering their opponent's actions.

Though, just so you don't read the above features of Guilty Gear and think people are unkillable turtles because they have too many defensive options, rest assured - every action above takes up 'Super' - meaning that you can't use them too many times unless you regenerate super by playing effectively.
The Burst actually uses up the Player's burst power, which regenerates slowly such that you will likely only get one burst per round. Also, if you fail to hit with a burst (which are fairly easy to block and punish), you lose all of your burst power, meaning you no longer have such a strong counter measure.
Pretty much, the game isn't too defensive - but every player has a lot of defence options to counter all imbalanced situations. This means you can have a larger variety of characters with a large variety of moves - with the potential for imbalance being far less than other games with a similarly varied roster.

Enough about Guilty Gear, anyway, I might make an entire separate post for it if I really feel like I need to give some praise for excellent balance strategy.

Step 3 - Develop expectations for a battle between two or three basic units.
Okay, so by now you're expected to know what variables will affect your game's balance, and you know what kinds of balancing techniques you can apply to your game (I also recommend you use one or create your own - think of what your game requires and what has been used in the genre.) - now you must highlight some basic combat situations and the outcomes of these situations.
Consider a couple of the units you wish to make, and say "X should be able to beat Y at close range, but should lose at close range" - or "X should be effective when pursuing this objective, but should be less effective when carrying out this task".
Do this with the most basic units - ones who are generally effective in most combat situations (for example a Sniper is not a good unit to start with because he sucks at close and moderate range combat, he is too much of a specialist).

A good idea is to use hit-counting and timing to describe exactly what you want to happen. This is not necessary, but useful of course.
If you want Unit X to kill Unit

Then you create these units in your prototype.

Step 4 - Test the match ups.
So you have your prototype and your units - you have your expectations for these units... let's get testing!
make
Play out several scenarios with the units and expectations in mind, and repeat them with slightly different positions etc. and make sure you're happy with the results - especially with regards to timing and hits.

If you're not, simply look at the values turning up, and see what can be tuned to make the match ups meet expectations.

As many scenarios as possible should be tested - but certain scenarios are well favoured over others.

You want to focus on common occurrences in the game - such as:

'Unit A counters Unit B. Unit B however has a slight level advantage over Unit A, and has ambushed the unit in favourable terrain at mid range - Unit B should win, but should sustain moderate damage (60% or so)'

This situation will arise.

However, there are obviously situations that are so unlikely that they aren't worth testing.

'Unit A counters Unit B, but has been afk for the whole game and so is still Level 1. Unit B is level 10 but ambushes Unit A in very unfavorable terrain at extremely long range. Unit B should still win without much problem.'

I think what I'm trying to say is, be thorough - but don't waste your time.

Really this is all just about controlled repetitions under different pretenses and tweaking the balance until it works well.

Repetition, repetition, repetition.

Step 5 - Alter until expected results are reached.

Ah I think I went over this in Step 4 with tweaking.

But, make sure you tweak intelligently. Make small changes, and make sure you clearly identify Variable Scope.

If you do this while tweaking, you should be fine. Save regularly, document and analyse any possible issues, test rigorously.

You know, all the good stuff.

Step 6 - Repeat step 3-5 for all other units, with reference to step 1-2.

Pretty much what we've covered so far - but more testing.

When you create a new unit - you need to know how the variables of the game will affect it (step 1), and if you have a balancing strategy in mind, you want to know how it will fit into that strategy (step 2), you want to know how it will interact with every other unit under different situations (step 3), you need to create and test these match-ups (step 4), then you need to make any alterations (step 5).

As said, we've covered it so far.

One little additional point I will make however is that as you create more units, the number of things you have to test increases and increases.

Think of it this way in a shooting game with 2 units you need to test perhaps 3 main situations - long range, medium range, close range.

Then you might want to test these in 3 areas, open area, moderately spaced area, enclosed area. That's 9 tests.

Let's add Unit 3 - you need to test him with 1 and 2 in each of these, so that's 18.

Perhaps units can be on teams, how will 2 unit 3s match up with a unit 1 and a unit 2.

What if unit 3 can choose between 2 weapons? What now?

As you add more and more, and there are more and more variables - the number of situations you need to test is astounding.

This is where balancing strategies come in.

The reason I recommend using balancing strategies is because they reduce necessary testing a bit - or, at the very least, aid it greatly.

This sounds awesome. But... well, let me be very clear.

You still need to test.

You still need to balance.

You still need to analyse.

I know some game designers that have taken a very devil may care attitude towards balance and testing because they think a balancing strategy will do all the heavy lifting for them.

"Hey, it's okay, we can do X because character Y still has a weakness to Z!"

No.

You're not allowed to arrive at that conclusion, unless you've done a lot of testing and analysis to come to it.

Don't get lazy.

Even with balancing strategies, I still test everything rigorously. Why? So I don't overlook an obvious problem and have to eat my words later.

Step 7 - Test over and over and over whenever changes are made.

This point has likely been sufficiently covered as well.

If I want you to go away with any knowledge after reading this blog post, it's constant testing is key to balance.

Conclusion:

This blog post was actually written over 2 weeks and had many paragraphs added and deleted over the period of writing, so frankly I'm just hoping it ties together nicely - but here's what I want you to go away with.

Follow the 7 step process. If you follow it properly, and can follow the steps in reference to your game design - you won't miss a thing. Just know your game type, what variables will affect your balance, and possible balance strategies than can be applied and you'll be fine.
Testing is key to balance.
While balance strategies ease up on testing thousands of situations, don't even think of being lazy with it. You still need a lot of testing.
If you're designing, do a lot of testing. If you're a programmer, get your designer to test. Designers often know what should and shouldn't happen, and how long it should take - or at least have a good idea of this.
Setting up balance takes a lot of time, and must happen from the first prototype and units made, right through to the end. If you start too late, you'll likely need to totally remake some systems that would have been visibly problematic from the start. If you consider balance until the end, you'll likely have to backtrack changes.
A monkey who understands balance scope and tweaking, testing a game for an infinite amount of time will eventually create a perfectly balanced game. Basically - don't give up. Keep testing, and thinking, and you'll get there with some hard work and ingenuity.

Anyway, thanks guys. I'd like to go in-depth for some balancing strategies.

Here's my to-do list for the moment:

Pacing
Single Player vs. Multiplayer Balance Concerns
Balancing Strategies in Depth
Canon vs. Gameplay
Untitled Puzzle-Horror game idea.
Untitled Puzzle-Adventure game idea.

I'll keep you all posted.

The Scope of Game Design (Refining the Problem)

2010-02-15T02:56:00.000-08:00

Well, first off, I know you guys were all expecting a post on how awesome Knarf is - but to express that would take me too long to possibly contain in just a single blog. I would have to make volumes of blogs to cover her awesomeness.
(For those who don't know Knarf, she's an artist at the AIE :D)

Clarification

This blog post is what was originally going to be named 'Conservative Game Balance' - but I realised that I don't believe in conservative balance at all.

I believe in making the right changes.

This implies, of course, not making stupidly over the top alterations to systems that only need basic alterations. That is the meaning of conservative right there, but conservative also implies a resistance to change - and that goes against everything I believe in.

If there is a problem, I won't water down the solution to be "more conservative".

Introduction to Scope

So the title has been changed. I want to talk about Scope today.

Scope in game balance are the different environments and features of game play, and units in a game. They are areas related to their effects on gameplay, in order of importance. This makes it essential for refining balance problems - so you can fix them in the most effective way possible.

A High Scope Context relates to a feature that, if changed, will affect a large amount of gameplay - for example, if 90% of characters in a game use swords, and you change the strengths of swords, you are dealing with High Scope as it affects a lot of the gameplay.

A Low Scope Context relates to a feature that will affect a small part of the game, for example, changing a character's stats will only directly affect that character.

I borrow the term from the scope of a variable in programming - as they are very similar. The scope of a variable in program determines how much of the program can access it, while the scope of a balance issue or change relates to how much of the game will be directly affected. Just as you want to use the lowest scope possible when dealing with variables, you want to deal with the lowest scope possible for a game change.

The easiest way to figure out the scope hierarchy is to see how units are categorised in the game. If units are defined by their weapon (e.g. Rapier, Pirate and Warrior are all 'Swordsmen'), then the weapon is likely of a higher scope than the class's traits. If you change the weapon, it greatly effects all of them.

On the other hand, if if all weapons are character specific (that is, changing a weapon doesn't affect any other classes), the weapon is of a lower scope than the character.

Why Determine Scope?

The Scope of a balance problem is essentially its location in the system, and how much of the game the problem affects. A problem of a single's characters stats being too low is low scope, while a major weapon type being too powerful is high scope.

Effectively finding the scope of a problem involves narrowing down the overall problem to its absolute core. You want to find the lowest Scope of the problem, and fix it there.

e.g.

"X is overpowered" --> "X's weapon is overpowered." --> "X's weapon's fire rate is too high".

The weapon's statistics are considered the scope of the problem (not the character), and so that's where you apply the solution (reducing the fire rate).

The basic idea of finding Scope, and refining the problem is to prevent issues where someone says "X is overpowered", and you nerf the wrong features, affecting large amounts of content in the game.

When balancing, you want to change as little as possible.

To get the perfect solution, you need to seek the core of the problem.

Real Project Application

This post came from my work on Pokemon Universe - in which we are trying to balance Pokemon to be viable in higher levels of play.

To balance each Pokemon, there are a huge number of variables we could change:

The traits of the Pokemon's types.
The Pokemon's types.
The Pokemon's stat spread shape.
The Pokemon's individual stats (HP, Defense, Attack, Special Attack, Special Defence, Speed)
The Pokemon's ability.
The Pokemon's move pool.
The Pokemon's optimal move sets.

And there are an amazing amount of changes that can be applied to each variable - and so, we need to decide on what needs to be fixed.
We must also determine the scope of each variable, as we want to change as little as possible.

The highest scope variable in this situation are the traits of a Pokemon's types.
if you were to change the Water type to have fewer resistances, you would affect all Pokemon of the water type.
After that you have the Pokemon itself, as an individual entity. As we are trying to fix individual Pokemon, this is the ideal scope to work in, but there are lower scopes for a Pokemon's individual problems. We need to delve deeper.

Now, Internal Scopes (those that will only affect the particular unit) are prioritised according to how much they will affect that unit - in terms of identity.
It is strongly believed that when you create individual units in a game, they should be more than just rehashes and clones of other units. They should have their own strategies and moves - so players feel like they are experiencing a new character, and so this character may fill a niche in the player's playing style.
For the most part in game balancing, you want to preserve identity. If you were to aim to change the identity of a unit, the change would be called a remake.

The greatest variables that determine a Pokemon's identity are its type combination (evaluates the Pokemon's type matchups, and the over all themes of the Pokemon), its over all stat spread (define the unique traits of the class and its role), and its optimal move sets (which determine what the Pokemon can do, and its role).

I would consider all of these equal in priority - and you generally want to preserve them all as much as possible.

That said, if you go through the lower scope variables, and you find that the problem is not in the Pokemon's stats or move pool - you do need to look at (and possibly change) its higher scope traits.

An example of such a problem is in Pokemon is where certain 'Walls' (for RPG players, tanks) hav exceptionally bad type match-ups, such as being weak to water and ground, being some of the most used and effective types in the game (hey there Rock Pokemon). A pokemon with this type combination has no viability as a Wall as it will fall very easily to any well rounded team.
For some types, stats can make up for these problems - but for others (such as the above example), the type combination must be changed (or the Pokemon needs to be reallocated to another role).

Identity vs. Viability?
The example above is a situation in which you have a choice to make a Pokemon useful, or keep its identity completely intact.
Personally, I prefer to increase the standard of gameplay - I will cover this argument in full when I do my Gameplay vs. Canon article later.

There will be times in which you need to make a big change to fix a big problem, and so you need to ensure you find the best scope to fix the issue. Don't immediately dismiss a fix because it alters the higher scopes, unless you already know those scopes are best left unchanged as they affect too much of the game (such as the relationship of types in Pokemon.)
That said however, sometimes big problems have big solutions, it's your job to have a balancing strategy that catches these issues earlier rather than later.

Thanks, I hope I explained the concept of Scope well enough.
Zanda.

Quick Update

2010-02-14T03:07:00.000-08:00

Well, life has exploded.

I am at college 3 days a week, and I work a day a week, leaving me 3 me-days.

On my me-days, I work on balancing Pokemon for Pokemon Universe when my Balance Team is on IRC, I work on The Undeadables (more about that in the next paragraph!), and I write for this blog.

I have also started playtesting for a local company called Convict Interactive, but I can't give out information due to the NDA. Exciting stuff from them, anyway. Visit their site: http://cg.stephenbarnes.net/

Sooo I'm busy with all the design and game-related stuff, but I love it. I've always liked designing games more than playing them - and well, I'm not missing gaming too much.

But yes - The Undeadables is in production as a Warcraft 3 map. It just myself and my friend Alex Hewitt (who made 3D images for the Undeadables video), but we're going okay. We started development on Friday - and we've already hit a couple of snags to do with subterfuge vs. in-game communication, but Alex's knowledge of the Warcraft 3 engine is driving the project. We will likely be working on the game once a week. So, there will be some updates on how we're setting up the balance and sorting out issues in that project.

Anyway, I have 4-5 blog posts planned:

Pacing (a theoretical post)
Balance Concerns Across Different Genres (I promised this one a while back)
Canon vs. Gameplay (the problems with games and their pre-existing universe)
Setting Up Balance (in depth strategies to starting a balanced game)
Conservative Game Balancing (how to ensure minimal effects on the entire game when balancing a particular unit)

Pacing is just one I find fun, and Setting Up Balance has a lot to do with The Undeadables - as myself and Alex are trying to find magic balance numbers from scratch.

Conservative Game Balancing and Canon vs. Gameplay are both very much to do with Pokemon Universe. In that project, myself and the other Balance Team member (Gammal) have to isolate problems in Pokemon, so only that Pokemon is affected. We are trying to be as conservative as possible, to ensure we don't cause larger problems in the game.

Canon vs. Gameplay is an issue I've found in the project, as, many members do not want the Pokemon to change at all, as it will interfere with existing canon. As a firm believer of Gameplay > Canon, I will be listing reasons pertaining to why you should try to preserve Canon, but when change is needed for the sake of balance, or in the name of fun, you shouldn't hesitate.

Balancing Pokémon

2010-02-05T02:59:00.000-08:00

Now it's time for the second post of the night. In the morning. Sorry - I started this post but couldn't finish it due to the length. This one, like the other, is pretty tough.

I have undertaken a project in which I want to balance the Pokémon metagame as well as I can.

Note that I haven't even really started on this problem yet - I'm currently developing a tool that will greatly aid me in what I'm trying to do - but, without further crapping on...

Analyze the problem. (remember the brilliant 2 step problem solving method)

Pokemon faces 80% content redundancy.

No joke. Don't ask me how Nintendo let it get that way - but anyway, that is ridiculous. Most companies would freak over just 10% redundancy - but okay.

Now, remember to refine the problem - we can't magically make a solution that fixes "80% redundancy" without more information.

Refining The Problem

There are a multitude of balance problems in Pokemon:

A vast majority of Pokemon do not have the stat totals to be competitive.
Most Pokemon don't have a favourable stat spread that allows them to be competitive.
A lot of Pokemon don't have the movepool to have viable movesets in competitive play.
Some types are unfavourable in comparison to others.

As most of these issues are Pokemon based, it is probably best to leave types out of it for the most part - unless particularly problematic moves are found (hello, Stealth Rock).

Now, there are 2 main categories of change I can make -

Buff the weak Pokemon
Nerf the strong Pokemon

#2 is a bad idea, because the strong Pokemon have a really dynamic and fun game going on right now, ripe with strategy and counter strategy. Nerfing them and removing the viability of these strategies used would be a hit to the game.

Similarly, there is no stable metagame below the standard metagame we have now. There is the UU tier metagame, but it has been unstable with Pokemon entering and leaving it since Gen IV was released.

Similarly, there are a large amount of Pokemon in the NU tier than must be buffed to even be useful in UU. Merely weakening the stronger Pokemon will not change the majority of their viability.

So, we should buff the weaker Pokemon.

Choose a Balancing Strategy

Due to the scale of the problem (rather than looking at one unit, we're looking at around 230!), it could be a smart idea to consider options such as algorithms that will immediately scale all Pokemon stats to a certain total, while maintaining their stat spread.

This does not take into account Pokemon with amazing movepools, who are already competitively viable with their stat sets, and other Pokemon like them who may become too powerful if their movepool is too compatible with a large stat gain.

So - this will often attempt to solve problems, that aren't apparent for some pokemon.

Similarly, it will be necessary to scan over all affected Pokemon, to try and look for potential imbalances with movepools, or, problems that have simply not been solved, like Pokemon with bad movepools and pokemon with poor stat spreads (having all of your stats piled into Defence and Special Defence, with no HP for example is an awful stat spread).

Either way you'll be scanning over all Pokemon, still trying to fix imbalances on the majority of them - and a lot of them must be implemented into a game engine to find (with such large changes, testing is even more needed).

Basically, while trying to save time with a blind algorithm, you're ignoring 3/4 problems, and fixing the 1st problem, even when it isn't a problem - causing you to need to iterate over every Pokemon anyway.

So if we're going to be going over all of the Pokemon anyway, we should analyse the problems with each Pokemon and treat them accordingly.

1. A vast majority of Pokemon do not have the base stat totals to be competitive.

This problem is fairly self-explanatory, and it can be rectified by scaling up base stats to less terrible levels.

Chances are, you'd buff the lower stats to a more acceptable level to start (approx 65), and then see if the Pokemon needs to have more specialised stats (taking them to perhaps 110 or so) - leaving the rest in the 70s-80s.

A general guide to go by:

Less than 50: Crippling. The Pokemon likely is useless because of this stat. Ridiculous other stats (255hp Blissey for example) are the only things that can make up for this.
50: Bad. Your Pokemon has to make up for it with other stats.
60-70: Passable, this is 'Okay', it will be a weakness of your Pokemon, but it won't cripple it.
75-85: Positively average. Most good pokemon have the majority of their less used stats around this level.
100: An important stat to the Pokemon. Well in the good range.
120: Considered a great stat.
130: The Pokemon is likely heavily based in this stat.
Greater than 130: The Pokemon probably heavily gives up other stats for this stat.
Greater than 160: The Pokemon is probably so one track stat wise, it suffers in the majority of other areas, if the Pokemon is weak, its stat spread likely needs to be looked at.

2. Most Pokemon don't have a favourable stat spread that allows them to be competitive.

Some Pokemon may have the right stat totals, but their stats may be spread out in a way that is very unfavourable. Some may be when the Pokemon has all of their stat points rather evenly distributed - 85 in every stat is great, the stat total is 510 - nothing to laugh at, but, the Pokemon can be considered plainly bad, relying on the features of their movesets to be useful.

A lot of these Pokemon would be better if they had some of their stats standing out more than others.

Another issue to do with averaging, is when a Pokemon has equal Attack and Special Attack, but only really has Physical (or Special) moves to work with. A lot of Pokemon are better of specialising in just one.

Another problem with stat spreads is... just really bad stat spreads. Let's take a look at the Pokemon Shuckle.

Hello Shuckle!

His stats of note are:

Defence: 230

Special Defence: 230

Wow! What a tan... wait... hold on...

HP: 20

What?!

This Pokemon suffers from possibly one of the most redundant, useless stat sets. So much defence, but no HP to back it up.

In fact, mathematically, if you were to change Shuckle's Defence to 165, his Special Defence to 165, and his HP to 60 (-70 stat points in total), he would have far better survival - despite the apparent stat nerf.

Let's not forget that Shuckle's Speed is 5, and his Attack/Special Attack are both 10 - and you're looking at an awful stat spread.

Your stats should properly reflect your role. A tank isn't a tank without good HP, and such.

To fix this, derived stats such as 'defence indexes' are useful, for finding more optimal arrangements of stats.

3. A lot of Pokemon don't have the movepool to have viable movesets in competitive play.

Some Pokemon have great stats - but moves that don't compliment them, or, bad moves in general.

A Pokemon should always have moves that support its role, and then a few that can be used to surprise the enemy, or create a slightly different play style. Simple.

If you're a tank, you should have moves that weaken the enemy team as they fumble to kill you, if you're a sweeper, you should have moves that allow you to hit the enemy hard. If you're a supporter, you should have moves that help your team.

If you are a tank, with low offenses (like Shuckle) and all you have are offensive moves, you are useless as you cannot perform your role.

The best way to balance movesets it to analyse other movesets of Pokemon with similar roles.

Let's say I got Shuckle's stats right, but, found he did not have a proper moveset to make him a viable tank. If I copied the features of a more effective tank's moveset into his, he would now be effective.

Solution: Single Target Analysis with Archetyping

I have picked my solution.

The best way to create balance in Pokemon, is to iterate through every single bad Pokemon, and analyse it heavily. I need to find its weaknesses, and fix them according to the balancing procedures outlined above (primarily stat analysis, and copying archetypal movesets).

While I plan to compare bad Pokemon to good Pokemon in order to find weaknesses in roles and movesets primarily - why stop there?

Archetyping is the practise of finding strong units, and latching onto them to base weaker units. You basically, make the weaker unit look statistically like the stronger 'Archetype', but also try and have it keep in tough with its own identity and nuances. The result, is, more often than not, a strong unit who performs their role properly, but still very much has their own identity.

If I make archetypes of each role (Physical/Special Sweeper, Physical/Special Wall, Staller, Support, etc.) - and compare these to the weaker Pokemon, and then again after the Pokemon has been buffed - we can get a good idea of the balance of the Pokemon.

Coupled with proper analysis, the Pokemon will be viable in no time.

Hopefully I can make a big difference to the Pokemon metagame, and increase the viability so that players can still fight with their favourite Pokes.

Wish me luck.

Skill Ceilings and Floors

2010-02-04T23:36:00.000-08:00

Well, I have a night to update, and, people have been asking me when I plan to post - so I am posting now.

I have been at college, and occupied with other projects and commitments (hello, shuffling work shifts to not be when I am 2 hours away learning) - and so, well... hey.... I don't have to make excuses to you guys. >:[

Anyway, long story short, 2 articles tonight, this one, which is mainly definition, the other a more practical problem.

Player Controlled Units

Also, it has come to my attention that a very helpful term being used to describe a 'player controlled character or class' is a 'Player Controlled Unit' - a PCU for short. I plan to use this as I am sick of having to make the distinction. The term is also of great use because it can be used for any game I can think of, even ones where class and character don't work (such as in Space Invaders - where you don't identify with the unit (not a character), and it is not in a series of classes) - it can even be used to describe weapons. So, now you know what a Player Controlled Unit is.

On to the post.

Skill Ceilings and Floors

Skill ceilings and floors are terms given to the skill levels at which a player controlled unit is capped by the game mechanics. They are often mistakenly used to describe the effectiveness of a unit at various skill levels.

These terms are extremely... murky (in a word). They are poorly defined, and, are often used incorrectly - leading to somewhat of a double meaning.

I will try to clearly rectify this, but, I may fumble with my words a little and edit the post several times to make the point clearer.

On to the definitions!

Skill Ceilings

Skill Ceiling - This is the term for the maximum amount of skill that can be applied to a player controlled unit with regards to its technical limitations.

Similarly, you can say that it is the point at which an additional application of skill will yield no additional effectiveness due to the limitations imposed on the unit through the game mechanics.

If you play at the skill ceiling of a unit (you apply the maximum effective skill to it), the effectiveness reached is considered the absolute potential of the unit.

This is where I draw the distinction between the two 'definitions' of a Skill Ceiling.

If you play at the Skill Ceiling (skill cap) you reach the unit's absolute potential.

This does not saying anything about the effectiveness of the unit, aside from that its absolute potential has been reached. Even if the unit has a high skill ceiling, and you reach its absolute potential, it may still be ineffective - this is a problem, as the player is not being rewarded for his skill.

I repeat, reaching the unit's absolute potential does not actually definitely say anything about how effective it is in practice. This is where the definition problems arise.

An example of a high Skill Ceiling is in shooting games, where an accurate weapon compliments player skill greatly - and players are expected to become more accurate when aiming, and aim faster to reach the high skill ceiling. This is an impossible skill ceiling to reach however, as the rate at which a player can react to an enemy threat is limited to the slow human reaction time, when compared to a computer's reaction time - seen when a player uses an aimbot. In this situation, a skill ceiling is actually limited more by the human than the game mechanics put in place.

If you were to lower the accuracy of a weapon or give it a large damage falloff over range, you would lower the skill ceiling of a weapon, as now regardless of player skill, they cannot properly attack at longer ranges (which in the majority of games takes skill), and aim is less significant due to the lower accuracy (aim takes skill).

So how does this relate to game balance?

The main message here is that it doesn't define the unit's power. It affects balance of the unit on the skill vs. power issue (I will talk about this issue at another time), but saying that a unit has a high skill ceiling does not make it a powerful unit. You could have a weapon that takes massive amounts of skill to aim, but it can still shoot bullets that deal 1 damage.

It should be noted however, that when you discuss the overall balance of a unit, you will usually be discussing its absolute potential, rather than its potential at lower skill levels (you want to eliminate skill from the equation, which applying a skill ceiling does) - and so, Skill Ceilings also apply in this scenario.

Also, It is often ideal to try and balance all unit's potential at each skill level.

Skill Floors

Skill Floor - The skill floor is actually the opposite of the skill ceiling, it does not concern the application of a large amount of skill, but rather, a lower amount of skill. Due to the floorlessness of a realistic low skill setting (the lowest skill level is not inputting commands, but that's useless), Skill Floors are often directly tied to effectiveness when being discussed (they are useless to us otherwise).

Again, I will make the distinction between effectiveness and the meaning of a skill floor.

A Skill Floor is the application of the amount of skill yielded from the lowest amount of experience with the unit, game, or genre of game in question.

The reason why I mentioned experience was to eliminate the issues surrounding the floorlessness of low skill settings. Basically, we're talking about new players to the unit, game and genre.

Now, I will just get this out. There is no such thing as a high or low skill floor.

While the Skill Ceiling quantifies "How much skill can be applied", a Skill Floor is the opposite. "How much skill can't be applied" doesn't make any sense, nor does any other opposite trying to measure a valuable. You can graph a skill ceiling, you can't graph a skill floor (it's effectively 0 with our current definition).

So why would we bother talking about skill floors? We talk about a unit's effectiveness at its skill floor.

If a unit is highly effective at its skill floor, it is considered to be imbalanced with reference to skill (this is that thing that's coming later).

A unit that is considered ineffective at the skill floor is... well... normal. Nothing more needs to be said.

So remember:

There is no such thing as a high or low skill floor.

When discussing a unit's skill floor, you must mention its effectiveness at this skill floor.

Skill Curves

Using these measurements, we can make a Skill Curve (not to be confused with a Learning Curve or a Skill Aquisition Curve (used in RPGs to map when units get spells and such))

A Skill Curve is as such:

The vertical axis is Effectiveness (what we are measuring).

The horizontal axis is Skill Applied (what we are given).

The 'Skill Ceiling' is a constant value of applied skill, found at the maximum of the horizontal axis.

The 'Skill Floor' is a constant value of applied skill found at the minimum (0) of the horizontal axis.

In most situations, 0,0 is not a point on this curve, as even unskilled players are often at least a *little* effective with a difficult unit. If they weren't, there would likely be very little development in skill before a player gives up.

So we have:

Adding a typical Skill curve, we have

Note the X, that is what's known as:

Peak Skill - Peak skill is a common point found on Skill Curves that denotes a point at which the player will reach a point where any increase in skill results in a negligible gain in effectiveness. It's not a peak really, as the effectiveness doesn't turn downwards after this point (that would be dumb) - but that's just the term for it.

The Peak Skill doesn't really mean much when it comes to design and balance - though, as with all points on the Effectiveness vs. Skill Applied graph, it's ideal to have them all in similar places for all units in the game.

Conclusion

Anyway, that was possibly one of the toughest posts to write - due to the confusing nature of the terms, just remember:

Skill Floors and Ceilings are values in skill, not measures of effectiveness at their respective skill levels.

Thanks.

Maintenance

2010-02-01T10:52:00.000-08:00

Hey guys, haven't posted in a while - but I started at the AIE yesterday and I've been working.

Turns out, the costs of getting to the AIE each week really cuts down on the money I'm making. Dang.

But I'll update soon, probably Thursday night.

The Internal Balance of the Pyro

2010-01-24T01:08:00.000-08:00

Well, first off, I'd like to return a shout-out to Shadowfred - my friend Scott.

His goal is designing or programming games, both if necessary - so he's kind of similar to me, except I'd rather take the programming route into just design.

Anyway, he's working on a game called Jungle Hat Madness 2 - and he'll be updating his blog with progress, so, give it a look: http://shadowfred.blogspot.com/

Anyway, a few people really liked my Undeadables article as it has a more practical display of design philosophy. Rather than me just saying "you should do this" and "a balanced game should have this", it dealt with a real example where I had to solve some issues with an idea I have loved to develop. It was a little tricky though, as, when you hold an idea close to you - it's hard to be critiqued on it, and it's hard to steer it in a different direction to what you had set in mind.

The Internal Balance of the Pyro

Anyway, I want to make another practical post today - as they're always useful as demonstrations, and today's relates to Team Fortress 2 - and the internal balance of the Pyro.

I use the term Internal as I did with Internal Content Redundancy - in the way that it relates to the options given to the Pyro when not in actually actively engaged in gameplay - so it reflects his choice of items, mostly.

The Problem

The Pyro suffers from great Internal Content Redundancy - but, well, first we'll just lay down the basics for the Pyro - so those who don't play Team Fortress 2 can understand.

The Pyro is a close range ambush class, who has above average health (175), with average movement speed (100%).

The Pyro has 6 weapons, 2 Primaries (Flamethrower / Backburner), 2 Secondaries (Shotgun / Flare Gun), 2 Melee (Fire Axe / Axtinguisher).

The Flamethrower has the Airblast ability that can reflect projectiles (mainly rockets), disrupt enemy movement (even if the enemy is invincible in an Ubercharge), and it can extinguish burning teammates. The Backburner - the other Primary that can be chosen, loses the Airblast but gains critical hits when attacking the enemy's back. This is supposed to function primarily as a strong ambush weapon, while losing the utility of the Flamethrower.

The Backburner is widely considered to be inferior to the Flamethrower, and the Fire Axe is considered to be inferior to the Axtinguisher (The Axtinguisher has a strong killing ability and combos really well with the Flamethower's airblast - the Fire Axe has nothing of the sort). The Flamethrower and Axtinguisher are considered balanced - so this is not a matter of nerfing those.

The Backburner is redundant because the trade-off the Pyro makes is unfavourable - he loses defence and support ability for ambush ability - that he unfortunately has great trouble utilising.

I'll put it into perspective - there are 3 specialised ambush classes in Team Fortress 2: The Scout, the Spy, and the Pyro.

The Scout is able to ambush effectively, as his speed allows him to trespass effectively, getting behind key players. His small frame also helps with hiding in wait.

The Spy has the cloak ability, which makes him completely invisible, allowing him to sneak past enemy lines. He also has a slender frame - allowing him to hide around corners more effectively.

Redefining the Problem:

The Pyro doesn't have the speed necessary to function as a Scout, and he of course doesn't have the Spy's cloak - the only thing he does have is his higher health (both Scout and Spy are 125hp classes). This often means that the Backburner Pyro has to battle and push his way through enemies to get around them - which doesn't work as he makes himself known (subsequent ambushes are less likely to succeed), and with his lesser combat ability due to the loss of the Airblast - it often means he dies trying to get around the enemy team.

So he needs a change in his ambushing ability - you can either increase his capacity to push through enemies - or change his style of ambushing from pushing to stealth, or speed-oriented maneuvering.

Now, if you read my post on Content Redundancy - you're likly thinking that we should increase the Pyro's pushing power, so that he doesn't encroach the Spy's stealth or the Scout's speed. The only issue is - Valve saw this issue with the Backburner when they released the Pyro update and included a +50hp buff on it, so the Pyro could survive to get behind the enemy team. This however had the side-effect of making the Pyro too effective in general combat, so rather than ambushing, he ran right up to people instead of flanking. This health was promptly removed as it upset the class balance of the game (this is actually something I'll talk about in another post - conservative balancing).

The Solution:

Anyway, with all this in mind, hopefully we have enough information to create a list of criteria and constraints.

The fix should increase the Pyro's ambush ability, while not doing any of the following:

The fix should not increase the Pyro's combat ability (as that will lead to a more combative playstyle rather than an ambush focused play style)
The fix should not be a general buff to the Pyro (it would upset class balance)
The fix should not heavily affect the Flamethrower or Axtinguisher (They don't need more power, or to be nerfed - more options are good though)
The fix should directly address the issue of the Pyro's lack of ambush ability.
The fix should not encroach on other class's roles and special traits.
The fix should not heavily change the Pyro, his role, or the primary abilities of the weapons at hand.

At this point, I'd like you to try and think of your own fix before reading about mine.

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

My Solution:

Okay.

My fix was a little roundabout.

First of all, I thought that the Backburner should have access to a 'mini-blast' of sorts - which is a small burst of air activated by right click (costing maybe 5-10 ammo) that merely extinguishes teammates. This is just so the Backburner can be used for some support - without your allies wanting you to use the Flamethrower so you can extinguish them.

Second, I decided that the best way to increase the Pyro's ambushing ability was to increase his speed. Frankly, as we covered - wading through enemies to ambush them is pointless, and leads to imbalance when you try and increase a class's defensive abilities. Also, we couldn't give the Pyro any amount of cloak, as it would severely encroach on the Spy's role, and it wouldn't fit with the Pyro at all.

But, I'm not saying that I made the Pyro faster all the time. I made him faster not when he was holding the Backburner (that would be a general increase to his combat ability) - but when he was holding the Fire Axe.

This means that, when the Fire Axe is a Pyro's active weapon, he runs somewhat faster (not nearly as fast as a Scout - that would be encroaching) to get around his opponents.

Justification:

You might be asking "But Zanda - isn't this a bad fix as it doesn't fix the Backburner directly - but complicates things by solving the issue through a different item?" - I know I asked myself the very same question.

I decided that there was no real issue with the Backburner itself aside from its lack of utility. Its lack of movement disruption and inability to reflect projectiles can be made up for with the crits from behind. The main issue, however, was the Pyro's lack of movement ability.

So - rather than considering this a fix to the Backburner, I would consider this a fix to the Pyro that arises from the analysis of the failure of the Backburner - that subsequently increases the Backburner's viability in general play.

The other plus side of it being assosciated with the Fire Axe, is that the Fire Axe was considered redundant and now hopefully will not be, but also, Airblast Pyros who would prefer movement ability over their powerful Axtinguish combo may also use it.

You may say that this makes Airblast Pyros more powerful, but truly, it doesn't. As said, they lose the Axtinguisher Combo - but they also don't gain a lot from being faster. The Flamethrower without the Axtinguisher isn't amazing for ambushing, but also, while moving, a Flamethrower Pyro will often hold the Flamethrower so he can airblast projectiles away. Obviously you can't hold both the Flamethrower and Axe out at once, so, there you go.

The final point I need to address is that this doesn't really affect his combat ability, or class balance as he must have a melee weapon as his active weapon to get the speed boost - which is easily beaten by most classes - the main class that would have trouble is likely the Sniper, who shouldn't be in close combat anyway.

Well, truly, as the Backburner is a close range weapon - most classes would think themselves lucky that the Pyro's holding the Axe and not it anyway.

So, feel free to post your solutions, I hope you liked mine - as it's what I have implemented for my TF2 Mod.

The Undeadables

2010-01-23T00:03:00.000-08:00

Well, I just want to introduce you to a project that myself and a friend at school (who is also going to the AIE) thought up, called the Undeadables. It's a multiplayer small-squad RTS, in which the players control mafia bosses and their henchmen, as they fight against a zombie apocalypse and amongst themselves.

Anyway, I submitted this idea to the AIE GameFace Competition:http://www.aie.edu.au/gameface/index.php

And was lucky enough to take out first prize.

Also, speaking of the AIE, I start there on the 1st of Feb!

Anyway, here's a link to the video I submitted to the competition:

The video is 2:59 because there was a 3 minute limit. If there weren't it would have gone for a while longer so I could really get into the details - which I may do on this blog.

Feeback:

And, one of the judges (a Game Designer from Big Ant Studios) gave me some feedback:

" I like the idea of a Mafia vs Mafia game, with an environmental factor (the zombies) being unaligned and just nasty across the board.
My main suggestion would be that the zombies are NOT the main enemy. The idea for each mafia team would be to eliminate the other mafia teams to get their all-important territory, and defend themselves against zombies in the meantime, clearing their areas of zombies as they see fit.

Actually using the zombies in your fight could be a great mechanic. Trying to flood an enemy territory with zombies by filling it with zombie attractants could be a good strategy. Maybe some items attract and some repel zombies, and these resources would be hard to get, constantly in threat of being stolen by the other Mafioso, etc.

In shoot-outs, it will be inevitable that Mafioso will have to shoot zombies to defend themselves, which ultimately helps their enemy Mafioso – it’s a passing necessity, not an active act of working together. Again, the zombies would be a shared environmental threat, not the core focus.

I don’t think you should have the mechanic of ‘shoot zombies to earn money to buy upgrades’. It’s an artificial gameplay mechanic that doesn’t fit the theme. Mafioso (in the real world) gain money through killing, stealing, and so on. Work THIS mechanic into the game, if you need a system of money to buy/acquire resources.

What’s the single main objective? Defeat the zombies or defeat the mafia bosses? It’s always highly dangerous to have two goals. Find ONE win criteria, and work around that.

This game ranked first for me, as there’s a game in it. I think it needs reworking and refocussing, but there’s a game here."

There are some places where he hits the nail on the head of what I tried to get across with my video, but didn't quite get there due to the time limit, but, here's my response.

Response:

I agree that you do have to be extremely careful with having multiple goals - such as, defeating the zombies or defeating the mafia. You don't want to overwhelm players, confuse them, etc. For that reason I think I agree with the judge - that eliminating the enemy Mafias should likely be the higher priority goal - as this will have the most PvP-action, and will therefore be the most engaging.

I think, when drawing up the concepts of the game - the main objective was not actually to fight either of them off specifically, but to survive. This insinuates that you could just flee and hide for the duration of the game, so I created obstacles to draw them in - such as the necessity of killing zombies to get upgrades, and killing zombie spawn points to slow their growth.

As I've already mentioned - the zombies solve such a huge amount of issues that would be common in this sort of game, and so it's hard to make them a secondary objective.

Some reasons behind the zombies are:

They force players into action (as already explained, so players do not just hide until the others die)
They stop, or at least, postpone relentless deathmatching.
They provide an eliminated player a second chance to redeem themselves - and make it so they don't just leave as soon as they are eliminated.
They can be used as a weapon by players. (I like the Designer's idea of attractive items)
Well, the game actually started as a zombie game - the PvP only came in after. Not really a design call as much of a personal call.

Though, I agree that we must sort out the focusing - such that the player is not overwhelmed.

Ways to do this, could be by making a zombie win condition that is easy to keep down for the most part, challenges players in the early game - especially when it comes to deciding whether to engage another player, while playing a small part in the late game.

As the players attain higher power in the late game, a counter can solve this - where, if the counter reaches (for example) 500 (there are 500 zombies on the map), the zombies automatically win. The growth rate of the zombie army can be adjusted so that players more or less need to spend their early game mostly killing zombies, and, as they grow and take out key zombie spawns, the zombies become far less an issue.

The idea is that at some point, the priority of killing zombies, shifts to being a lower priority than seeking out other players and attempting to injure them. Zombies remain in the game, and a threat - but by the end of the game, you're not being overwhelmed by both Mafias and Zombies.

I also agree that the money system feels a little tacked on. It could likely be largely replaced by a measure of experience (the player does need to attain power) and the foraging system referenced in the video. As experience is a particularly... disbelief suspending mechanic, for this game it could perhaps be replaced by money (merely a change of name) - which, through the leveling up process, attains new skills (which can be referenced as weapon upgrades).

When I think of a Mafia in a comedy game, I think their greed is a major character feature that should be highlighted. Hell, it's why they're all killing each other rather than bunkering up in peace!

Through the adoption of the experience mechanic, with some slight stylisation, we just eliminated the need for a shopping system - while keeping the mechanics needed, and the themes of the game.

Anyway, that's the end of my reflection - and the designer who reviewed my game definitely knows what he's talking about, and through his ideas - I could refine my own.

Being able to use constructive criticism is a valuable trait that designers use to refine their game ideas, and please more people. A lot of games could do with some more of this feedback - as glaring issues (such as multiple objectives) are easily found by others.

Anyway, I'll keep you posted on The Undeadables, and any ideas I have with it.

Thanks

Content Redundancy

2010-01-19T20:29:00.000-08:00

I wrote this material on content redundancy while writing the first Game Balance article - but found that it was getting too long and complex - so I am posting this section on Content Redundancy here. I also figure that if I can keep some of these articles shorter, they will be easier to reference.

Content Redunancy:

Content Redundancy is where previously introduced content is rendered useless by other content. There are two main types - Internal content redundancy and External content redundancy.

Internal Content Redundancy may be if your character finds Weapon B, which is better in every single way to his current Weapon A. This is a more so a problem in Shooting games and Action games - where players are more expected to choose between the two weapons comparing the trade-offs. However, Internal Content Redundancy is often totally disregarded in Role Playing Games, as the acquisiton of stronger weapons is consdered a part of the character's progression through the game, and you are expected to get stronger weapons as the game goes on.

Internal Content Redundancy is often considered less harmful than External, however, there can still be significant issues in class-based games, where a class may encroach on another's role such that it is better at that role, or, it may be reasonably good at that role and still great at its own role, such that it's considered a better choice as it can perform both roles well.

To solve this second issue (classes fulfilling too many roles), a significant investment is often added so that the class must choose between roles (such as with Skill Trees in Role Playing Games).

External Content Redundancy is where an external entity renders content useless - such as an enemy being a hard counter to your character - making you unable to continue using him (so you have to switch characters, build your character a particular way, etc.). This is a big problem in most games - you never want to have a player feel as if their character is useless in a given scenario (especially if they have to invest a lot of time into this character) - and you want the player to be able to play as he wishes to play.

External Content Redundancy is often a big problem in multiplayer games - in which players being countered by other players are nullified in play, or are at least weakened enough to cause them to switch characters, and not turn back to the other that they wanted to play.

There are two types of External Content Redundancy, Exclusive Content Redundancy and Complete Content Redundancy.

Exclusive Content Redundancy is a term given to a situation in which a character is countered by another, or several characters - such that it is considered to be a bad choice depending on the popularity of these other characters. The countered character is often played less than others without these counters, as players adapt and decide to favour a different character. Exclusive content redundancy can be troublesome in games with few characters/classes, while it is often overlooked in games with extensive rosters. Typically, Exclusive Content Redundancy affects a smaller percentage of the roster - however, an excessive amount leads to the second type of External Content Redudancy - Complete Content Redundancy.

Complete Content Redundancy is about as bad as it sounds. You do not want this in your game at any cost. It's pretty much when there is a lot of imbalance in the game, so, one character/class comes out the victor.

This character is then universally played by the vast majority of players, as he is the one with the fewest counters, and the largest strengths. You find that in most games, the matchups are simply Character X vs. Character X - or 'mirror-matchups'.

Your game then becomes really stale, really quick. It's very dangerous.

A notable case in this issue is Super Smash Bros. Brawl - which, despite its advertised particular focus on balance, has a notable Complete Content Redundancy with the character Metaknight, who, as far as I know, is on the verge of being banned (if not already) as recent tournaments have been over 50% Metaknight players.

Conclusion

Content redundancy is bad in most cases - and so Game Developers try to avoid it in most scenarios. As said, there are exceptions.

Most internal content redundancy is solved by mere balancing - if a weapon is too much better, nerf it, or buff the other. If a class encroaches on another's role, you can nerf it, or buff the other. If you wish, you can solve it through making the encroacher choose between being as effective at the other's role while sacrificing their own, or being effective at their own while sacrificing the others.

Exclusive redundancy can be really tricky, as if you nerf a character so he does not counter another so well, he may be countered by others. You need to get a really good look at the entire roster's relationship with each character, and decide where to go from there. Buffs and nerfs can be managed - though it is often rather difficult.

Complete Content Redundancy is either really easy to fix, or really hard. If the single character is the cause - he can be nerfed in whatever way is deemed most necessary. If the other characters all have large flaws however, you may be in a position where you need to consider a large scale balance revamp.

Thanks.

What is Game Balance?

2010-01-19T20:28:00.001-08:00

Well, it's been a while since I've updated - but this is not as much because I'm lazy (for once), but because this post has been haunting me. It has been exceptionally hard to write and I've restarted it about 20 times, so I'm just going to get through it and see how I can create it in such a way that I can talk about different aspects of game balance later on.

The Reality of Game Balance

Frankly guys, the topic of Game Balance is huge - as it covers and affects pretty much EVERY aspect of the game, from your character, to the difficulty of levels, to the game time per round, to... everything. Further, every single type of game has its own balance concerns - some derived from genre, some from the number of players, others purely from the individual systems in the game.

Then, consider that both players and developers tear their hair about balance - and you've got a pretty tough safe to crack.

Did I mention it's also difficult at times? Though, it is probably the most rewarding thing to get right. Balancing a weapon or character well - making it fun to use and powerful, while not being too powerful makes you feel great.

Definition:

Game balance is often defined as a state of the game where players have multiple options or routes, where most or all of these options are about equally effective or feasible. (Copied pretty much word for word from Wikipedia - as in general, this definition of balance is as succinct as you can get it.)

Good balance is essential - as the benefits are a fun, balanced (err...) game, while bad balance creates issues surrounding content redundancy and a lack of options that makes the game far less fun for some/most/all players.

I won't lie to you though - the rewards of good balance aren't exactly as notable as the punishment for bad balance for the most part. A well balanced game will generally receive responses such as "Oh, that game's pretty balanced", but bad balance will ruin your game. You game is often reviewed on its other merits as good balance is expected, but good balance is needed as a prevention measure.

Often, you will also find that good balance goes unnoticed by most - as the game feels intuitive and no issues are encountered.

The Results of Bad Balance

As said, the main issues related with bad balance are content redundancy, and the removal of options.

Content Redundancy is where previously introduced content is rendered useless by other content. This limits players greatly in terms of what content they can/will choose to use, and effectively wastes the time of the developers who implemented the useless content

Content Redundancy is mainly caused by:

Some characters being too strong
Others being too weak
Hard counters
Role-intrusion in class-based games.

[[I originally had a huge section on the different types of content redundancy, but I will post that right after this post]]

The Removal of Options is something that you never want to do to players. You never want to force them into a certain playstyle, or force them to use X weapon, etc. - you want to merely direct them. Well, to clarify, if something is considered outside the rules or limits of the game, you don't want players to be trespassing, but - when it comes to options that you give them, you don't want to force them down a single path. First off, the removal of options is very closely linked to Content Redundancy - why make a fork in the road when only one option is viable?

Second, you want the player to feel in control, and you want them to be able to control the game in their own way, when given choices by you. Basically, you don't want to give the player an option and have it severely deficit them later.

Just remember - the idea of the game is to be fun for the player, not to control them.

Strategies for Game Balance

Now, let's look at some strategies to set up game balance, and then some strategies to maintain it.

I plan to write an entire article on setting up game balance, but I'll just briefly lay it out here.

Good strategies when setting up game balance:

Use tried and tested game formulae, enemy stats, hero stats, etc. Don't be afraid to partially base your balance on another game's balance.
Create a quick prototype.
Consider a life as a basic character (basic hp, speed, weapons) - how they would progress through a level or game.
Create the most basic character first - for example, make them run at the most basic speed (units per second depends on the game engine), give them 100 health (if your health is going to be base 100), then give them a standard sword, pistol, whatever. Base other characters off this template. You don't have to use this guy in your game, but he can just be for initial testing
Count attacks. Counting attacks if a strategy used in many multiplayer games, such as saying "Class X should kill Class Y in a minimum of 4 shots from this weapon".

These won't create the balance for you, but will make balancing a lot easier.

Maintaining balance is a matter of basic, logical problem solving. I iterated the necessity of logical problem solving in my last post, but, well, get used to it - as you'll be seeing a lot of it.

If you find imbalance in your game,

Evaluate the problem
Simplify the problem.
Consider possible solutions.
Pick the most basic solution, that effectively solves the problem without creating others.
Implement solution
Test solution.

That's the full process - but the main steps really are 'Simplify the problem' and 'Pick the most basic solution'.

It should be obvious that if you don't simplify the problem to its core elements - and core problems, you cannot effectively solve it, while if you choose a solution that is not simple, does not effectively solve the problem, or creates new ones - you're... just making more problems.

So - I've gone over what balance is, why you need balance, and some balancing strategies.

I aim to perhaps create a list of balance concerns for each genre and style of game, but for now - I'm happy to stop here.

Thanks for reading.

Modding TF2 weapons.

2010-01-10T05:38:00.000-08:00

Well, I am proud to announce my newest, and, likely, my first modding project. I said in my first post that I really wanted to get into it, and well, now I have - and, what better to mod than a game I have been playing for the entirety of its lifespan, at a large variety of skill levels, exploring every single piece of content possible. I think I'm only more qualified to make a Pokemon game.

Most people who make their own weapons in TF2 do so to see how crazy they can make it (such as machine guns shooting 4 rockets a second), or, to test out unlock ideas that they had envisioned in the past (though, with our limited set of possible modifications, most are very impossible.).

My Aim:

I skipped the first motive - as, well, the crazy game modes and etc. have never interested me - I can see why some would love randomness and having everyone shooting shotguns that shoot rockets that drop plasma grenades, but, as I mainly play games to analyse them, figure out the maths behind them, and the developer's motives - the off-the-wall modes don't interest me. I'm interested in the balance and the designs - others are into the action.

That's not to say I don't like my share of fast paced gaming, but, generally when I play my mind is elsewhere.

I started modifying weapons, and making my own for reason 2, to test out some of my ideas (luckily, most of my ideas were very basic ones that had already seen similar systems in the game, such as life steal and slowing - not to say that they are boring to use, but, they're intended to be balanced and useful, rather than different and situational), and for a third reason - I want to try and balance out some weapons and classes myself. I have a lot of fun playing with pre-existing balance, so this is perfect.

Progress:

First off, I made two weapons that Valve has had in the works for some time now - the Heavy's Gloves of Running Urgently (GRU), that are supposed to counter the Heavy's poor mobility even when outside battle, at the cost of a constant health drain. I like these a lot because they are extremely well thought out, and they don't change game balance when fighting too much. The Heavy merely doesn't take 3 minutes to get to the battlefield anymore. An interesting part of the weapon is the health drain, as, this makes the Heavy a great Medic buddy when running to the battle field, further strengthening their synergy. If Valve made all unlock like this one, I would be in paradise.

The other Valve designed weapon is the Engineer's P.D.Q. - it's a wrench that builds buildinggs much much faster (+150% speed... making a sentry go up in 4 seconds), but, it cannot upgrade the buildings it makes at all.

This build likely sets up a quick teleporter and dispenser, having other engis upgrade them, while the Engineer sets up offensive, dispensable sentries around the place to hinder the enemy as much as possible.

I love the offensive Engineer style, so I really hope this one makes it into the next update. Likewise, if Valve made all of their unlocks like this, heaven.

After these, I started making my own weapons.

First off, was a Syringe Gun for the Medic that builds uber with each hit. The tradeoffs are that it fires far slower (otherwise it would build an uber every 2 minutes just with random spam), it deals very little damage (it's much harder to defend yourself), and, it totally nullifies the Medic's natural health regen.

This highlights the risk vs. reward nature of the Medic - you can take the Blutsauger or Syringe Gun that have better survivability - or you can go for the gun that, with some use, will get you those last few drops of Uber, but, if you're caught in a bad situation, can't help you.

I also made the weapon less powerful in combat so that there are no big issues with Battle Medics trying to gun down the enemy team for an uber, rather than heal.

The 2nd change I made was to the Pyro's Fire Axe. It is currently underused in play, due to the strength of the Axtinguisher - so I added 14.5% movement speed to it when drawn. This aims primarily to solve the poor movement issues of the Pyro, which keep him out of competitive play (not that this unlock will make him viable) - but also, to make the Fire Axe a good choice.

This pure buff is balanced by the fact that the Pyro must be holding his Melee (sacrificing most offensive power) to get the buff, meaning that like the GRU, it will not affect combat too much. It may be harder to run from him, but, with the Airblast, and his average running speed, chances are you weren't really going to without killing him anyway. The melee makes it easier to kill him.

Still, I may nerf this if necessary after further thought.

The final unlock I made today was an additional Pistol for the Scout. This Pistol has a 66% chance of slowing the enemy, but gives up 25% of its damage, and fires slower as the trade-off. This makes the Pistol ideal for catching up to someone, but less amazing in combat situations.

I thought up this unlock because I was not satisfied with the Bonk Drink that the Scout got for his update.

I wanted the Scout to get an unlock that slowed the enemy, as the Scout is the optimal class to take advantage of it. The Scout can catch up to an enemy, and, as his weapons are effective in close range - he can deal a lot of damage through this. The slowing effect also compliments the annoying nature of the Scout, which Valve tried to capture in his update with the Stuns and Knockback.

By contrast, the original slowing weapon was given to the Heavy, who, while he needs to keep his enemies close to him, is in much less a position to take advantage of the trait.

Anyway, I'm looking forward to using this one if I ever get the chance - I think it'll be useful and a lot of fun.

Anyway, I'm off to bed, just thought I'd type up the report.

I have a few more ideas to make before work tomorrow - wish me luck.

Goodnight,

Game Design is like...

2010-01-07T06:02:00.000-08:00

Well, forgive me guys - I meant to get this blog post done... about 3 days ago - but I wasn't really in the mood to type. I need inspiration, and I didn't really have anyway.

I have some now though, after a quick trip to the shops to get cereal ended up with me coming home with 2 video games (as you do...). I was pretty anxious about it then, as I don't like to buy on impulse, but I'm glad I did. I came home with Zack and Wiki: The Quest for Barbaros' Treasure. I paid $50 for it, but after playing for 20 mins, I think I would have paid $300 for it if necessary. Great game.

Anyway, I want to lay down the basics on my views of Game Design. I will warn you however, my views are idealistic - to put it in one word. I know that not every game will be perfect - but I strive for perfection when I'm thinking of game ideas, or mechanics, or even patches for pre-existing games.

Game Design is like...

Game Design is like a cube made of pure glass.

It's substance is all clear and consistent - if you look at the core design, you can see right through and view how the entire outside comes together.

On the outside, you have clearly defined faces, edges and corners. There aren't any imperfections, there aren't any jutting out pieces, or chunks missing.

There are a limited number of clearly defined faces, rather than a sphere, that has an infinite amount of indistinguishable facets.

When the game is created, the cube is gift wrapped - it's all pretty, but the inside contents are hidden. People observing the final product can't see all the inner workings, they can't see your intentions, your underlying principles, and why you made it like it is - but they can still clearly see, and touch the faces, edges and corners.

The Criteria for a Game Design

Sorry for the metaphor, but when I think of game design, this is what I think of.

As I said, it's idealistic. A game design should be consistent the whole way through (pure glass), and you should be able to understand the majority of the design by seeing the main structure (gift wrapping hides the inner workings, but players still need to be able to understand the game ideas), and you should understand all the inner mechanics if the developer explains it to you, or shows you the inner workings (transparency).

Designs should also be effective. To put it bluntly, if your design doesn't solve a problem, or meet its intended purpose - it's not worth a damn. This is quite obvious for a patch to a game that is experiencing balance issues ("Does it balance out that overpowered weapon? Yes. Done."), but a total game idea still has to have a purpose. You might have a market driven purpose ("There aren't enough games with Zombies being killed by trigger happy Plants"), experimentally driven ("Let's see what this new game engine is capable of"), or personally driven ("I want to make this"). Make sure there's a purpose.

Fixes and Solutions

If you're making a fix, a good guideline to ensuring that your design is effective is stating the problem - isolating the faulty parameter, then creating a fix to solve the problem, addressing the parameter.

For example, "The new weapon is too powerful" is too bland. Try something like "The new weapon deals too much damage".

At this point, you can make progress - by nerfing its damage.

"The new weapon is too powerful" can mean many things, such as "The new weapon deals too much damage", "The new weapon infringes on that character's main role", "The new weapon counters this character too well", etc.

The best way to do it is by saying:

What is the problem?
Can this problem be attributed to a particular aspect of the current design?
With reference to the problem, and the aspects listed above, here is the simplest, most effective solution.

Make sure to follow these steps when designing anything.

Clean Structure

Similarly, the structure of the design and its contents should be solid, and perfectly shaped - with no random modules added on, and no mechanics missing.

There is nothing worse than having a game where you think "Ugh, if only it had", or, having a game that is all consistent, until you reach a random snag that seems tacked on to fix a major issue without any real thought (such as, if all of your characters had 6 stats, but then one had 9 due to design issues with that character). These seemingly random additions or missing parts just confuse the player, and make the core gameplay convoluted. You want to have everything as clear as glass when you're making your game.

[[ Just a post-publishing note here, this section on tacking on random systems is not trying to persuade you to avoid adding new systems to your games - such as lifesteal on a new weapon, or a new attack modifier, etc. If you want to add something new - by all means do it. The point above is more-so a caution when fixing issues - rather than adding new content.]]

Convolution is represented through the contrast of the cube to a sphere. You might think that a Sphere would be amazing to experience as a game - many players, and early designers say that they want a game that has infinite possibilities - a true sandbox game in which the player isn't forced into anything, and they make their own destiny. I won't lie - I had grand aspirations of this, until a designer once told me that games are all about rules and direction. Games need to be clearly defined and contained, otherwise the player will either be overwhelmed, or they will cut corners to the content they bought the game for, then get sick of the game and don't experience the other 99% .

You want your game to have clear rules, with clear goals - and you want to direct your player to these. Note that I say direct rather than force. I love sandboxes just like everyone else - but you still need rules. Take for example, the game Prototype - it is very sandboxy, you can explore, kill people, fly - but, in order to reach the stage where you have all of your powers, you need to do story missions throughout the game world.

Presentation

The final idea I want to get across is the metaphor of gift-wrapping. You want your game to be clear to the players, you want them to quickly pick up things such as what the game is about, what directions you can take your character in, how you proceed through the game, how the game is played, etc. - but you don't want to show off all the inner workings if the player doesn't want to see them. For example, when a player is playing, you don't want them saying "Oh, the choice of weapons in this game is limited in the range spectrum, so I am expected to get up close and personal" - you want them subconsciously working it out and doing just that, and having a ball.

Similarly, you don't want them saying "The art direction in this game makes heavy use of silhouetting so I can distinguish my enemies from a distance" - you want them saying "Nice graphics", and distinguishing enemies without much thought.

That's not to say you should hide your intentions - I think some of the best leaps and bounds in terms of the developers giving their thoughts and insight to the players comes from Team Fortress 2 and Valve - who, in Single Player mode, have maps with little audio clips that tell you the reasons behind the various aspects of the game. I loved listening to them, and it really drew me into the game. Another example was the Warhammer Online podcasts. I didn't buy the game, I've never played it, but I'm subscribed to their podcast channel.

Conclusion

So really, imagine that the design you're trying to create, whether it is a fix for a bad weapon in your favourite multiplayer game, an entire patch for a game, a large mod for a game, or even an entire game idea in itself - make it as simple, effective, pure, and perfect as possible.

If you're having trouble with an aspect of the design, and you think you're going to have to add a convoluted feature - sleep on it for a few nights, and a better solution will pop into your head.

The reason for my idealism is not because I'm ignorant of the true nature of game design (well, I hope not...), it's because for every problem I've faced, and for every design I have created, I have found a neatly contained, but absolutely effective fix. It hasn't always come to me at the speed of light, and I have had sleepless nights going trough every possible idea that could fix the problem - and hell, sometimes I am totally shut down, and I only get it right when someone else spells out half of it for me - but there's always an elegant, well integrated solution.

Strive for perfection, but not just that.

Strive for

Consistency
Clarity
Simplicity
Effectiveness
Efficiency
Logical problem solving
Direction
Communication

Thanks,

Goodnight.

Woorrrk

2010-01-03T21:02:00.001-08:00

Okay, I've been trying to get in an update, but I've worked the past 4 days in a row.

And...

All the time I've spent away from work has been sleeping or watching Dexter.

Good thing however, I just finished watching all the Dexter accessible to me, and I am off work for 3 days after tonight.

I know I planned to jump right into what I would call more advanced, or derived balance discussions - such as the nature of balance and such - though, I feel that I need to lay out the groundwork first. I don't want to be talking about X or Y, and leaving giant holes where I use a term that I've made up to describe a feature of the design.

I also want to just lay out the basics of what I have done in the past - this is just so I can refer to them and perhaps give updates with regards to various projects I have undertaken.

Anyway, I will update tomorrow with *something*,

Zanda

First post.

2009-12-29T06:04:00.000-08:00

Well. I have been aiming to make this blog for a while but I suck at taking initiative.

It's 1:00 am and I am totally going to bed asap.

So, I'm Zanda, a teenager from New South Wales, Australia - and an aspiring Game Designer.

I'm attending the Game Development course at the AIE next year, with a major in Software.

I wish they'd teach design - but, as the programming teacher told me, you can't teach design - and you sure as hell won't get a job from it. So, being absolutely intolerant of 3D art, and with a natural curiosity and like of programming, I'm looking at code to get me an entry level job, then we'll see where I can go from there.

I want to get ahead in terms of design - and, I was told the best way to get there was to mod engines - and I may try it out, but, as I said, I suck at taking the initiative, and frankly I look at design from such a philosophical and egalitarian view point - it makes more sense to me to make a blog.

But hey, if anyone ends up reading this, and who knows how to mod an engine, or would like my mind on their modding team (I very much doubt it, but one can dream) - I guess you can give me a yell. I'd love to learn (and I need someone to beat the crap out of me until I do).

Anyway, just thought I'd initiate on this thing, as hopefully it'll actually lead to me continuing this blog and not just leaving it to be wasted. I already have some ideas for posts that I want to make, I'll list them below.

Wish me luck,

Zanda.

Ideas:

A conservative, analytical view on changing your game's balance.
A view on random achievement and reward.
Where to start when balancing your game - a daunting task.
Graphs and game design.
Is the game fun?
Role-based class balance.
Achievement, rewards, and addiction.
'Balance' and redundancy.
Balance vs. variety.

I think I forgot the others.

Oh, and I will be posting up game design ideas I have.