Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
December 19, 2014
arrowPress Releases
December 19, 2014
PR Newswire
View All
View All     Submit Event






If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Evolution of MMO Maps: Moving Bases
by Nicolas Weber-Krebs on 08/21/14 06:20:00 am   Featured Blogs

2 comments Share on Twitter Share on Facebook    RSS

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

The evolution of in-game maps offers opportunities for developers looking to create new gameplay experiences. Maps are of particular importance for MMOs, in which they play a central role as a tool to structure the socialisation of players.

Astro Lords: Oort Cloud allows players to constantly move their bases. It’s the first MMO to do so. Although moving bases are certainly only one step in the evolution of maps, they are nevertheless an important step, and bring a new dimension to MMOs.

This blog outlines the reasons for introducing a map with moving bases, the opportunities and challenges it creates for game design, and the consequences it has on processing power and hardware needs. 

Spherical Map Setting

The Dutch astronomer Jan Oort postulated in the first half of the Twentieth Century that a vast cloud of asteroids surrounded the Sun at a distance of almost one light-year. In Astro Lords, human settlers have colonised these asteroids and use them as bases for mining, constructing spaceships and ammunition and, unsurprisingly, launching attacks on each other.

The Oort Cloud is represented by a two-dimensional finite spherical map. The x- and the y-axes measure, respectively, the longitude (-180 to 180) and latitude (-90 to 90) of each point on the sphere. This is different from an MMO like Travian, where the map is an endless flat grid, with the x- and y-axes stretching theoretically out into infinity and without limitation to the maximal distance between two points.

In most MMOs, bases are castles or villages, which are founded in the centre of the map at the start of the game; new bases are then founded farther and farther away from the centre, like the ripples caused by a drop falling on a pond.

In Astro Lords, the asteroids of new players are located in the Kuiper belt – another scientific theory postulating that there is a disc of asteroids and meteorites cutting the Oort Cloud in two equal half-spheres. After players have passed the initial levels of the game, their asteroids jump onto the Oort Cloud, where they are at first in a kind of “solar-stationary” position, similar to the geo-stationary position of satellites around the earth.

Moving Bases

Obviously, the fact that the bases can move is rooted in the subject matter: castles and villages don't move, but asteroids do! Similarly, it should make sense to have moving planets in moving solar systems or galaxies. However, in the world of science fiction MMOs, before Astro Lords, there wasn’t another game – not even EVE Online – with moving bases.

When arriving on the Oort Cloud, the asteroids are not precisely solar-stationary, but are languidly drifting on the sphere. They move every hour up to 0.375 degrees on the x- and y-axes and change direction of up to 30 degrees. It would take an asteroid drifting in only one direction 40 days to complete a cycle around the Oort Cloud.

Asteroids can also be piloted, either in a particular direction or towards a specific point. The speed of the piloted asteroids increases from Jump Speed 1 to 10, depending on the science level acquired: when moving at Jump Speed 1, an asteroid takes 20 days to complete a cycle around the Oort Cloud, at Jump Speed 10 only 2 days.

The introduction of moving bases generates an important number of game design opportunities and, with them, a wealth of game design and coding traps. If taken to their logical consequences, moving bases could have become too complex to handle for game designers and developers, as well as for the hardware running the game.

Game Design Opportunities and Challenges

One obvious game design consequence from having moving bases is that a player can explore the map without having to come back regularly to a fixed point on it. Not having to go regularly and systematically through the same areas of a map should inherently make grinding less boring. Also, the player can make more friends and enemies and can flee from a harassing adversary to avoid being continuously attacked and beaten.

But what might at first look like a windfall of game design opportunities is also a major threat to the gameplay. By moving away, a player risks getting lonely, not only lacking friends and enemies, but also enjoying unfettered growth: eventually, the balance of the game and the gameplay experience would be the worse off for it.

In Astro Lords, this threat has been countered by several game mechanics:

  • The size of the Oort Cloud in the game is proportionate to the number of active players, somewhat like a balloon that can be in- and deflated.
  • Robot asteroid enemies and their spaceships can appear everywhere on the map.
  • Players can launch a “pirate raid”, which is aimed at a random, same-strength asteroid and has a fixed travel time, independent of the distance between both asteroids.
  • Strong, competitive growth is only possible through confrontation with other players or in densely populated areas.

Another game design consequence is linked to the armies stationed on the home bases. Astro Lords has the equivalent of troops (explorers, spies, spaceships) that can be sent out from one moving asteroid to explore or to attack another. Theoretically, the home base could have moved out of range after an attack. To avoid this bitter consequence, troops take a fixed travel time to return to their base after a mission, independent of the distance.

Astro Lords, as all other video games, sacrifices “scientific reality simulation” for the sake of simplicity and gameplay experience. A case in point is travelling time, which, although somewhat proportionate to distance, is generally calculated roughly: the squeezing of the graticules at the poles has, for example, not been taken into consideration.

Also, the asteroids are drifting or speeding on the Oort Cloud: they are not supposed to take short cuts to reach a point on the other side, but are expected to remain on the spherical map. However, if players are absent for a longer period of time, their asteroids jump out of the map, so as not to disturb active players.

Other potential gameplays resulting from the introduction of moving bases have simply not (yet) been exploited. The potential for asteroids to flee could have generated an “asteroid chase” gameplay. The potential for asteroids to collide has been sidestepped altogether: the asteroids move by instantly "jumping” through hyperspace once an hour, thus avoiding any potential impact.

Coding Consequences

In an MMO with fixed bases, the attack range of a base needs be calculated when it has become powerful enough to send out troops farther away than before. Moreover, the relative strengths of all bases in each other’s attack ranges need be calculated to determine if two of them can be matched for battle.

Attack and matching ranges also have to be calculated in a game with moving bases; but in addition, the positions of all bases relative to a given base have to be calculated to assess which bases have moved into the attack range of this given base and can be matched for battle. It has to be done for ALL given bases. It has to be done after EACH movement of the bases.

Clearly, this increases the number of processed calculations exponentially!

Some preliminary tests can be used to limit the number of calculations made: matching potential for bases that are not within each other’s reach should obviously not be calculated. However, such tests and other tricks will not significantly reduce the enormous increase of needed calculations, which is a direct consequence from the simple fact that the bases are moving relatively to each other.

From a player’s perspective, if the relative positions of the bases weren’t calculated often enough, clusters of bases would appear or disappear abruptly every time the calculations have been processed. The movement of the bases would be spasmodic, not continuous and smooth, as can be expected from objects moving in space.

In Astro Lords, the positions of all asteroids relative to each other are calculated every few seconds. Enemy asteroids appear regularly and stay in attack range for a reasonable amount of time before disappearing again. Piloting an asteroid on the Oort Cloud is perilous, but somewhat predictable.

Hardware Consequences

Using moving instead of fixed bases has an important impact on the number of calculations processed, on the number of database accesses, and on the amount of data generated. All other things being equal, a game with moving bases significantly increases the CPU and RAM needs and the HDD access speed needs; it marginally increases HDD size needs.

While technical issues aren’t necessarily the most important consideration for game design and development, an MMO with moving bases will require more expensive servers. A company that considers publishing an MMO like Astro Lords will have to budget high-end servers, with particularly performant CPUs and fast-access SSD HDD.

Looking Ahead

The reason why moving bases hadn’t appeared in MMOs before is probably that the consequences on game design, coding, and hardware of MMOs were daunting. In Astro Lords, these consequences have been kept in check mostly by limiting their potential. This leaves space for other MMOs to improve further on two-dimensional, finite spherical maps with moving bases.

Moreover, MMOs with moving bases have room to grow and evolve beyond two-dimensional maps. The next “natural” step in this evolution will be three dimensional, infinite maps with moving bases. These will appear in high-end MMOs and will most likely advance in several steps: at first with many limitations, but improving over time in complexity and scientific reality simulation.


Related Jobs

Bigpoint
Bigpoint — Hamburg, Germany
[12.19.14]

Senior Project Manager (m/f) – Hamburg – 3353
Gameloft
Gameloft — New York, New York, United States
[12.18.14]

Technical Director
Rumble Entertainment, Inc.
Rumble Entertainment, Inc. — San Mateo, California, United States
[12.18.14]

Senior Platform Engineer
Deep Silver Volition
Deep Silver Volition — Champaign, Illinois, United States
[12.18.14]

Senior or Principal Programmer





Loading Comments

loader image