by Samuel Asher Rivello
Figure 1. Some leading MMO games.
Massively Multiplayer Online (MMO) technology has arrived in all forms of software. When we think MMO, we typically think of multiplayer games that enable many users to connect in real time to play cooperatively and competitively (see Figure 1). World of WarCraft remains the gold standard in the industry for subscription-based DVD-ROM MMO gaming. However using the Adobe Flash Platform, we can develop free-to-play browser-based MMO games similar to Wakfu and Small Worlds in a fraction of the time and budget required for WarCraft.
In this article, I explain how you can create a fully functional (and very simplistic) MMO social experience in less time than you ever thought possible. I also show you a few code samples to help communicate high-level concepts. The examples are specific to Flex 3 for deployment to the browser, but much of the information is equally relevant for application developers of other technologies, including Adobe Flash CS4 Professional and Flex 3 for Adobe AIR desktop deployment.
I hope this serves as a welcome introduction to the world of MMO games for beginners and teaches veterans a few things as well.
Massively Multiplayer Online technology has been mainstream in desktop PC game development for more than a decade. In recent years, we've seen its popularity soar in the browser, too. An MMO application is software that connects many users in real time and in which one user's actions affects other users with relative immediacy. Type a chat message and the recipient can see the message instantly. Attack an enemy and the enemy can take the hit or quickly block and counterattack. In its most common form, an MMO application is a community-based, personalized experience that is rich and interactive. MMO applications have many flavors: games (MMOGs), role playing games (MMORPGs), real-time strategy (MMORTS), first-person shooter (MMOFPS), browser-based massively multiplayer games (BBMMOGs), and more.
Tremendously popular is the MMORPG, or virtual world. A virtual world is an interactive simulated environment accessed by multiple users through an online interface.
Six common features of virtual worlds are:
Increases in computing power and technology have shifted MMO games from desktop applications to web applications. This article focuses on the latter.
MMO gaming is hugely popular. As more gamers get online with broadband speeds and as more Internet users try out MMO games, the audience expands rapidly. The engaging Web 2.0 and RIA features make these games immediately popular with players. Users are sinking hours of leisure time into these games — and where there are users, there are business opportunities. Whereas traditional commercial gaming sought to create a shelf item with a one-time fee for purchase, the ongoing maintenance required for MMO games and the advantage of connectivity to the Internet for play lead to other financial opportunities. Game developers and game publishers can profit from successful MMO games in many ways. There are several popular business models for MMO games. Publishers usually choose one or more of the following:
Surely, as the audience for MMO gaming expands, advertisers will become increasingly creative with how they monetize the games in this industry.
When planning interactive projects, it is important to create compelling creative and match it with the proper technology to empower your ideas and engage your target audience. In the following sections, I offer general MMO advice and discuss available technology choices.
Figure 2. RIP game logo.
As an example, let's pretend my market is 8–10 year old boys and girls and my secondary market is adults who like youth-oriented content. Just for this discussion, I created a simple, fully functional MMO Flex game called Rest In Peace (RIP). It is by no means a complete project, but instead it serves to help communicate the concepts of MMO planning and development (see Figure 2).
In addition to the typical challenges of attracting and engaging users, an added responsibility of an MMO game is to retain your audience long-term. The characters and story are two key factors for hooking and retaining your user base.
Here are some tips to consider when choosing the intellectual property for your MMO game:
For RIP, I used a friendly ghost theme (see Figure 3). When I created it, I could not find one friendly ghost–themed MMO game. So it is unique. Ghosts can have many human traits and may have some superpowers, too. This should allow for some good character growth. When I think of a ghost world, I imagine several things: new ghosts being introduced regularly, a fantastic world where anything is possible, heaven vs. hell themes, and characters that can die over and over again. These ideas should promote a long, rich storyline.
Figure 3. Character art.
With the characters and storyline chosen, you can get the writers and artists started and investigate the needed technology.
With MMO technology, there are two major camps to consider: client-side and server-side. Your completed project combines the two technologies. The client-side technology (that is, Adobe Flash Player, AIR, and so forth) will do all the heavy lifting — it is responsible for rendering assets and managing input from the mouse and keyboard. The server-side technology is responsible for shepherding messages between each player in the game.
Starting big and getting more granular, there are many questions to be answered when considering technologies. For example, what type of computer does your target audience use? Macs or PCs or both? Will this be a desktop experience, or will it run within the web browser? Will the game be a 3D world or a 2D world? And what software platform will achieve these goals?
For this exercise and with economy in mind, we used the Adobe Flash Platform to develop and deploy this game in 2D within a web browser. We used Adobe Flex Builder as our development environment. We combined client and server technologies, using Flash Player on the client side and ElectroServer 4 on the server side. With our client-side choice of Flash Player, I opted to use a ready-made server technology that includes an ActionScript 3 specific set of helper files because it will help speed development within Flex. In addition to ElectroServer 4, some leading server-side choices that support ActionScript 3 include Adobe Flash Media Interactive Server 3.5 and SmartFoxServer 1.6. If you are interested in creating casual online multi-player games without the headache of hosting your own servers, consider checking out the Adobe Flash Collaboration Service.
You may also be wondering why I chose 2D over 3D. While the latest Flash Player 10 has some exciting 3D abilities, it is limited to moving 2D objects in 3D space or using software-rendered solutions (which provides slower animation than hardware-rendered solutions) such as Papervision3D. I'm excited about the future of 3D in Flash Player, but in my experience, the Flash Platform is not currently the best choice for powerful 3D needs.
Now that I have decided on the friendly ghost theme for the storyline and characters, Flash Player for the client side, and ElectroServer 4 for the server side, I am ready to start developing the application in Flex Builder. For the user interface, we will dedicate screen real estate to meet specific user needs (see Figure 4). Each area handles user input and reflects relevant changes in the game:
Figure 4. Rough layout of components.
We will create Flex components for the areas outlined in Figure 4. For each component, we must consider the users' needs, decide on the UI elements to meet those needs, and take advantage of MXML in Flex to easily create the layout. This is a basic process in Flex development, so let's look at a brief example.
Like any text messaging application, the Chat Input at the bottom of the application's layout (see Figure 5) enables users to type text messages and submit them for other users to see in the Chat Log. This is the primary method of communication between players.
Figure 5. Chat Input component before final artwork.
A Panel container component (see Figure 6) holds TextInput and Button components. The ID properties are used to reference these components from the main application code to handle the requisite functionality; when a user clicks the chatSend_button instance, any text in the chat_textinput instance will be delivered to other players. In the next section, we'll see how this message is delivered to the server.
Figure 6. Chat Input component's MXML.
We continue with component creation as we lay down some of the client-server communication. A fundamental difference in developing for multiplayer use is that nothing should update onscreen in the game directly following user interaction as it does in single-player gaming. All game clients (each instance of the game running for a particular player), including the client for the player providing the input, should wait to hear back from the server that "Player 1 has sent a chat message," for example. Only then should the screen update. Player 1's client sends a request to the server, and the server sends a response to every client. Of course, Player 1's client must be ready to handle responses that it did not request as well, and it should update whenever any client sends a request. Player 1 uses Client (A) to send a chat message request and handle the response (see Figure 7). The message sent contains enough information for all clients to react properly. The reaction in this case is to simply put the response's text message into the ChatLog component for all to see.
Figure 7. Client-to-server-to-client(s) message flow.
In this game, there are five types of request/response pairings (see Figure 8). All interaction with the server side is through an ActionScript 3 object called ElectroServer. The pairings are shown in rough chronological order from creating the original connection to the server as the application loads and joining a room to the ubiquitous PublicMessageRequest. All the text chats and all the players' game moves (such as position changes, attacking, defending, and so forth) are sent this way.
When a PublicMessageRequest is sent with just text, it is typically handled as a chat message. But more than just text is possible. A message can be sent with an EsObject attached, too. This is a generic ActionScript 3 object. The developer packs the EsObject with useful properties — for example, the new x and y position of a particular player who is on the move across the game world. More complex games feature heavier use of EsObjects and pack them with more data. It is an art form to create complex games without sending too much data in EsObjects. Sending smaller pieces of information will help keep the game speedy. The final pairing shown is how to disconnect the client from the server room when the user ends his or her game.
Figure 8. Request/Response pairs for RIP.
Integrating the creative elements into Flex projects is straightforward because of the collaboration between Adobe Creative Suite 4 products. This is one of the major benefits of working with Flex. With careful planning and an efficient workflow, developers and designers can work concurrently on the project with minimal conflict.
For RIP, I started laying out the application's MXML while the graphic designer coded CSS to define the colors and fonts. I continued programming character movement and interaction while the artist created the background and character art using Flash. The three of us worked with little interruption because RIP's code references its visual elements externally.
There are two major types of visuals in Flex Builder: styling and skinning. Styling defines the basic component coloration and text display attributes within the application. The excellent (but far from complete) CSS compatibility in Flex allows for one CSS text file to define the styling attributes. The art team edited and saved this one file with each style change. An example of the styling is the panels' background color gradients and the various font treatments (see Figure 9).
Skinning defines the drawings and animations to include in the application. In RIP, the application embeds one asset SWF file containing the assets. The art team used Adobe Flash CS4 Professional to republish this SWF file with each skinning update. Each time the Flex project is recompiled, the published game is always up-to-date programmatically and creatively. An example of skinning is the RIP logo illustration or the friendly ghost animated characters (see Figure 9).
Figure 9. Finished game with complete styles and skins.
Now that we have a solid, polished build of the game, we are ready to give it a try. While it is not yet optimized for many users, the game should handle a few dozen onscreen. Joining the fun is easy. Click Connect and a uniquely colored ghost avatar appears onscreen. Type a text message to communicate and then click anywhere within the game world to guide your avatar. The depth of the game could be expanded to include avatar attributes such as experience and speed, missions to complete, inventory items to collect, and more worlds to explore.
Beyond the development of the game itself, there are two important ancillary considerations: integrating your application online and planning for the maintenance of your project.
Toward the end of your development cycle, you'll need to integrate your application online. During development, you can run an instance of ElectroServer on your desktop and interact directly with the published SWF file. Simply open two or more game SWF files on your desktop to test multiple users. This workflow allows for rapid development.
Once you are ready to test your application online, follow these steps:
Keep in mind that for most commercial deployments, you will also need some sort of player-matching system — commonly called a lobby — so users can find friends and start games. You can build a lobby into your game or use an external one. You can use one well-designed external lobby as the entryway into multiple MMO games, so you don't need to re-invent the wheel if you deploy multiple games.
In addition to typical application maintenance, including bug fixes and feature requests, MMO games require more up-keep following the initial launch. It is important to consider a launched MMO project as an incomplete game with ongoing needs. Many of the business models for MMO applications mentioned earlier benefit from a game with a long life of happy users.
Keeping users engrossed for months or years requires solid community management and periodic content updates. Much of the users' enjoyment will come from interacting with other players. The social dynamics of meeting new players and the dramas that follow will capture users' attention. This is one of the greatest advantages of the MMO genre for game developers. However, there is steep competition from other MMO games, and user-to-user enjoyment can be found with many other games, too. To keep your game exciting and fresh and to ensure your users stay engaged, create a maintenance strategy for launching more characters, worlds, and plot lines over time. Because developers often don't fully understand the maintenance requirements and therefore don't scope and budget for it properly, poor maintenance is the leading cause of death for MMO games.
MMO games offer engaging experiences for users, combining the best of Web 2.0 and RIA methodologies. They can be exciting projects for developers and profitable endeavors for game publishers.
Creating a successful MMO game requires careful planning, including developing characters and storylines that are truly unique and allow for growth, building an attractive visual design, and selecting appropriate client and server technologies to power the creative vision.
Development includes UI design, client-server messaging, game logic, and art and skins. We believe Flex Builder is an ideal choice for client technology because of its flexible development environment. Combined with Adobe Creative Suite 4, Flex Builder will get your team collaborating smoothly from the start.
If you plan something truly special, develop tightly, and maintain your project long after launch, you're sure to create a successful MMO game using Flex 3.
Upcoming Flex Events
360 | Flex Conference
May 18 - 20, 2009
Samuel Asher Rivello is the principal of Rivello Multimedia Consulting (RMC). RMC's Flash and Flex services include software architecture, consulting, development, and training. Sam has a decade of experience creating games and applications, and is currently traveling the globe to collaborate with top companies. Follow Sam on Twitter at @srivello.