Note: I’ve put this work on hold and am going another direction with this project. The C++ code is found in the ogre branch. I’ll have a new post about what I’m putting together soon!

If you’ve done any sort of game development in the past 5 years you’ve most likely heard of “Component Systems” or “Entity Systems” for doing object and scene management over an OOP hierarchy. Object Hierarchies may start out clean, but over the course of the development of a game, become a very difficult to work with. Components — very succinctly built self-contained clusters of data and logic that can be added to, or taken away from, anything — are the answer.

There is a ton written about these kinds of systems. A quick Google search of either of the terms in the title will get you to many of the most popular posts describing the why of Component systems, so I’m not going to dive into that myself. Instead, this post will be explaining how I’m implementing Components in Project Slartibartfast, why I’ve made the decisions I’ve made, and how I plan on continuing development with this system.

As an avid supporter of Open Source software, it’s been annoying reading so much about this radically different methodology and find very little code, or code examples that don’t solve the issue I’m trying to solve, concerning Components. Now that I’ve sat down and actually turned an idea in a working system, I realize that these systems really do end up being very specific in their implementation to the product at hand, be it a game, an engine, or something not game related at all. So this isn’t per-say a “this is how you implement Components and Entities” but an exposé of how I’ve decided to implement this in my game.

As an aside, because these arguments come up so often, my personal view of software development and design is that pragmatism beats idealism every single time. As long as you have a good reason for your decisions, build something that works, don’t fret that it’s not a “best practice.”

That said, lets dive into the Component system of Project Slartibartfast.

When I sat down to start designing the base system this game will use, I needed to answer two questions: Where does the data live? and Where does the logic live? These questions will have vastly different answers depending on who you talk to, what they’re trying to build, and what language they’re working in. Do the components know about the data? Does the Entity have data and Components the logic? Are there other systems that handle the logic as well as the connecting of Components to Entities? It’s important that you can put an answer to these questions before you start coding because once you’ve started building a system following your answers, changing your mind later usually results in a very large rewrite and big headaches getting everything running again.

I decided to take as pragmatic an approach as possible and build a system that’s simple but no simpler, easy to extend, and doesn’t require a bunch of crazy C++ syntax or templates. I came up with the following.

Actors

Actor is what I’m naming my Entity construct. My first real foray into modern game development was UnrealScript in Unreal Engine 2, which uses the Actor terminology and it’s just stuck with me. Actors are very simple, they only hold the list of Components that define them. Every Actor has a TransformComponent by default which defines how they hook into the world (an idea I pulled from Unity3D). Due to this fact, the TransformComponent is defined directly on the Actor itself and not in the components array.

Actor.h

Components

Components are pure data. There is no per-frame logic in these. Each component knows what data it needs to keep track of for the system to work. This data can include publicly usable data (position, rotation, scale) or hooks into various subsystems (like a SceneNode or Camera in Ogre). Because these classes are pure data, they’re in most part just a collection of public attributes.

Implemented Components

When a Component is added to an Actor via addComponent(), the Actor ensures that the Component is registered with it’s appropriate Manager. The logic for Component <-> Manager registration is handled with the REGISTER_WITH macro that’s added to each Component. After fighting for a while to make Managers and Components all OO happy with templates and polymorphism I blew the entire system away (don’t you just love 300 page error reports due to gcc template errors?) and implemented a few macros to define some helper methods common across all Components and Managers. This turned out to be much, much cleaner and easier to work with.

Managers

Managers are logic. If there’s a Component in the system, it has a related Manager to, well, manage it. Components get initialized by their Manager when given to an Actor. The Manager has update() for any per-frame updates that need to happen for the Components it’s in charge of. Managers also keep internally a list of all of their Components. Only Components added to Actors are considered “live”.

Managers Definitions / Managers Implementation

You’ll notice that there are also macros in place here: MANAGER_IMPLEMENTATION and MANAGER_DEFINITION. These, like the Component macros, define common functionality across Managers for dealing with Components. With this I’m able to keep a very specific list of Components for each Manager instead of fighting with polymorphism, templates, and types.

Also, Managers are Singletons. There’s going to be quite a few of them as this project progresses and it was the only idea that made sense.

API

With all of the above now in place, the API for using Actors and Components couldn’t be simpler. It’s straight C++ object handling:

Everything here just works. The Ogre::Camera gets initialized, attached to the Actor’s scene node to inherit rotations and translations. The Input is hooked up to provide a full 6 degrees of movement in two parts, MovementComponent handles the keyboard ESDF mappings, and MouseLookComponent of course handles the mouse input, and the Actor is placed into the world at the given location.

Adding a Planet to the game is just as easy:

where we get a new Actor, set its scale through the TransformComponent I talked about earlier, then adding a Mesh representation to have something visual on the screen.

Continuing from here, there is one convention that I break really badly that I wouldn’t mind finding a cleaner way of handling. If you’ll look at CameraManager.cpp you’ll see that I utterly beat and abuse the Law of Demeter. This is one aspect of Component systems that is probably the least “solved,” for lack of a better word: communication between Components. An Ogre::Camera, for this system to work, needs to be directly attached to the SceneNode representing it in the world. This SceneNode is on the Actor’s TransformComponent, so I have to go component -> actor -> transform -> sceneNode to get at that information. Since this is the simplest solution that works and doesn’t really get in my way I don’t really have a problem with it but if I do come up with a better solution I will be sure to post about it.

And that’s really it. I’m pretty happy with the system so far, it’s easy to understand, handles communication automatically so I don’t have to remember to connect anything, and is very easy to work with and extend. If any serious issues pop up with my decisions here, I’ll be sure to update this blog as necessary.

I’m not going to write it because frankly, I’d never want to read it. So I’ve condensed my point into three simple words:

BALANCE

PVP

FIRST

You simply cannot have a PvE game and add PvP on top of it. PvP is player skill, PvE is just numbers. One could go to the extreme and say that they can’t co-exist, but I’m not quite convinced this is true. Close, but not quite.

Now of course I can’t list, or even think about, most of the design decisions that have helped towards making WoW the massive success that it is, but there are a few decisions, both good and bad, that have hit close to home for me, decisions that I have to work with or around every time I play. Were I to be on the WoW dev team, these are some of the things I’d be recommending.

Stat Equality

Wow is all about gear because character power advancement is built completely around the stats. The stats in WoW are Strength (STR), Agility (AGI), Intellect (INT), Spirit (SPI), and Stamina (STA), and they are directly related to how powerful your character is, or at least they should be.

In WoW, stat allocations over the various classes has always felt arbitrary, and frankly it’s a very complicated system that doesn’t need to be, which has lead to serious balancing issues between Melee and Caster classes that have yet to and probably will never be fixed.

For example, a Warrior gets two Attack Power (AP) (stat on which all abilities scale, thus directly related to damage output) per point of strength. Rogues and Hunters get their Attack Power from AGI (Hunter is considered a “Ranged Melee” class by the game). However, Mages get a 1% increase chance to crit every 60 INT along with 100 mana per one point of INT, while Spell Power comes purely from items themselves. SPI gives a DPS boost to Warlocks because of a skill that class has, but anyone else just gets mana regen (as of 3.1, SPI does give very small amounts of crit now too), making it a very important stat for some healing classes, but not all.

Confused yet?

When WoW first came out, progression for DPS caster classes, especially Mages, stopped hard at level 60. The game did not have the stat Spell Power, so the only benefits Mages got from gear was higher health in STA and more mana / crit with INT. The game did have Attack Power, so melee were outscaling Mages exponentially, who were simply able to cast spells longer. Since then, caster DPS scaling has been an issue.

A much, much simpler system of making INT behave like STR would have gone a long way towards simplifying scaling from the beginning. If your game is going to have stats, make them consistent. Arbitrary decisions will lead to big problems, and sooner than you’d expect.

All stats need to scale to appropriate levels and then some

Following the above, make sure those stat decisions actually do scale into the foreseeable future. It is surprising to see a Blizzard lead designer explicitly say that they check the scaling of all classes only through to the next patch or expansion (which ever is nearer) and fix problems as they crop up. I can’t begin to imagine the amount of work that would have been saved had more care been taking at the beginning to make stats less complicated and properly scale for longer than just the next tier of gear.

Character resource decisions can make or break balancing from the beginning

The Death Knight uses a Runes and Runic Power resource system. The DK expends Runes on certain attacks, those attacks build Runic Power, from which the DK then uses other abilities that deplete the Runic Power. Any rotation a DK choses can be kept going forever.

Rogue energy is always refilling and simply serves to put a “cast time” on rogue abilities. Rogues can fight forever.

Warriors have Rage. Warriors gain Rage when they hit with white attacks or get hit. They then use this Rage to use special attacks. This system, while dependent on Rage income, can be kept going forever.

Casters use Mana, and can run out. They cannot fight forever. This is a very poor decision that has caused numerous problems with fight balancing, character balancing, and makes PvPing with these classes especially difficult.

Healers are not included in this. Healers running out of mana is a very valid ‘soft enrage’ system to put on a raid. If a healer could go forever, then any fight is easily trivialized.

Warhammer got it right: every class uses a refilling energy system like the WoW Rogue.

Incentives drive player inclusion

Converse to that, disinsentives do drive players to not participate. When you’re dealing with a group of people, it really is quite easy to predict what that group will do. For example, by adding Battlegrounds and gear rewards for doing those battlegrounds, Blizzard completely destroyed World PvP. Why spend hours ganking people in the world when at least you get rewards for doing it in a Battleground?

Achievements!

Nothing has refreshed WoW like Achievements. Giving people the ability to show off their exploits, to be rewarded for taking on hard content, or for committing acts of crazy mindlessness (see: The Loremaster) helps keep players busy with tasks they otherwise have not done, along with just straight keeping them in-game and paying. Nothing helps a game’s population than more ways for people to show off what they’ve done.

World Events

Special time-specific events are always a big hit for players, but they usually are very time consuming to implement and it’s rare that every player gets to participate in said events. WoW’s system of having set events that happen throughout the year, every year, help to make sure that as many players as possible can experience this specially crafted content. Hooking achievements to world events was of course a brilliant idea, and has made players actually look forward to the next event, preparing and planning.

Mistakes have been made, but it cannot be denied that Blizzard hit on the recipe for hugely successful MMO. It’s easy to get into, easy to play, difficult to master, and full of content for everyone, from the PvPer to the PvEer to the players that just hang out with friends. There’s a lot to be learned from this game, and I’m sure designers will be using WoW as a template for many years to come.

Part 3 will be my (hopefully not to angry) rant on the decision Blizzard made to try to turn a PvE game into a PvP game, and the constant balancing work that has and is going into both sides of this game.

I figured, now that I’ve got a blog, it’s time to start taking more permanent notes on the design decisions, both good and bad, of the various games I play. To start, I’m going to pick on the 800lb Gorilla in the room, World of Warcraft (known here on out as WoW). This is the first of what will be a multi-part series of articles, as I tend to delve in to rants and ramblings at time. However, I will try to keep it all coherent. So, without further ado…

I’ve been playing this game on and off for nigh three years now. I’ve seen plenty of ups and plenty of downs, been a part of quite a few guild breakups, and have developed an almost unhealthy love of criticizing and critiquing every little change Blizzard make to the game. I’ll admit, it’s not the best state of mind to be in, and many-a-time it has eaten away at me and caused me to loose all enjoyment of the game as I end up only able to focus on what’s wrong and not what’s fun.

What follows are the results of my brooding over the what and the why of the decisions made at Blizzard. Why does Blizzard make the decisions they do, what are the ramifications, and what can other game designers and developers learn from one of the best companies in the business. To start off, the most important rule about game design in general is quite simple:

You are building your game. Make the decisions you think are right.

I give Blizzard HUGE applause for what they have accomplished with WoW. It is by far the most complicated game ever created, and the fact that they have kept it running, continually added more, and still kept the same general WoW atmosphere and Blizzard Polish since release is a testament to the courage the development team has in shaping this massive game over time. Given all the flak they receive on a daily basis on their official forums and forums across the world, Blizzard rolls right along with the punches.

If you want your game to be successful, trust your instincts. It’s your game, not theirs. Make the game you want to play. That said…

Some players will know the game better than you

An interesting phenomenon I’ve been following with WoW is the statements of theorycrafters (those players that constantly calculate and run all the numbers they can get a hold of, to find the best, the worst, and everything in between) contrasted to the official statements of Blizzard, and what I’ve noticed is this: the theorycrafter community is almost always right.

As an example (and this will be difficult to really show without forum posts, but those are gone so please bear with me), with the most recent expansion to the game, The Wrath of the Lich King, we’ll look at how WoW’s PvP game became, quite frankly, a failure.

Wrath of the Lich King came with three changes that worked together to completely dismantle the game’s PvP.

Up the level cap to 80
Restart everyone on even footing as of level 71
Introduction of the Death Knight

Upping the level cap is a normal move for any MMO expansion, and follows with the previous 10 level jump we saw in The Burning Crusade (TBC), the first expansion. There needs to be significant increases in the status of player characters, so it stands to reason that a level 80 character would easily tromp a level 70 character.

Restarting on equal footing is almost a necessity given WoW’s PvE end-game. Now, first and foremost, WoW is a gear driven game. Everything you do to make your character more powerful involves gear. To help be better in PvP, you get better gear. To do better, and progress farther in PvE, you acquire better and better gear. The side effect of this is, a level capped character with full end-game PvE gear is far more powerful than a character who just hit the level cap. With a new expansion, and 10 more levels to grind through, Blizzard could not require high end PvE gear to continue through the new content or they would have very quickly lost a large portion of the player base (as only about 10% of the population really experience much of the end-game content).

So, the new area, Northrend, had to offer quest reward items and random world drop items that were almost equal in power to the previous end-game PvE gear, putting all characters back on an even footing. This means that everyone suddenly does more damage, has more health, and is overall significantly stronger (example: my best raiding DPS in TBC was around 1500. When I started raiding again in Lich King, I was already doing 2500 and quickly improving). In general, the calculations showed that a level 80 character started out about 2.5 to 3 times more powerful than at level 70.

The introduction of the Death Knight was long in coming, and heavily anticipated. A new class for WoW was just what the game needed to bring a fresh breath of air to the game some people had been playing for 3 straight years by then. It is a class with a novel new resource system (Runes and Runic Power), tons of new spells and abilities to master, and an entire new starting area built just for the class and its lore leading up to Lich King. Blizzard put everything into this class, they wanted it to be a huge success, and quite a success it has been, and a major sore spot as well.

With the triage of these three major changes, WoW’s PvP was doomed from the start. It didn’t take the theorycrafters long to crunch the numbers, to play with classes on the Test Realm, and to come to the conclusion that at level 80, characters were either going to do way too much damage, or they weren’t going to have high enough health pools to soak up the huge damage increase. Posts on the official forums and post on respected theorycrafting forums like Elitist Jerks showed, argued, and asked constantly for Blizzard to re-think their stance on character power at level 80, but Blizzard would have none of it. If there’s one statement seen the most, it was “We will just wait and see what happens” often followed by “We think it will be ok, characters will have enough health.”

Well the “wait and see” has happened, and the game’s PvP devolved to the worst it’s ever been. Healers gave up trying to heal, because you can’t heal someone who gets killed in 3 seconds or less. Entire classes stopped playing because they either couldn’t do the damage others could, or they couldn’t get out of the way of the incoming damage. It was, and in most cases still is, absolute mayhem. Skill has been shoved into a trailer and gear and choice of class is the king of PvP now. To see what I mean, here’s the top 10 ranked PvP Arena 3v3 teams as of the March 24th:

The top 10 teams of the 2009 Arena Tournament’s online qualifier as of March 24, 2009 are listed below:

Rank. Team Name	                Classes
1. well then                        Death Knight, Paladin, Warlock
2. BARKSDALE CREW             Death Knight, Paladin, Warlock
3. monkey attack squad        Hunter, Mage, Shaman
4. GET MONEY GET PAYCE     Death Knight, Hunter, Paladin
5. Walrus Attack Squad	        Hunter, Mage, Priest
6. Paradorn’s Team	        Hunter, Paladin, Warlock
7. NO LIGHTNING GEN BRAH	Death Knight, Paladin, Warlock
7. Nekos’ Team	                Death Knight, Death Knight, Paladin
9. faceroll tunnel vision         Paladin, Priest, Shaman
10. Wd’s Team	                Death Knight, Paladin, Warlock

Pretty obvious to see just how inbalanced the PvP game has become. The top teams, while good at PvPing anyway, are so much better simply because of the class composition of the team. Entire classes are absent of this list: Druid, Warrior, and Rogue, which ironically enough were always present in Arena teams during TBC.

Anyway, it’s a lot of talk to make a point, but the severity of the failure because Blizzard didn’t listen to the theorycrafters at all needs to be shown. There have been many steps since taken to “tone down burst damage” since Lich King’s release, but Blizzard has a long way to go. More time up front, and a willingness to admit that they were wrong, and Blizzard could have made huge strides towards preventing this catastrophe. Blizzard has been working hard since the release of TBC to make WoW’s Arena a viable “e-sport”, but with current state of Lich King’s PvP, they have taking a very severe blow to that work, making it that much harder to convince people that Arena is worth standing on the pedestal with games like Counter Strike and Quake.

Continue with Part 2