The game infrastructure has to store the state of the game environment and all the entities in it, as well as provide an interface for the actual playing. Choosing the mix of back-end and front-end technology is another aspect of the game system that will feed into design and implementation decisions.

There are many different possibilities for the front end: it can be via HTML over the Web or it can be via a special custom software package, for example. They both have their own specific drawbacks and strengths. One obvious strength of an HTML interface, for example, is its portability. On the other hand, a custom interface package might provide a richer playing environment—although the gap between the two approaches is continually narrowing as machines become more capable.

To obtain the widest reach, portal style connections can be used. These make use of multiple and varied interfaces for different devices and different kinds of interaction. For example, updates can be received by e-mail, and limited access can be offered via a handset-specific Web portal, with the full richness of the interface only exposed via a dedicated Web page or specific software package.

One of the key points of a multi-player game is that there is interactivity between players both within the game and outside it. We can look at two ends of the interactivity spectrum—low interaction between players and high interaction. Helping players communicate and interact is a key part of developing the game system as a whole.

Interaction between players will be different depending on how the game is implemented. Low interaction, for example, is typical for games where the player spends his or her entire in-game time creating something that only ever interacts with the rest of the game environment. For example, where the impact of the player on the game environment is known only after the daily update has taken place, there is often no need to communicate or interact with other players in order to play the game, and even succeed. However, this sense of operating in a vacuum can actually harm the longevity of the game.

Players like to interact with each other as well as the game. Curb, when designing Project Rockstar, for example, put a fake album cover competition in place, where players could vote for each other’s (invented) album art, as well as read song lyrics.

On the other end of the scale are those games where players can’t move unless another player has moved. These are highly interactive, and encourage players to communicate more; there is more of a sense that players are playing together. While interactivity is high for these games, they can also suffer from potential disconnect drawbacks, which can make them harder to play and can also restrict longevity. This becomes more of a danger the closer the game design moves toward the real-time game design described in Chapter 6, “Creating Arcade and Massively Multi-Player Online Games (Real-Time).”

Generally speaking, the games at this highly interactive end of the scale don’t restrict players’ moves beyond the natural restriction brought about by the various capabilities of their in-game representations. This is in contrast to the tight restrictions and guidelines that we examined in games with lower interactivity and longer update cycles. In order to keep the interest for these games at the lower end of the interactivity scale, a good community must be fostered. This eventually becomes part of the gaming system, and players often turn up as much for the social aspect as for the gaming side of it.

This is the face of the player in the game, as presented to other players. Therefore, players might like to have some initial control over the avatar beyond just having a standard set of looks for different classes of in-game entities, which is a workable default.

The more the avatar can be made to represent the actual looks (or desired looks) of the real-life (or imagined) player, the more of a connection that player will feel with the game, and the more emotional investment he or she will make. This then translates into an investment in time, and subsequently provides one of the hooks that retains old players and entices new ones.

Where many turn-based games fall short is in this aspect of the interface. They would, on the whole, do well to borrow from techniques offered by real-time games such as Second Life and World of Warcraft. Granted, these games have been developed on a larger budget, but it is perhaps more important for smaller, less-complex games to over-deliver in this respect in order to bolster their offering.

At the very least, customization should include the following:

There is an additional benefit: once the customization has been built in to the game, it can be exploited to generate characters later on as well as offer a randomization function to players to allow them to start from a semi-blank canvas. This can be taken one step farther in extending it into all parts of the game, at which point it becomes a part of the feature set, and even part of the game proper.

The chances are good that, on top of this, players will extend their time in the game environment by sharing screenshots of particularly bad-looking or good-looking in-game characters that they generate or come across. And, as we have pointed out, anything that extends the time that the player spends immersed in the system increases the success of the game by creating an emotional and time investment.

This effect can be further enhanced by the introduction of clothes and accessories that can be acquired with in-game currency, either earned or won. This can be extended also into areas of the pseudo game environment such as owning property (as in MUDs/Second Life/World of Warcraft/etc.).

While we call this the pseudo game environment, this customization might actually be part of the game itself. However, in a turn-based asynchronous environment, it is more likely to be just an extension of the original premise. For this reason, any extensions used to foster a community should remain in character for the genre of the game—for example, using an abstraction of scrolls in a medieval context or computer screens in a sci-fi context, etc. This will help to add to the authenticity—but, of course, will also be dictated by the level of abstraction used in the game itself.

Additional customization can be offered at the level of player profiles where their in-game statistics are shown. These collections of otherwise drab numbers can contain parts that should be customizable through a variety of mechanisms—graphical and otherwise—and this then becomes part of the community feel. For example, some players might, at the simplest level, be depicted in forums with a special symbol (or set of symbols) reflecting their relative success within the game. Or perhaps those who have proved specific skills can obtain badges that display alongside their avatar, or are even woven into their virtual in-game clothes. For the creation and delivery of avatars, it is probably better if the interface is somewhat customized. This adds another layer of complexity to the system, of which designers must be aware, but provides more flexibility than other techniques. There are plenty of precedents in real-time MMORPGs—from Eve Online to Everquest and Second Life—that prove that dynamic custom generation of characters both works and is capable of becoming a feature in its own right.

Services like Yahoo! manage quite well to allow creation of avatars using just HTML and CSS, and Project Rockstar also provides semi-custom graphics (they are actually static but can be recombined in interesting ways) that reflect the player’s in-game choices. However, Curb may have missed a trick here. It seems that the in-game representation of bands does not directly reflect their make-up—i.e., it is perfectly possible to create a band with six members, where only four are required by the game, and then end up with a band photo containing only four. It would have given a far greater sense of immersion if each band member had been chosen with respect to the player’s decision for hiring him or her—instrument, looks, style (genre), and so on—rather than presenting a stock graphic roughly representing the band. This might have added an extra layer of complexity, but it would also have given the game a little more depth that would have compensated for other visual flaws, if any became apparent.

The same error has been committed in the superficial customization options that Project Rockstar offers the player in terms of their in-game avatar, which, oddly, does not extend to the look, but only the textual description and name. The avatar is perhaps the most important part of a turn-based asynchronous game, and offering extended customization is practically a prerequisite in a non–real-time environment.

All of these tweaks add to the underlying turn-by-turn game and form the gaming community.

The community in any game is important. In fact, I would argue that fostering a community in a rule-based, turn-by-turn game that is basically all about exploiting statistics for the benefit of the individual player (or, more rarely, a team) is even more important than for other kinds of network-gaming models.

This is partly because of the social aspect of these kinds of games, but also because the player can choose a level of participation that matches his or her available time. Other kinds of games are an all-or-nothing proposition. Turn-by-turn games run the risk of becoming boring if no community is available to extend the basic playing model.

Adding a community element to the game can be as simple as adding forums discussing various aspects of the game and the players’ individual successes in the game environment, as well as sharing them visually. HTML gives a great way to do this using links, images, and dynamic content.

Games can take the community concept farther by allowing players to give gifts to each other or even hand out in-game money to their friends. In-game trading can then be either a part of the game mechanic itself (i.e., the design and model) or it can be conducted outside the game as a community feature.

Players also like to communicate with each other to discuss in-game strategy and possibly form alliances within the game; these can be either formal or informal arrangements. Many people prefer this form of communication over sharing their e-mail address with people who are otherwise strangers. The forum lets them stay in character whilst also preserving their privacy.

Some games also report that players use the forum to engage in semi-serious or serious competitions amongst themselves. These can be either instigated by the players themselves or by the game’s administrators.

Competitions can become a vital part of the community spirit. Gamers are naturally competitive, even when the competition is not strictly part of the game proper, and adding competitions outside the gaming system can be a great way to extend the turn-by-turn nature of the game and allow those players who want to, to become more involved.

So, competitions can be used as a way to reward players or just for the sake of one-upmanship. As with all other aspects of the multi-player environment, competition is just another way to use the background of the game to introduce ways to keep the community alive, and add stickiness to the game as a whole.

The reward can be a rare object, in-game currency, or special privileges. In the old days of MUD gaming, competitions based on knowledge about the game and its history were employed to choose users with administrative privileges, for example. More recently, Project Rockstar has used competitions to let players earn power-ups, which give their account benefits—usually by adding statistical points to one of their bands to make them either slightly or greatly improved in one of their key skill sets.

I have used this term a few times now, and it essentially means engendering the site with qualities that retain the attention of the player once his or her official game session has ended. It answers the question that the player is asking himself or herself, having just expended all in-game move capital: What else can I do?

It is also possible to derive revenue from advertising based on player participation and visibility of promotional material. The success of advertising as a revenue stream largely depends on stickiness (see the “Revenue Model” section at the end of this chapter). Put simply: The stickier the community, the more advertising revenue can be generated.

Part of the reason for choosing a turn-by-turn Web game, for example, may be that it is easy (relatively speaking) to implement, and the low investment in time makes it appealing to the casual market. This is the wide audience that will react well to a site that backs up the game by being sticky. If, however, it is just a pick-up-and-play game that nobody cares about, it will not make any money. The attempt to make it sophisticated and sticky may well end up costing the game developer more than just the time spent to create it in the first place.

So, there is a balance to be struck between the effort needed to entice players to stay awhile and the revenue that can be generated to cover those costs. All the other aspects of this first section of the chapter must be brought to bear on the issue, principally:

If these three combine correctly, they will generate stickiness—and, more importantly, make the player care about his or her in-game representation and desire to do better.

In the game environment itself, there is plenty of scope for allowing customization as well as the way in which the environment is presented to players. This starts with players providing simple textual descriptions of themselves, lyrics for any songs that their band writes, and other simple, gradual tweaks. The bands can be named (although not, as noted, the band members), and descriptive text attached to them. Also, a band’s progress through the game is more or less public access, so anyone can examine the band and see what the player has created.

The color scheme can also be altered (with CSS). This requires that players wanting to adjust it have some knowledge of HTML, and also opens up the possibility that players can get involved creating, sharing, and helping others create by way of informal tutorials on the forum.

There are also standard options for players to receive e-mail updates, and all the usual housekeeping aspects, as well as a vacation setting.

Each player in PR starts with 30,000 units of in-game currency and is invited to create a band. The player must remember to set enough aside for five or six weeks (each week is a real-time day) of updates before the band starts to earn any money. This is typical of the general start-up process for any game based around strong characters, be it real-time action or turn by turn. Often, a certain fixed amount of points or cash is attached to the creation of in-game personae.

Again, looking toward other gaming styles, the player might be asked to create a team of characters and given a pool of points to assign to various in-game attributes such as strength, intelligence, charisma, and so on. Each of these aspects is likely to cost a certain number of points, and in Project Rockstar, those points equate to in-game money.

Getting the balance between a solid skill set based on available funds and the depletion of those funds (be they hit points or money) is part of the game’s own balance. From a design point of view, this is also a vital area to work on to make sure that the balance is just right.

For the first real-time PR week, the band will also be on probation, which limits the amount of things that a player can do—i.e., no gigging. This concentrates the player on trying to build up a rapport with his or her virtual creation rather than wasting money without appreciating the nuances of the balance between money and power. It is like a tutorial mode, but can be irritating if it’s the third or fourth time the player has set up an account. Unlike many other games that use true tutorial modes, it cannot be bypassed. However, it does give players the chance to see what the various skills and weaknesses of their new creation might be. Almost nothing that takes place in this first week will bring in any money; that can only be earned through releasing a record or playing a concert. Money is also used for trading between players and setting up labels, which can sign acts and share the profit—just like in the real world.

The game itself is a simple Web-based, point-and-click interface. There is nothing advanced about the way the game is presented. This makes it playable on almost every platform; I have tried it on all kinds of desktops, laptops, and even a portable media player, with excellent results. This is something of a bonus over those games that use a Java- or Flash-based user interface, often something that is badly supported over multiple platforms. As Java becomes even more prevalent, though, it may be a good candidate for Web-based games in the near future, although it will always require that the game front end is downloaded to the client platform. The beauty of a pure Web interface is that this is not necessary, and the game can be played wherever there is an Internet connection.

Turn-by-turn games have to have an update cycle of some form. This cycle can take a variety of different forms, from turn-based update triggers to continuous re-evaluation of the playing environment. They all have their advantages and disadvantages; usually it is a tradeoff between processing time and availability and the practicality of the platform.

For PR, Curb has chosen a daily update (an in-game week). This ties up the system while it evaluates the results of the in-game actions of all players. Obviously, the more players there are, the longer this will take.

It works because once the bands have been instructed to perform certain actions for a day (or several days), there is nothing else that the player can do. The player’s turn—for that band, at least—is over, and he or she must wait for the daily update to see the results of his or her choices.

At the close of the day, whether or not the player has instructed his or her bands, the system updates itself and the decisions made (or not made, as the case may be) are played out. At the end of the update cycle, several things happen:

There are a few other things, but this list reflects the core of the update cycle.

Some randomness is also built in, so players can find that their artists have been involved in scandals and the like, at which point the player has to decide what course of action to take. These random events are also combined with ongoing updates such as voting on album art and activities in the various forums and community platforms. There is also the risk of a band member leaving after a string of bad gigs that leaves him or her demoralized, at which point a replacement must be found. It is these little attentions to detail that add spice to the game, and all are part of the daily update cycle.

As noted, balance is important in any game. Forcing players to connect with their in-game representations by making some stark decisions as to the various skills that they assign to them is vital; that way, they know that they have only themselves to blame for failure.

This ownership helps retain players, which is tricky for a game that only updates periodically. Between updates, it is easy for a player to lose interest. In PR, the initial question of balance comes when the player is creating his or her band—it’s a balance of available funds and anticipated earning potential and time-scale against risk:

In a fantasy game where the setup is about assigning points from a limited pool to attributes of a character, the same kind of trade-offs exist, but it is unlikely that the player would need to have anything left over.

Once the player is up and running in PR, there is a continual balance of income against money spent, the traditional video-game–design conundrum of risk versus reward. This leads to certain rules, some implicit and some explicit. The latter are as much there to help players as to make the game more enjoyable.

One case in point: the requirement to have 30,000 in game currency units available before being able to start a new band. Besides adding to the initial set of band-creation constraints, this also protects players from doing something silly and running out of money, at which point they must start over. On the other hand, some rules are there to provide balance in the larger community such as the requirement that players only have one band in a specific genre (i.e., rock/indie) and no more than three in one main genre (i.e., pop). This restriction is purely for the good of the game, and simply adds a little spice to each player’s decision-making process. In addition, it fosters a sense of repeatability—can the player repeat his or her success in another genre of music? (This is also bolstered by the fact that certain songs from certain genres must be recorded in studios of the same genre—revealed by their names—and that concert success is likely only in venues that appreciate the genre of the band playing there.)

All of these genre-based rules add to the immersion, and form a technique that ought to be repeatable across other genres of game.

Clearly this aspect of running systems could be an issue. In the past, one of the weak points of Project Rockstar has been the manual nature of the update cycle. If the chief engineer goes on holiday and something breaks, the updates have been known to stutter on rare occasions until the engineer could access the system and make a fix.

For a game that rests so heavily on the daily update cycle (a process that takes several hours), this is unforgivable. At least with a game that operates on a continually updating environment (even if it is turn based), there is no possibility of the ship being left unmanned; plenty of engineers should be available to monitor events. In other words, the game design dictates the necessity of a staff monitoring the system around the clock. In exchanging the complexities of a real-time action system for a daily-update model, one hopes to recoup that saving elsewhere—spending more on design, for example. But it can backfire by having only one member of staff dedicated to maintenance tasks—be they scheduled or unscheduled.

The point to take away from this is that maintenance is a necessary evil. Outages will happen, and there will be problems that result in the system going down and requiring a restart. They shouldn’t affect the game, however. At some point, turns still need to be calculated, even if it’s a manual operation based on a backup procedure.

Most turn-by-turn games will be broken down into sessions lasting a set number of iterations—soccer and other sports games can be based around well-known seasons, for example. Abstract games that are based on a continually evolving game world such as Project Rockstar can be divided into arbitrary rounds. These natural breaks give the developers a chance to perform maintenance, as the system can be made less available for a limited length of time as the changes are rolled out.

This is the classic solution to player absenteeism. As long as the player remembers to set the vacation settings (like setting a vacation auto-responder on e-mail), then it is an elegant solution.

Most turn-by-turn games (and PR is no exception) have vacation settings, which allow players to set the system to an automated update while they are away from their machine. At the simplest possible implementation level, it puts their session (indeed, their entire account) into suspended animation.

This in itself presents a small problem: If the account is suspended, then the player will lose ground to other players in the system as he or she will not accrue in-game points—be they in the form of in-game currency, experience points, or any other measure of in-game success depending on the gaming model and premise. Project Rockstar addresses this by enabling some updates to take place—although no vital decisions will need to be made. Money can still be accrued, but the band will not disband by itself, nor will any other make-or-break decisions be made.

Ensuring that the game continues as normal for the player with respect to the mundane, business-as-usual, aspects of the play session, whilst protecting them from anything that they might have been able to prevent had they been actively playing, is a key part of developing a robust vacation mode. Having said that, it ought to be possible to enable players to take a gamble and allow some decisions to be made on their behalf—we will cover this a little later on. The game design can also come to our rescue in that there are some actions that will take more than one update cycle to complete, and so it might not even be necessary to provide for an explicit vacation setting for short-term absences.

More frequently, a turn-based game where the update is driven by player action, and where several players must move in strict round-robin fashion (i.e., sequentially), might lead to a natural situation where there can be weeks between moves. This will probably be the case for play-by-e-mail turn-based games, for example.

In addition, if the game is being played on a platform that allows players to set their own pace, they might even decide amongst themselves to take a break. As long as nobody moves during the unofficial vacation slot, the game will simply not progress until they all agree to resume. Again, though, this is restricted to gaming models based on turn-by-turn, player-driven update game implementations.

For any other centrally managed game-update system, if a player leaves his or her account executing a task that takes five days to complete, and something unexpected occurs in that period, it could spell disaster for that player’s in-game persona. Subsequently, it is a good idea to offer some kind of extended safeguards in the guise of pre-programmed behavior.

What makes the PR model easy to appreciate and implement is the fact that it appears, on the surface at least, to be a statistics-based game. The natural emergence that makes it challenging to play (and more fun) is simply the playing off of each player against the others. In other words, the behavior is preset, the rules and calculations that determine success are set in stone, and the only thing that players can do is schedule tasks and try to influence the statistics that govern their own in-game properties. By doing this, they hope to ensure that they at least do better than the others, and eventually win.

Many, if not most, turn-based games are themed around the management of statistics, hiding behind an immersive abstraction. If you think back to the classic D&D model, for example, the roll of dice determined your fate, and the skill was in making decisions that balanced risk against reward.

This is where real-time action games and turn-based strategy or simulation games differ, of course; the skill in the former is based on reactions and inventory management, while the latter requires a slower, more considered form of decision making. Puzzle games sit somewhere in the middle—fixed moves, highly strategic, but with a player-driven update system.

All turn-based games tend to share one thing in common: There is no way to change behavior or create new behavioral models for the in-game entities to follow. At the most extreme end, we could say that there is usually no player-available scripting language. (There are a number of reasons why this is not usually a good idea, but we can break it down a little farther so that the solution is not quite as extreme as letting players make their own scripted turn-playing mechanisms.)

The innovative twist to the predictable pre-programmed behaviors is the occasional make-or-break decision that can be implemented in a turn-based game. In Project Rockstar, for example, these range from finding money in the street and deciding whether to hand it in or not up to full-blown scandals in the press and invites to appear on TV shows. Sometimes, choosing options leads to additional record sales; sometimes it leads to a dip in record sales. There are parallel decisions possible in most genres; all that needs to be done is to tweak them slightly to fit the game genre and premise.

While on vacation, these events should not happen. During normal play, however, they do happen, and will cause problems if the player does not take steps to deal with them. The game design usually calls for a time limit to be placed on making these decisions, and the default (random) option is usually bad.

Before we look at how a turn-based game might be implemented that takes note of all the success points from our case study and adds some innovations of our own, we should note that there are a few alternative approaches to the Project Rockstar playing model.

This area is great for generating income. It works on the principle that, after a certain level of play, the player faces a humdrum existence. To face new challenges, the player can pay a fee to upgrade to the next level, which might include more places to go, more interesting people/things to go there with, or just an enhanced experience.

A humdrum existence might then repaid over time by an automatic upgrade. However, the impetus is on generating revenue from players’ desire to continue (advance) quickly in the game. This is eventually coupled with peer pressure from players they have built up a relationship with in-game. Consequently, the drive to succeed and the kudos associated with it become a revenue opportunity.

This system could feasibly be coupled with a donation system whereby upgraded players could sponsor their peers to join them on the next level. It is a system that has been tried on the Fark.com Web site with some success. Although Fark is not a game (it classifies itself as “not news”), the upgrade system allowing paid members access to more entries than the general public generates healthy revenue for the site owner.

The other side to buying expertise, technological advances, and the like is limiting the capabilities of players with respect to their in-game prowess.

Besides specific upgrades, in turn-by-turn games it is also easy to implement limitations on movement and/or turns. These limitations could be a way to change the balance of the game where specific capabilities have been acquired, or used as a way to generate revenue.

For example, we can place limits on money required to do something as well as limits on the number of actions that can take place in a single play session. This is the approach that Project Rockstar takes, but there is no way to extend the limits.

Players reaching the end of their move limit for the session in other games might choose to buy a few extra movement credits in order to try to finish off their plan for the day. This is not available in the current Project Rockstar build, but it is a possible extension.

However, this should not upset the balance of the playing model. For example, in Project Rockstar, once a player has set one of his or her band members to a task (say, improving core instrument skills), then this task, logically, cannot finish until the requisite number of play sessions has elapsed.

The danger is that this mechanism would completely upset the gaming balance if players could buy additional time, allowing them to skip this limitation. So, offering players the possibility to buy themselves out of these limitations risks redressing the balance in a way that presents several drawbacks.

The limitations of a gaming system are the very things that we use to manage the difficulty level and keep interest high. As noted in the last section, there is a danger of upsetting playing model if we start to play with the limitations that have been designed in order to present players with a challenge.

In addition, there is the possibility that any approach that can reduce the natural limitations or even the explicit limitations of a system can give rise to cheating. We look at this later on in Chapter 8; for now, you should be aware that the more popular a game is, the more prone it will be to people trying to circumvent its limitations for their own ends.

Linked to this are practices that are not cheating per se, but more like devious playing tactics. These often have the sole purpose to raise vast amounts of in-game cash or capabilities for the express purpose of building an account position of high value. Then, a natural cycle of buying in and selling on occurs, where players with money will buy into other players’ positions, and those with time and money can build up a high-value in-game account very quickly and then sell it on. This would be fine, except where it becomes the norm, at which point it becomes loaded in favor of those with money—and the balance is, again, destroyed.

The final responsibility rests with the game developer: It is up to you to make sure that the in-game exploitation of rules and mechanisms does not detract from the game. Some games will build this around reset points, where the end of a round signals a loss of all in-game wealth and accumulated possessions. This has the desired effect, but can also be very frustrating for players who have invested time and money in building a strong presence. Clearly, if another solution can be found, as well as offering the possibility to raise revenue, then a compromise position is better than the black-and-white mechanism that total resets offer.

Two of the most common forms of advertising are pay per click (PPC) and display advertising. Google AdSense follows the PPC model, in which advertisers pay a certain amount of money “per click” that the advertisement generates. So, a single campaign can reach 1,000 visitors (people who actually click on the advert) for a relatively small amount.

A proportion (usually small) of the cost per click (CPC) is returned to the Web-site owner as generated revenue. For each advert displayed, the expected click-through rate can be quite small.

Without a specific action, the site owner will not make any money at all. This model is, however, popular with advertisers, but less so with publishers of Web property that has a low CTR (click through rate).

On the other hand, display advertising works in the same way that traditional advertising does—the content provider is paid each time the advert is displayed, regardless of any ensuing action. This is also known as “banner advertising,” although banners have become less popular over the years.

An alternative is to pay a set amount to the site owner for a certain length of exposure; this amounts to sponsorship of the game. The advertiser gets exposure for its brand, in return for which it pays the game creators for the prestige (or just the facility) of being associated with the game itself and having its advert displayed to the players.

It is tempting to splatter a game with adverts. The risk, however, is that the value of each advert is diminished as it gets lost in amongst all the others. There are many ways that advertising can be incorporated into the overall game interface so that this does not happen. They all rest on one key point, however: They absolutely must be targeted toward gamers. If they are PPC adverts, this is doubly important, as no clicks means no income, and it takes an awful lot of online, registered, active, players to overcome poorly targeted PPC advert campaigns.

One model is borrowed from e-zine (electronic magazine) and e-mail list advertisers, where every now and again they slip in a solo advert. A solo advert is one that is sent to some, or all, of the list, with no other content whatsoever, and in addition to existing mailings that players receive. These e-mails can also be sponsored by allowing companies to advertise in the daily update or status e-mails. This is a useful technique, as it conforms more completely to recent legislation with regard to unsolicited commercial e-mail (SPAM). This use of solo adverts has to be very carefully deployed so as not to fall foul of Internet etiquette and legal restrictions.

Then, there is onsite advertising using banners. This is a form of display advertising that is similar to real-world billboard-style adverts. It is easy to implement, and works as well as the material that is provided by the advertiser. Gamers, however, might well be immune to banner advertising as they spend so much of their lives online.

Next, it is possible to provide advertising spots in top 10 lists and other non-game areas such as forums. These adverts can even be used to break up the content so that it reads rather like watching TV: Every now and again, there is an advert that must be tolerated in order to keep enjoying the show.

It is important to test and verify different locations for different kinds of adverts. This is important because display advertising yields a certain CPM (cost per thousand impressions) whereas PPC (pay per click) adverts only make money when someone clicks on them.

Thus, while the price that can be charged per click is higher than the price per impression, sometimes the CPC does not translate into money directly, as nobody clicks the advert. Here again, though, correct targeting will help, as the more relevant an advert is, the more likely the player is to notice and click, it.

Designers must beware of trying to integrate advertising actions with the in-game currency or even the in-game mechanics themselves for advertising networks. These could well fall foul of the network’s own rules on advertising.

For example, the terms and conditions often explicitly prohibit encouraging third parties to click on adverts or use automated systems to click on them. This usually extends to trying to offer players (viewers/visitors) some kind of reward for having clicked an advert.

Of course, if you (as the game’s owner) also own the advert network, then this might not be an issue—but be sure to check with the advertisers first. The ramifications for getting it wrong aren’t just that you won’t be paid; your whole business model might well fall apart if you can no longer offer in-game incentives for real-world actions if that is the path that you have chosen.