So, I'm working on an RTS right now, and I'm looking ahead at the final product, but one thing is eluding my vision. How to make the world massive enough for players to feel comfortable without breaking the map into chunks that would be disconcerting to the players.
I'm thinking the map has to be at least 1000x1000 for decent 4 player game, with room enough to expand and still have space between player bases for NPC tribes and unclaimed territory. A map that size isn't such a big deal for BYOND, but when I factor in other systems, turf count starts to become an issue.
And honestly, 1000x1000 still seems small to me. Something at least twice that size would feel about right for 4 players and a full game session. I have to remember there will likely be large water areas between players, so those will take up considerable space.
I thought about using SwapMaps to break the world down into natural divisions, like individual landmasses, or maybe splitting them at mountain ranges. The problem is the division, though. It has to be fairly natural or it will seem very jarring when you change maps. Foomer once made seamless maps, but I doubt I could pull that off with this project.
Splitting the map does have great advantages, however. I can ignore fog of war for maps that aren't being used by players, and unload areas that have no active players and simply calculate in the background what should be going on there. That'll really help keep the CPU usage down, but I'm not sure the benefits outweigh the fracturing of the game world.
Most RTS games I've seen take place on one huge map. I'm not sure how the players would react if they encountered an edge halfway to the nearest player, especially if the other side is swarming with enemy units you *should* have seen before getting that close.
Any thoughts?
ID:151939
 Sep 5 2008, 7:45 am
|
|
I had considered that, actually. Here, let me repost something I have up on my development forum for this game.
Scale and Scope =================== This one is killing me. The more I think about the game, the smaller the scale gets, and yet the larger the scope of events on this scale. I need to find a workable middle ground. I want to represent individuals and low-level events and actions, yet still give the player a detailed look at the whole world. Map size is going to be a problem, I think. A decent 4 player map with NPC tribes will have to be around 1000x1000 tiles, considering space for growth of each tribe and room for the NPCs between them, and even that is going to feel cramped. And what's worse, it's going to have to all be on the same map. :/ So... I'm thinking about splitting the game into an overworld map, and then splitting that into smaller maps as needed with swapMaps to map out the developed lands on a larger scale. The overworld map would show developed areas, cities, towns, the like, and interconnections, national borders and large-scale terrain features. The sub-maps would hold smaller scale terrain features, individual structures and units and local resources. The fog of war would cover the overworld, but not the sub-maps. This will save on processing big time. If units moving across the over-world map encounter hostiles, a new map will be created for the battle, and be removed once it is concluded. This is only done if the players view the battle, otherwise the conflict is simply calculated internally. New development ares are given new maps, which are destroyed only if all structures in the area are demolished. I think this mix will work well. It'll give me that world-wide perspective, yet still allow for tactical situations and small-scale interaction. The separate maps shouldn't feel too out of place, provided we never split a development area or battle field. We can ensure that by just limiting the players to set map sizes, possibly chosen by the host or voted on by the players. It might be just fine to reuse the same unit graphics for both the overworld and sub-map areas, since they are grossly out of proportion in either background anyways. I can make simple graphics to represent towns and cities, like Jon Snow's A Game of Kings, and structures on the sub-maps will be large individual images placed by the player and constructed by the civilians. I actually, even wanted to take it one step further, and let the player design and construct each structure themselves, sort of like the Castles games of yesteryear, but that's probably just too much for one game engine to handle. :P | |
Are you sure you want maps that big? We're talking 32,000 pixels of freedom on both the X and the Y axis. Even the huge Total Annihilation maps (what I consider the benchmark of large-scale RTS that doesn't involve the ability to zoom in or out à la Sins of a Solar Empire) aren't that big.
| |
One million square tiles isn't enough for you? o_o
Personally, I would dislike having big edges between me and another player, especially if it ended being why I lost. If you do do it, try and make it as seamless as possible, because a little edge won't hurt (a few tiles), but a lot of edge can kill (10+ tiles). | |
There's no way you could possibly need that many tiles. Archipelago creates a somewhat isolated environment for 12+ players with only a couple thousand tiles, a million tiles would mean players would never find each other.
| |
Yes. Considering 4 players on a standard Conquest (default game mode) map, taking into account the size of units, structures, NPCs and the space between, it will have to be big.
avg unit size would be about 64 pixels square, but could be as large as 96 square avg structure size would be about 128 square but could be as large as 160 square You'd need a minimum of units and structures to maintain your civilization, room between you and your opponent for open space, large water ways, NPC controlled tribes who may have their own structures and plenty room for everyone to grow. | |
I'll decide what my project needs, tyvm. I'm not requesting an alternative to a massive world, just alternative solutions to a single map that aren't disruptive to the gameplay. The subtitle of the game is "an epic game of conquest" for a reason. :P
| |
Yeah, that's one of the problems with breaking up an RTS map.
So I'm thinking this... If I can break up the map into small SwapMaps, then total world size is no longer an issue, since only 4 maximum map areas would be in play at any one time (maybe a couple more if the players are switching areas a lot), and those can be a great deal smaller than the overall world, say 100x100 tiles on average. Gamers are already used to overworld maps, and many RTS games use them in single-player campaigns. The difference here is the smaller sub-maps would only hold one development area, or the equivalent if being used for exploration or fighting. Leaving the sub-map would just require switching to the overworld map and moving your units, or moving them to the edge of the sub-map, where they would then show up on the overworld like many RPGs do when leaving towns. If I represent units and structures on the overworld map, so you don't enter a sub-map blind, and only allow entry to sub-maps from the overworld (no sub-map to sub-map edging issues), then there shouldn't be any surprise ambushes by enemy armies who've amassed at the border of the sub-map, since you'll see them on the overworld map before you enter. I guess this will do. I won't have to rely on unnatural terrain features to separate maps, and players should still be able to see what they're walking into. I can prevent structure building a certain distance from the edge of sub-maps, so players will only have to worry about stumbling upon an army at the edge of an occupied area. | |
It would definitely be possible to give the appearance of larger maps, although it would take a little legwork and the added overhead may not be worth it in the long run.
Basically instead of 1000x1000 maps, you would work with something like 980x980 (depending on how far people are able to see). The remainder of the 1000x1000 tiles act as overlaps on the adjacent maps. The legwork comes in in settings things up to look like they're on both sides of the map (creating an image on the other maps at the proper location). Then it just becomes a matter of writing everything so that essentially theres only x and y coordinates rather than x,y,z. The final effect is once the player would move to the 981st tile of map A, they get sent to tile 20 on map B, but since you cloned the images of everything on map A's tiles 981-1000 onto tiles 1-19 of map B, the player would have no idea they changed maps. As another possibility, which depending on the detail of the artwork may not be possible... Scale everything. Half-sized you could have a 2000x2000 map, quarter-sized a 4000x4000, etc. | |
What exactly are the issues you're having at the moment that make you need to divide up the map? Unless you're executing code over a whole mess of turfs the overhead of having that many shouldn't be too bad. If it's a matter of objs, mobs, and stuff you can just have all the turfs loaded and then break up the map into maybe 100x100 chunks which have the objs and mobs loaded in and out as necessary then you don't have to deal with borders as long as loading happens before any of the turfs in question reach the players view or have any long reaching effects the player might notice.
| |
I'm concerned with the number of turfs in play, but it's not as important as the number of units in play. I suppose I could just unload units out of range and keep the map solid. I think I can vastly improve my fog of war using areas instead of turfs, which will help quite a bit. I'll have to run some test when I have something more than a demo working.
| |
Either that or some notion of mini-map to get around the issues of large forces piling up for an attack on the edge of a map boundry.