We have quite a few things to solve here, and a lot to translate. Unlike the original, for this one we will need a game world that:
-Â Â Â Â Â Â Â Â Â Can accommodate many players, be persistent and offer different stages of experience to different players at all times.
-Â Â Â Â Â Â Â Â Â Can do away with the original division between Geoscape and Tactical Combat.
-Â Â Â Â Â Â Â Â Â Is structured in a way that can support many different avenues of play.
-Â Â Â Â Â Â Â Â Â Is able to be instanced and portioned, as required.
-Â Â Â Â Â Â Â Â Â Is a dynamic entity that can be transformed as the overall gameplay evolves.
First order of business is actually deciding what to do with the issue of the Geoscape and Tactical Combat. There were a few options (not many that I could think of, though), but I think by far the most effective and elegant at the same time is doing away with the Geoscape entirely. Instead, we will consider the game world itself to be the “new Geoscape”.
In other words: Players will not be staring for half the game at the Geoscape as it happened in the original (although that can be snuck in, if needed – the old Geoscape could perfectly become the new game’s “map” function). It is just too restrictive and this will be one of the major departures we will take. Players shouldn’t be staring at a map of the game world for half the game, but instead they should be surrounded by that world at all times.
In order to do this, the best way I could think was to begin to consider the world in a nested structure, such as:
Location -> Zone -> Region -> World
Locations: The smallest units of playable space. Player bases, cities to visit, generated missions and playable encounters (such as city attack/defense) are all locations.
Zones: A larger territory in which locations are placed. Zones will be not necessarily based on the current political borders between countries. Zones will hold the entirety of generated missions (interceptions always happen in zones and not in cities). This nested level is the one that will call on the majority of assets, in order to reproduce geographical diversity.
Regions:Â Are essentially abstracted groups of zones that we will use as large geographical “blocs”, for purposes of assessing squad money stipends, relative performance and reputations and contribution to the overall state of the game world. Think North America, the European Union, Asia, etc.
World: The world itself comprehends all regions and we will use it simply to display the overall progress of the game in terms of zones gained and lost as well as other parameters of interest such as overall reputation, conquest/defense progress via map and filter options.
Moving through the world:
Every player base is a point of departure from which they can travel (via ship) any other location in the world that can receive them. This includes:
-Â Â Â Â Â Â Â Â Â Other player bases, depending on permissions set by the base’s owner.
-Â Â Â Â Â Â Â Â Â Location cities in the world designed as social, recreation and trade spaces.
-Â Â Â Â Â Â Â Â Â Any active encounter on the map. This is an offensive action.
Players can only select the travel destination, not the length of the trip or to stop it once it’s ongoing. Travel can only be performed between locations. Not, for example, from a base to a random, non-encounter spot on the map, nor can trips have an unspecified destination.
Players can only enter enemy territory if:
-Â Â Â Â Â Â Â Â Â A location is known inside enemy territory (ex., a captured large city remains on the map, no matter who the territorial owner is. Its location is known to both factions and will exist there regardless of ownership)
-Â Â Â Â Â Â Â Â Â A generated encounter is located inside enemy territory (ex., a spacecraft downed in enemy territory)
-Â Â Â Â Â Â Â Â Â A location is discovered (ex., discovery of an enemy base location on the map by any means)
Travel times are absolute in relation to game world distances. For example, if it takes one real time minute to fly to an encounter location 200 game miles away, reaching another encounter location situated 1,000 game miles away will take five real time minutes. Players will have the option, as the game progresses, to acquire different crafts for their squads, with different characteristics in order to shorten flight times.
Zones are essentially unconnected to each other, and travel between them is not possible. They only form a cohesive structure and are visually next to each other on the game map. Travel by foot from zone to zone or from location to location is impossible (although there is the option to design structured, multi-location zones that would allow travel by foot). Travel to different zones can only be started from an appropriate point of departure.
This way of structuring the world naturally makes it look very fragmented; instead of a world, as a mere collection of points of interest existing separate from each other. In order to soften this and create a more tangible ‘whole’, travel should be visual at all times. We do want players to see and feel that whole as they travel, even if they cannot stop the trip and physically access it, because this lends a strong sense of continuity to the world. To allow instant travel between locations would finish shattering any illusion of a ‘whole’ world.
Re: travel times.
So players hop into their jet, and fly over your world and wait to arrive where-ever they’re going. What are they doing for the minute, five minutes, eight minutes, etc, that it takes to fly there? That’s a long time to be sitting and not actually playing the game…
Also, if you’re going to the trouble of making all of the locations have a specific place on your global map, how much of them can players see while they’re flying overhead? If they spot something interesting, can they (after they finish the first mission) fly back to check it out?
The major dilemma in my opinion seems to be that in X-Com, the time taken on the battle maps is likely to be wildly inconsistent with time spent elsewhere. Won’t that result in players being in wildly different points in the game timeline and limit how much they can interact? Because if one player is still on day one, and all of the other active players are building ships to attack Mars, it would probably be bad if the advanced players are selling/giving tech to the starting players.
But I suppose if the original X-Com ended up being converted into something like LotR book 1, or levels 1-10, then segregating by those bands might be feasible.
Ben:
“So players hop into their jet, and fly over your world and wait to arrive where-ever they’re going. What are they doing for the minute, five minutes, eight minutes, etc, that it takes to fly there? That’s a long time to be sitting and not actually playing the game…”
I’m not a fan of long travel times. I think emphasizing the size of the world is fine, but there comes a point where it starts messing the the player’s fun. I think you also have to be very judicious with how you use instant travel (if at all), because that destroys most of the world’s continuity.
The numbers I used are just examples. Ideally, I would say (thinking of the game world as a globe) that the longest flight distance, say to get to an encounter in the antipodes of wherever you start, should be ten minutes tops. You have to consider giving your players a brief break to get ready for the encounter (bios, getting a drink, taking a phone call, etc…) without giving them too much of travel downtime. I think ten minutes maximum flight is a happy medium, and it’s well, well below other games’ maximum travel times.
Sure, it’s tempting to just go ahead and set things up for something silly like 1-minute max flights, to “maximize the time to fun” with the best of intentions, but you also have to consider that your players are not robots and need their breaks. You can make travel instant if you want, but if your players need to take care of something else, their group is still held up in the meantime, so whatever time you gained by eliminating the travel times, they turn around and spend it anyway by waiting for the afk guy. That’s what the travel time window attempts to compensate for.
“Also, if you’re going to the trouble of making all of the locations have a specific place on your global map, how much of them can players see while they’re flying overhead? If they spot something interesting, can they (after they finish the first mission) fly back to check it out?”
No, only cities have a specific place on the map (because they exist, they are on the map and everyone knows where they are). The rest of the locations do not, and would not be observable during flight. Player bases are supposed to be underground, in any case, so even if they had fixed locations they would not be observable during travel.
So players can’t really spot something interesting, other than a city they already knew was there should their flight path take them over it. The rest of the areas are cosmetic content.
Brad:
“The major dilemma in my opinion seems to be that in X-Com, the time taken on the battle maps is likely to be wildly inconsistent with time spent elsewhere. Won’t that result in players being in wildly different points in the game timeline and limit how much they can interact?”
Yes, but there are a few ways around this. It’s not possible (I imagine) to perfectly replicate X-COM’s “flow” of a game session over one world with different players at different stages. So we have to separate and translate that flow. In X-COM the game’s progress (from first small base, to Mars, basically) was tied to the player because that’s all the game had to satisfy.
What we need to do here is to tie the game’s “flow” to the world itself, and not the players, because we cannot tie it to all of them at the same time. It’s the world itself that will slowly go through the timeline of advancement, and the players will contribute to it and tag along for the ride.
There won’t be squads getting to Mars at the same time other squads are just downing their first alien scout under this view.
Other options are: Sectioning the content, as you mentioned. Freezing the timeline and move things into a framework of “constant conflict” instead of a definite beginning and end. Or perhaps a combination of sectioned and dynamic content.
This is an important area which I haven’t got to yet.
I’m trying to read this in the 9.274 version of the safari browser and the header looks sorta chopped up. You should probably it out.