Posts Tagged ‘gamedev’

Crafting Endogenous Value

Monday, February 8th, 2010

About 16 years ago (at the now seemingly infant age of 13), I was introduced to the fantasy role-playing genre of PC games with Ultima Underworld: The Stygian Abyss (Ultima). Ultima was incredibly immersive not only because of its rendering engine (one of the first to feature techniques we take for granted now like texture mapping), but also the ways in which players interacted with their avatar and his/her gear. Eating and sleeping regularly were necessary, lest the player suffer decreased health and stamina. Torches would burn out and had to be replaced. Swords would fracture if not regularly repaired and become useless junk. Fish could be caught (and eaten) from underground rivers. The list goes on…

After awhile, managing the in game inventory became an arduous task that led me to realize three things:

  1. I had (and still have, actually) a pretty severe case of OCD and simply couldn’t leave anything on the damn ground.
  2. Ultima’s inventory system allowed for nesting containers (basically putting bags inside bags). This led me to stumble on a bug in the game that caused it to crash while attempting to nest containers greater than 8 levels deep. I know…I need help.
  3. Some items had absolutely no useful purpose.

I’d like to stay on that last one for a bit because it begs an important question. Why deliberately design game objects (including their artwork, models, stats, and other assets) that don’t do anything? Ultima’s developers say they intended the game to be a “realistic and interactive dungeon simulation“, rather than a straightforward role-playing game. Of course, as we all know…realistic dungeons are full of useless crap.

Sarcasm aside, I do have issues with this reasoning. For one, the game is simulating a fantasy world, so the notion of it being a realistic simulation strikes me as odd. Some in game characters and creatures do have real world counterparts that are exaggerated to great effect (giant spiders give me the creeps), but ultimately the designer is crafting their own reality. That being said, I don’t see the problem with crafting a reality where every item (and I mean every item) is useful in some context.

In the case of Ultima, this is really a minor issue that doesn’t take much away from what is otherwise a classic RPG. I only mention it because of the lineage it shares with a ridiculous and growing trend that has crept into more recent games, vendor trash (VT). Simply put, VT is anything in game that, upon discovery, is immediately stuffed into a bag and sold for pennies to a willing merchant. It defies any logical explanation, and the sooner it dies a quick death, the better off all gamers will be. VT seriously bugs me because I consider each useless item a squandered opportunity to increase the endogenous (en·dog·e·nous) value (EV) of a game. I also consider EV to be the cornerstone of what makes games addictive and compelling…so…what the hell is it anyway?

In 2002, Greg Costikyan swiped the term ‘endogenous’ from the biology world and used it to describe the internal value that a game structure (including its rules, mechanics, and objects) can generate:

Suppose you’re walking down the street, and someone gives you a $100 in Monopoly money. This means nothing to you; Monopoly money has no meaning in the real world. The guy who gave you the bill is probably some kind of lunatic.

Yet when you’re playing Monopoly, Monopoly money has value; Monopoly is played until all players are bankrupt but one, who is the winner. In Monopoly, the gaily colored little bills that come with the game are the determinant of success or failure. Monopoly money has meaning endogenous to the game of Monopoly – meaning that is vitally important to its players, so much so that you have to watch your little sister like a hawk to make sure she doesn’t swipe bills from the bank when you aren’t looking.

In most RPGs, much of the EV is generated by the game inventory. The treasure. The drops. The loot. The schwag. Call it what you like, the pursuit of shinier and more powerful gear is one of the primary driving forces in any RPG. Traditionally, the quest for epic loot has started with slaying massive amounts of baddies. Players either kept what they received or sold it to non-player, or computer controlled, characters (NPCs). Trading with NPCs was also possible in some games. Ultima is one example.

With the rise of online gaming, items that players craft themselves have become a mainstay in most massive multiplayer online role-playing games (MMORPG). Crafting can be an incredible source of EV because it creates new goals for players and enables them to have a more meaningful and direct impact on the game economy. I use the word ‘meaningful’ here to describe the satisfaction a player gets from taking raw material and creating something useful to other players in various contexts. All this is very dependent, of course, on the actual implementation.

Around 2000, I had my first experience with crafting while playing Everquest. It was pretty painful. Raw materials weren’t readily available and reagents were relatively expensive, which resulted in crafted items that were worth less than the materials used in making them. For newcomers, most attempts at making anything resulted in failure and a loss of all the materials involved. In the end, players who became proficient in a certain trade skill couldn’t create much that was unique or useful to the other players. The entire system was an incredible waste.

Four years later, even though a few of these problems persisted, I had a much different experience with World of Warcraft (WoW). WoW has two general types of professions, gathering and production. Each production profession is supported by a gathering profession. Blacksmithing is supported by mining, for example. Mining alone isn’t that glamorous: you see a mineral vein, you stroll up to it, and click. It either works or it doesn’t. If it fails, you can try again. If it works, a loot window appears just as if you had killed a creature. Despite this, mineral veins don’t stick around very long after they pop…players tend to snatch them up immediately. Anyone who’s ever been on a dungeon run and watched a miner make a sudden b-line for the nearest vein can attest to this.

The raw materials gathered in WoW create an incredible amount of EV because they are useful to production professions. Those professions, in turn, can actually churn out useful gear. As an example, take a look at this list of all the recipes (blueprints for items that can be crafted) that require Copper Bars. As of this writing, there are over 30 items that can be crafted using copper as one of the ingredients. Each one of these items is useful to different characters in different contexts (level 15-20 Hunters are quite fond of Crafted Heavy Shot, for example). Every time a useful recipe is added to this mix (assuming it doesn’t throw off the game balance), copper becomes more of a commodity and creates even more EV for the game as whole.

This system is far from perfect (I never saw many Warriors carrying Copper Axe’s), but it does illustrate the positive effect a crafting system can have on a MMORPG when implemented correctly. Blizzard’s success with the crafting system in WoW, however, makes it all the more insane that the game still has so much VT. Again, every item dropped in-game should be useful in some context: whether it be important for a quest, a reagent for a trade skill, or just something that allows the character’s aesthetic to be customized. Who says necklaces made from crisp Basilisk urethra aren’t sexy?

As a final example, EvE Online takes crafting to one extreme (some would say too extreme). Most (if not all) of the ships and various gear sold in EvE are created by the players themselves. The game simply sells the blueprints. Actually, the players can research and sell them as well. EvE also has various trade skills that players can train, like Salvaging. I can recall one instance when a close friend and I had an opportunity to clean up a trail of destroyed enemy ships a fellow corp member had left behind after a mission. While the prospect of collecting garbage wouldn’t exactly be appealing in most games, we salivated. There was several million worth of ISK (EvE’s in-game currency) to be made from that salvage, and we were all too happy to oblige. This is a perfect example of a game creating EV where there otherwise would be none…and it’s a trend that I hope continues in all games.

Source SDK Development Woes

Thursday, January 15th, 2009
It hurts right around here...

It hurts right around here...

I had mentioned in my first post that I wanted to focus a lot of the content on this site towards two software projects I’m working on in my spare time. One of them is a PC game demo I’m writing with some friends.

When we started the project, everyone was dead set on creating the demo as a Halflife 2 mod using the Source Engine SDK (we’re all loyal Valve fanboys). We spent about three weeks heading that direction and finally gave up. We’re currently in the process of starting over (possibly using XNA).

A lot of the reasons we decided to dump the Source SDK are summed up in this thread on the hlcoders mailing list. It’s getting a bit long though (and has strayed off topic more than once). So after spending some quality time with the SDK, here are my primary gripes:

  1. API Docs – This is probably my single biggest complaint. The Source SDK is a huge and complex chunk of code. Without API docs, new developers are basically forced to read the header files (which are sparsely commented at best) and waste a lot time on trial, error, and guess work. I know that commenting and documenting source is royal pain and a bane of all hackers (even the good ones), but it’s still vital. This is especially true for something being released to the public. Doxygen has been around a long time, and is used in at least a few open source rendering and game engines. Given Valves resources, I don’t see a reason for this.
  2. The Source SDK Wiki – This was a great idea that I think has just been poorly executed. Valve started this wiki around the summer of `05 as a central source of documentation for the modding community. The content is poorly organized, most if it isn’t written very well, and a lot of it is simply outdated. It seems as if Valve just installed MediaWiki on a server somewhere and said “Here…enjoy.” I’m all for community edited documentation and version control, but I think Valve has to set standards…and the community needs to keep to them. Installation instructions and beginner tutorials should probably be written by or at least approved by Valve developers. This would help keep the learning curve from getting too steep and provide a reference for people that want to write more advanced content.
  3. Source Code – The first steps to creating a new Source mod are very straight forward. You open up Steam, launch the Source SDK tool, tell it to create a new mod, and you’re off. The code that it dumps in the project directory is a bit of a mess though. When you open the generated Visual Studio (VS) solution, two projects are presented: one that builds a client DLL and another that builds a server DLL. The base source code directory for the client project contains no less than 315 files. The sub directories contain even more and they’re not organized in any seemingly logical fashion. In addition, the project doesn’t build clean (read: without warnings) right after you create a new mod. Some of the warnings I fixed by tweaking some header code, others could have been suppressed in the project settings. Finally, as of this post, the VS solution generated by the mod tool is a VS 2005 solution. Converting it to a VS 2008 solution creates more problems that need to be fixed. Overall, the base source code seems sloppy and poorly organized.
  4. Design Documentation – Another problem with the complexity of the Source Engine is that new developers can easily get overwhelmed. I got frustrated and confused many times because I just wasn’t sure how the pieces fit together. Often times the in-game dev console would spit up errors and I’d have no idea why, where they were coming from, or how to fix them. A good design doc would go a long way to alleviate some of this. Something that described at a higher level how the different parts of the engine and SDK talked to each other and where to find the code for each piece. This could also be helpful as a road map to the API docs as well.

I know a lot of this is just ranting (and I’m not the best coder in the world by any stretch). But overall, I was really disappointed with the Source SDK. As a gamer, I’ve bought everything Valve has ever released. A few of their games are in my top ten as well. I think they listen to their customers and genuinely try to improve products after their initial release (Left 4 Dead and Team Fortress 2 are great examples). I was excited to try my hand at Source development after reading about the origins of Portal, CounterStrike, and Left 4 Dead as mods. But as a developer, I feel like a lot of the work on the SDK was shoddy. I know others have similar grievances, and I hope Valve addresses some of them in the future.