     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Massively Multiplayer Reusing the World Segmentation for Other Purposes The world segmentation algorithms suggested in the previous section could also be used on the server and client machines to facilitate/accelerate other common RTS tasks. Clustering: One of the more compelling ways to divide the workload of maintaining an MMORTS server cluster between individual machines is according to spatial world position: each server deals with all the game elements and players that are in a certain area. The world segmentation algorithm can be extended to have a seamless world map across servers and allow shrinking and growing of server areas in real-time (each server is responsible for a certain region, but a small patch of squares around it is still updated by adjacent servers—still viewed by that server. Having data in this patch continuously updated by other servers allows for a fast and easy passage of units across the seam). 3D graphics rendering: It is impractical to keep a mesh of the entire world in MMORTS games. Rather, the mesh is constructed in real-time on a need basis and a cache is kept of recently viewed areas. It is in general very convenient to construct the meshes for areas that match the segmentation, and to keep regions that are marked as viewed by the player longer in the cache (as they are inherently viewed more). With a slight effort, even fog-of-war calculations can take advantage of the viewed/unviewed division. The data structure can be easily used to answer queries like, "What elements are positioned at a certain location?" and "Which elements are near/around a location?" This greatly accelerates choosing targets for attacking units as well as other actions. AI: The proper segmentation lends itself easily to creating a tiered approach. First, one builds a scaled-down version of the map needed by defining each square region as a tile on a scaled map. Then, same-player groups of units that are geographically close together are aggregated together on the scaled map. This can be repeated iteratively. Distributing AI to Clients Because a great deal of AI is needed in RTS, simply adding a few more computers at the server farm is not sufficient to support the performance requirements. Since the connected users have a lot of CPU power at their disposal, it is logical to try to harness that power by distributing AI processes to the clients. We will focus on the technical issues of distributing processes, and will not dwell on the legal and semi-legal ones, most of which can be covered by adding one more term to the terms of use paper players accept as part of the installation. Still, it is worth mentioning that when one plays a regular, offline RTS, the client uses part of the CPU for playing "opponent" AI. We suggest that distributed AI in MMORTS games does essentially the same thing. Returning to technical issues, distributed AI still has to conform to the low bandwidth restriction. This has great impact on the type of distributed algorithms possible: We provide only guidelines. Fine-tuning depends greatly on the architecture of the MMORTS and of the AI and the exact algorithms used. More detailed discussion and specific solutions lie outside the scope of this article. The game should distribute CPU intensive algorithms, which require little input data and short output answers. Examples include terrain analysis routines (e.g., choke points), optimization algorithms over spaces with many variables (e.g., resource allocation and management), and searching of large data-spaces that are built on the fly. Favor strategic, long-range planning that needs only minor changes afterward over tactical short-range decisions. Favor sending strategic, long-range planning that needs only little changes afterward to the client’s overall tactical short-range decisions, which change rapidly and require constant updating. If distributing tactical unit decisions is important, transfer control of entire NPC armies to a client and do not divide them across clients. There is significant interdependency between units inside an army but little interdependency between units of different armies. Therefore, playing few NPCs of each army on each client will increase the bandwidth tremendously. All MMOGs share a common problem: content creation. The need for filling an enormous virtual world is a time-consuming and expensive task for game designers, who in turn seek automated solutions. Since the AI in RTS games includes many routines for "building," it is tempting to apply them also for automatic content creation. The local flavor of these tasks makes them ideal candidates for distribution. After deciding what to distribute, we are faced with the practical question of how to build a task-distributing manager. We start by collecting information about the bandwidth available for each client and processing power to decide which clients can deal with additional tasks. Next, each time there is a need to send a location-based query (e.g., terrain analysis) or transfer control over an NPC army to the AI on a client machine, send it to the most appropriate player(s). The algorithm should try to pick players already viewing the regions relevant to the query in order to reduce traffic. For playing NPC armies, this achieves even better bandwidth reduction because all the squares in which these NPCs reside are turned into PURs of that client. For reasons of security and robustness, send the queries to more than one client and keep only the majority result, which avoids dependency on any one client. The pseudocode for such a system is shown here:
Note that the list of players viewing regions of J can be formed very quickly by using the advanced world segmentation explained previously. Conclusion MMORTS provides great challenges to both designers and programmers. This article covered mainly the architecture and the algorithms needed to achieve low bandwidth per client (1–2 KB/sec) for transferring updates on large armies comprised of thousands of units. The basic idea common in many network games—only send information relevant to the client—was supplemented by world segmentation and complex actions. The suggested scheme also helps other areas of the MMORTS such as clustering and AI. References
-- This article is excerpted from Charles River's Massively Multiplayer Game Development 2, (ISBN 1-58450-390-4 ) edited by Thor Alexander.
|
||||||||||||||||||||||||||||||||||||||||||||||||
Features
|
|
|