Selling more stuff

You've added some interesting commerce-related requirements in this scenario. Now explore them in detail, beginning with Barbie's T-shirts.

Conceptually, selling T-shirts is a simple use of commerce.You've already identified commerce as a required function and you have a commerce engine that allows a gamer to choose and buy a selection of T-shirts in different sizes and colors.

The graphics technology angle

Printing an individual gamer's avatar on the T-shirt is a little more complex. Because digital T-shirt printing is unlikely to be a competency that you wish to develop, the solution is to build a relationship with an external digital T-shirt printing house. You send them an order with an appropriate image attached as a graphics file and they print it for you. To do this, you need to be able to extract the image of the gamer's avatar, complete with accessories, from the game graphics database. You then can scale it up and ship the image to a digital T-shirt printing facility along with this gamer's nickname and order.

You're making the gross assumption that the individual icons from which the individual avatars are constructed and with which they're accessorized can be scaled up in an appropriate fashion -- this requirement may cause your graphic artists some pain. You can solve this problem by forcing avatars to be created from pre-defined graphic building blocks, then save the high-resolution versions of these blocks in a digital-asset management system. Technology for automatically creating thumbnails from higher resolution graphics is readily available -- some solutions provide more elegant results than others.

When you get a request for a T-shirt, construct the required avatar from higher-resolution versions of the same building blocks from which the avatars are created; then add the nickname to create the proposed T-shirt image.

By the time you've implemented the T-shirt printing, expanding sales to include personalized mugs, posters, screensavers, toys, and other paraphernalia is a small step that might supply substantial financial rewards!

Besides addressing the graphics technology issues, implementing these personalized component sales will almost certainly require some customization or additions to your commerce engine. You know some implementation challenges are likely. But at this level of design,the sales appear to be do-able -- you cannot see any showstoppers. But customization to the existing commerce engine at this stage is a minor issue.

How minor an issue is it, though, when you consider supporting Ken's supplementary source of income -- his sale of in-game possessions?

Creating a barter/exchange system

Begin adding to this new lifestyle scenario:

Ken's character, Buffboy, finds another character, Cooldude, who wishes to purchase one of his possessions.

In-game commerce is a surprisingly large market. EverQuest's developers didn't support (nor have initial knowledge of) the market for characters and weaponry that sprang up on eBay. One study showed that the EverQuest universe of Norrath had an economy ranking close to Russia's in terms of per-capita GNP. (No kidding! For some people, their entire substantial taxable income as reported to the IRS comes from their dealings in this economy.) If you can provide gamer-to-gamer sales inside the game, you can maintain control of this market. If you can create a tax on these sales that go into your pockets, even better.

Lawyers may wish to get involved at this point to explore potential legal issues. For example:

• Is it legal (in whatever countries) for an exchange of cash or credit to occur for something that does not physically exist?
• Who is really the owner of the character's sword, spell, or other possession? The people who developed the game? The people who have the rights to run the game? Or the players who currently hold the possession?
• How do you value the item, and create the exchange?

While you find some thorny issues here, you also find precedents. Casinos have in-casino chips that can be credited to an account, exchanged between players with their agreement, or exchanged for cash at the casino entrance. Frequent flyer miles are another example of an intangible good with questionable ownership that is exchangeable for real money.

Based on these examples, you'll create in-game scrip for use as currency within the game, exchange between players, and credit to the gamer's account.

While this is still commerce, it's quite different from the first scenario. It is, in fact, not a sale that manifests in a transfer of goods in the external world with a cataloged item of inventory that must be managed. This is actually the moving of an item from one gamer to another and a simultaneous exchange of scrip.

The scrip could be implemented in a number of ways. A simple way is to have the scrip exist as a possession within the game and require the gamer to take specific action to move scrip between his account and his in-game existence.

Another option is to have scrip exist as an external currency and to have each transaction manifest in the gamer's external account. You could seamlessly provide a secure link between the in-game existence and his account, so that use of the scrip in the game immediately translates into an account balance change.

This option requires a greater level of integration; greater security, given the temptation to hackers; and probably, greater expenditures on the part of the character since it is then far easier to lose track of expenditures (similar to a casino effect). It potentially also carries with it higher threats of liability, but I take a technologist's view of this and leave that as the lawyers' concern.

I use the first option here since it reduces the level to which you must integrate support of scrip into the other business systems (such as accounts, commerce, and accounting systems). Let's play out this scenario:

Buffboy and Cooldude haggle and reach an agreement on a price in scrip, the local in-game currency. Buffboy then gives Cooldude the item, and Cooldude gives Buffboy a certain amount of scrip. Behind the scenes, the scrip is deducted from Cooldude's in-game scrip balance and added to Buffboy's scrip balance -- potentially minus a transaction cost. When Ken later goes to check his in-game balance, his scrip account has increased.

The exchange between the characters is straightforward to implement within the game. You have a database -- the game database -- that tracks all characters and knows what items they possess. You can easily create a scrip account within the game to add to and subtract from as a result of an agreed-upon exchange by the players.

However, you still have to account for the transfer of scrip from the in-game account to the external directory:

Ken's character, Buffboy, can request more scrip to be added to his in-game account. He can also request an exchange from scrip to dollars which causes a transfer of the scrip from the game to the gamer's account. The accounts system recognizes scrip as a currency with a given translation into real dollars. Ken can pay his account or purchase items from your online store using scrip. He can also transfer amounts between scrip and dollars at will, add dollars to his account to get more scrip, and vice versa.

How will you implement this? You have a gamer directory which identifies the gamer associated with each character. You can also locate each gamer's account in the accounts and billing system. However, you are now asking for an in-game request to affect the external business systems, and vice versa -- something you only want to do cautiously, under extreme control. Your games programmers are not experienced in this area. This also seems like a function that hackers are likely to target, a further reason for caution.

I mentioned in the previous article that outsourcing a component to an entity that is experienced in creating a specific critical function can be the most prudent path to follow. A little research locates a technology that can help in this instance.

Business Integration for Games (BIG), for instance, is a technology available on the IBM alphaWorks site, which provides a Web-services-based interface between the game and out-of-game services (see Resources). By using BIG, you can make Web services calls from inside the game to the business system that manages the gamer's accounts. By using a specified service in this way, you can simplify the coding from the programmers' perspective and secure the calls by ensuring that the Web services request is accepted only under specified conditions. In fact, BIG has already been integrated with a micropayments service that you may also wish to use.

This is your first need for an external manifestation of an in-game event, but you can easily see additional uses for the same technology. Now take the scenario to the next level of complexity:

Barbie's character, Cutegirl, finds an in-game store, CoolStuff Inc., which advertises personalized T-shirts, showing her avatar. The price is set in scrip. She agrees to buy. Behind the scenes, the cost is deducted from her account. You are running the store, so the scrip value becomes a transaction that adds to your internal account; you also register a purchase transaction in your commerce system for a personalized T-shirt on her behalf. When Barbie later goes to check her account, it has decreased by the T-shirt's cost.

Again, an in-game transaction has out-of-game consequences. In this case, the in-game transaction links to the out-of-game commerce system. You can use BIG to act as a programmer-friendly interface between the in-game transactions and the out-of-game commerce engine.

You also wish to ensure that hackers cannot easily penetrate your business systems, so a firewall divides the game infrastructure from the community infrastructure where the commerce engine resides. Carefully managed firewall holes reduce the danger of security compromises.

Take a look at the additional complexity now added to the game zone.

Figure 1. Revised game zone, with in-game services (and ancillary components)

Remember that every time you expand the scope of your game environment -- whether answering or anticipating gamers' needs by adding and refining services -- you are also contributing to your own best interests. Additional revenue means keeping the game going; that means the company can keep going; and that means you can continue to do a job you like.

Ancillary products and services such as image transfer to physical items and real-world-to-game-world (and game-world-to-game-world) economic exchanges enhance the player experience -- and help keep the business bottom line black.

Now look at the device connectivity requirements I mentioned in the scenario.