Developer Forums | About Us | Site Map
Search  
HOME > TUTORIALS > GETTING STARTED > SITE PLANNING TUTORIALS > DEVELOP A HIGH LEVEL BUSINESS DESCRIPTION AND IDENTIFY PATTERNS


Sponsors





Useful Lists

Web Host
site hosted by netplex

Online Manuals

Develop a high-level business description and identify patterns
By Veronika Megler - 2004-08-19 Page:  1 2 3 4 5

An architectural approach to providing online game infrastructures

The business of the online games industry is a complex one, requiring the input and integration of many variables -- people, business conditions, product goals, and more -- to create, implement, and distribute a successful online game. Senior IT architect Veronika Megler ignites the first of a five-part series that focuses on infrastructure providers for online games. The series illustrates the state of the industry today and demonstrates how to develop a high-level business description and how to identify the all-important business patterns. The author offers eight steps towards this goal.

Twenty years ago, when I wrote computer games for a living, the industry was pretty straightforward. I wrote games, the company packaged them (well before the advent of CD-ROMs and CD-ROM drives for PCs, games were distributed on cassettes -- can you believe it?) and sold them. My employer made good money, I made more money than a college student could make most other legal ways, and I got to play all the computer and arcade games I wanted. Life in the game industry was good!

But I got bored, joined Real Business, and started working with Enterprise Applications. The years flew by and here I am again, working with the game industry. My how it's changed!

The major change in the industry is that every game (well, almost every game) can now be called an online game. Coupled with the phenomena that online access has increased astronomically, that attribute alone has added a tremendous complexity to development and deployment of games and game infrastructures.

Inside the online game industry

Describing the online game industry in any level of detail would take quite a long time and I want to focus on the development issues rather than the history. To create a context for this discussion, I want to spend a moment talking about the industry.

The industry that creates, distributes, and runs games is complex. Increasingly, game art is developed by artist studios rather than by the code developers who performed every task back when I was writing games. Game developers can vary from small startups with a great idea, to major entertainment studios who wish to capitalize on existing media assets by developing a game with movie, character, or brand tie-in.

Games may be distributed by the company that developed the game, by the game publishers, or by game consolidators. The game-development industry is starting to look more and more like movie production with its major studios and small independents -- who sometimes partner and sometimes compete.

Computer games come in many varieties. Game content or game style is substantially different: from role-playing games (RPG) to extreme sports; from strategy to first-person shooters, the ultimate high-twitch games. (High-twitch games are games that require fast reflexes in order to score well -- or even to play for more than a few minutes without losing.)

A common way of segmenting the games is by the number of players:

  • Single-player games often take a fairly short time to play, and appeal to the casual gamer. Games such as Patience or Tetris (the freeware version for Windows is called Tetrus), or casino-based games, often fall into this category. They may also be called turn-based games -- the interaction in multi-player versions of these games is often limited to competing for high scores.
  • In multi-player games groups of 2 to 64 players are hosted by a single server. These games are generally of a specific length and often possess the high-twitch factor. One example is Battlefield 1942.
  • Massive multi-player online games, or MMOGs, have thousands of people playing in a hosted-server game environment; the games generally run continuously, 24/7. Examples are Everquest (sometimes flippantly called Evercrack since it can be so addictive) and the Korean blockbuster, Lineage.

The ways in which these types of games are played differs, and the user interface and detailed technical infrastructure to support them varies as well.

This series will take you on a tour of what I'll call, for simplicity, game infrastructure providers -- a subsection of the overall games industry that includes the following:

  • Companies that have developed their own games and now wish to make them available to the game-playing public by hosting their own infrastructures.
  • Game consolidators, such as game portals, who provide those who want to play with access to a wide variety of games from a single source.
  • Publishers who, similar to game portals, may provide access to one or more games.

Later in the series, I'll focus on the infrastructure that game providers must build to fulfill the goals of these services.

While you'll find differences between single-player, multi-player, and massive multi-player game providers, most of the infrastructure needed by each of these types of game providers is similar enough that the same architecture can support all of them.

Before I move to the steps needed to get started in planning such an infrastructure, look at the environment that envelopes a game infrastructure provider.

Life as a game infrastructure provider

For the game infrastructure providers, life is complex. Making money from games has become more complicated. Why?

Services

A major reason is that subscription-based customers must be kept happy. They expect a set of services and, if those services are successfully provided, they'll enhance the overall income of the game provider. As time goes on, the game players (or gamers in industry jargon) expect an increasing number and complexity of services.

Technology advances

Another reason profiting from games has become more complicated is due to advances in technology, which creates further change. Game devices are becoming more varied and the games themselves are becoming more complex, requiring higher quality graphic abilities and more creative and intricate game play. Distribution, once primarily handled by CD-ROM, can be (and often is) provided electronically.

Investment requirements

Lots of money is also involved. Developing a massively multi-player game can take upwards of $12 million. Given the size of investment in developing a major game, the risks associated with that investment, as well as the opportunities to make significant, recurring profit, meant that it was just a matter of time before the "suits" showed up. And once they did arrive, it was only a matter of time before you start hearing the mantra:

Do more with less -- let's not re-invent the wheel -- reusable components....

Now, online game infrastructure development looks a lot more like other e-business enterprises. All joy and creativity is not lost, though. It's possible to take the overall list of enterprise needs and divide it into smaller chunks, some of which are unique to the game industry and some of which are well-understood enterprise problems that may be amenable to industry standard solutions.

It's really a transitional issue

This is an industry that is struggling with exploding complexity. And constant rapid change means transition. So that's what I discuss in this article: The infrastructure issues involved in the transition of game infrastructure providers from the free-spirited arena to the e-business enterprise.

I explore this view in this series by taking a few scenarios, demonstrating the functions they imply, and postulating a possible architecture that can support the scenario. I'll start with a simple view, then add further functions and scenarios as the series continues.

In this first article, you start to create your architecture using a business pattern approach, as described in the book Patterns for e-business: A Strategy for Reuse (see Resources). This template will also act as a mechanism to determine which additional functions you can add easily and which ones take a significant rethinking of the architecture.



View Develop a high-level business description and identify patterns Discussion

Page:  1 2 3 4 5 Next Page: The patterns approach

First published by IBM developerWorks


Copyright 2004-2024 GrindingGears.com. All rights reserved.
Article copyright and all rights retained by the author.