Help resolve territory acquisition design difference of opinion in MMO RTS

Question

TL;DR: My business partner and I disagree about how to implement "territory acquisition" in an MMO RTS we are close to (alpha) launching:

1. My view: Small squares (5m edge) that get larger as you "level up", up to about 500m edge
2. His view: Fixed sized squares that are always 5km edge

Which is the better approach (mainly from a game design perspective)? And if you feel that my approach is better, how do I convince him of this?

Detailed question:

Hi there,

I’m an indie game designer and developer. My business partner and I are close to (alpha) releasing an MMO RTS, but we are stuck on how to handle one feature: territory expansion.

First, a few details about the game so that the answers can be in context:

• It’s played on a map of the world using the Google Maps API
• It is a “true” RTS – very little is abstracted.
• There are actual buildings you can place on the land, actual units that you can move around the world etc.
• Territory acquisition is currently by way of moving an infantry unit onto a “square” of land, which turns it blue meaning it’s now your territory (you can build buildings on it etc.)

Also, some details about our partnership:

• We have a 50/50 partnership on costs (and hopefully one day, profits!)
• We have shared, 50/50 responsibilities on design
• Everything else is assigned roles:
• Me: technical lead, coding etc.
• Him: Art, UI, marketing etc.
• We have been working together on this game for almost 2 years
• We live in different states and only work together remotely (although we have met in person)

Where we’re not seeing eye to eye is how territory expansion should work in the game. My view is this:

• Players start with a small “square” of territory (about 5m x 5m) and expand by claiming adjacent “squares”
• Once they hit a number of squares equivalent to a larger square (5 x 5 small squares, or about 25 x 25m), they can then claim squares at that size
• This keeps increasing until they can eventually claim 500 km x 500 km squares
• There is a mathematical model behind this, but I think all that is relevant is that the sizes align to degree increments, and that I have modelled it so that there are 10 “map levels” in the game, with the largest map level having about 2,500 large squares across the globe

I believe these are the pros and cons to my approach:

Pros:

• I feel that it adds a lot of “flavour” to the game having players grow in size and power from owning territory the size of a room in a house, then maybe a house, then a block, then a suburb, city, state etc. all the way up to small country size squares
• It allows players of different “power” to compete against each other in the same game world. Players at the smallest map levels can only see and claim territory from players of equivalent power, and likewise players at the largest level compete for vast tracts of land, and can leave smaller players alone
• It looks very neat – map squares always align on a grid, with no overlaps

Cons:

• Using this approach, players would not be able to see other players’ territories at different map levels. This is because territory would overlap, which not only looks terrible, it’s just not the way maps are represented, and also causes technical issues wherein any API you use (e.g. Google Maps) doesn’t know which layer you meant to click on
• However, players can see other, more/less powerful players’ territories by clicking on some up/down buttons so that players can see what’s going on around them at different power levels

His view is this:

• Squares should always be a fixed size, say 5 km x 5 km

I believe these are the pros and cons to his approach:

Pros:

• It’s simpler! My life as a developer and designer would be so much easier if squares were always the same size
• All players can always see all other players’ squares because everyone is basically at the same “map level”, all the time

Cons:

• It makes the game feel like a large checkered board game, or a big version of Risk rather than an RTS
• Basic grids like this have been done before in other games – I feel that my approach is more novel and interesting (albeit a bit risker since it’s new)
• Acquiring territory may feel “quicker and easier” as you start the game since you already start with a massive chunk of land, but I think that will quickly turn into a grind once you realise that there are about 26 million squares of this size on earth
• There is less aspirational value to capturing “more” squares, as opposed to a psychological player reward associated with being allowed to capture “larger” squares as you level up

A few more facts at this point:

• I was previously a professional game designer, so I believe I usually know what works and doesn’t work in games (although I’m only human, and can obviously be wrong)
• My business partner has no experience in the game industry. He is coming at this problem from a “this feels right to me” perspective
• I have already coded, implemented and tested my approach and it works perfectly (albeit with the constraint of having to choose to go up/down to view larger/smaller players’ territory)
• It has taken me about 2 months to design and develop this approach and it is an integral part of the (pre-alpha) version of the game
• The game has only been played by very few family members and friends, and we are maybe a month away from a private alpha launch to a closed group of people whom we both know

He is suggesting that we either go with his fixed square approach, start completely from scratch, or stop developing the game altogether (after almost 2 years of time and money, with maybe a few weeks to go before an alpha launch).

I guess I’m looking for advice on two things:

1. Which is the better game design approach: gradually increasing square sizes (with the constraints I mentioned above), or fixed square sizes (and their associated pros and cons)
2. If I’m convinced that my design makes more sense from a design, gameplay, technical, aesthetic and financial perspective (since I don’t want to waste the couple of months working on this feature, let alone the couple of years working on this game), how do I convince him of this?

Any external, objective advice on this is much appreciated.

Answer 1

Clearly, your business partner feels very strongly that your approach has some deep flaws and just won't work. If they didn't, they wouldn't be suggesting starting from scratch or abandoning the project entirely, especially not at this late stage.

What you should try to do first is find out why they think your approach won't work. This might be tricky, since their opinion might be based on just a "gut feeling" (to be fair, so is your opinion that it will work) which they may not be able to immediately explain in a clear and convincing way. They might also feel reluctant to get into a technical argument with you on a topic where you have much more professional experience, and where they may thus feel they're at a fundamental disadvantage just because they don't know the right jargon and buzzwords and can't lean on their authority from years of experience like you can.

So your first task will be to convince your business partner that you don't want to argue with them or to convince them that your approach is better, but simply to understand why they feel it's problematic.

You might want to start by telling your business partner that, if they think there's a problem with they way you've designed the territory acquisition mechanic, then you believe them. But also say that you can't really fix the problem unless you understand it, and that you'd like to try to help them analyze and explain the issue so that you can then find a good solution to it together.

If they bring up their previous suggestion of using fixed 5km tiles, say that you feel that has its own problems (as you've mentioned in your question above) and that, while it might be a possible backup plan, you'd really like to come up with a solution that still preserves some of the advantages of your original multi-scale solution, if at all possible.

In this case, be prepared to also have the same conversation from the other side, i.e. to try and explain to your business partner why your gut instinct is telling you not to go with the fixed-size tiles and what specific aspects of your original approach you feel would make the game more interesting and playable. And try to do that non-confrontationally, in a way that your business partner can understand and relate to, without unnecessary jargon and without leaning on the "I'm the expert so I know what works" argument. Remember that you're not trying to convince them that they're wrong; you're trying to make them understand where your gut feeling is coming from.

---

Anyway, if you manage to have that conversation and explain the sources of your respective gut feelings to each other, what you'll probably find out is that each approach has issues that one of you considers to be likely showstoppers. It's even possible that both of you are right, and that both approaches do have major problems.

However, with a bit of luck, you may also be able to identify a list of features that you both do consider desirable, and possibly even come up with a third approach that keeps as many of those desirable features while avoiding the showstoppers.

I won't try to suggest any such third approach here, both because I don't know enough about your game and also because it wouldn't really fit into the scope of this answer anyway, but I do wish to point out a few implicit assumptions that you both seem to be making, and some possible ways of breaking them:

• You're both assuming that the tiles that players can claim should be regular squares. What if they weren't? What if the tile shapes were instead irregular, and maybe (more or less) aligned with real-world map features? What if the tiles could have different sizes (even at the same "zoom level")? What if players could somehow move tile boundaries, or even join or split tiles?

• You're both assuming that players can or should only interact with other players at the same "zoom level". What if players could have hierarchical relationships, with smaller-scale players being able to act as (more or less temporary) "vassals" of higher-scale players? Or what if players had to team up to claim larger tiles?

• You're also both assuming that tiles should be claimed one at a time. What if placing a unit e.g. claimed all tiles within a certain radius of the unit (with some sort of nearest-neighbor and/or first-come-first-served rule to handle cases where the same tile is within range of multiple units)? Then you could maybe use a fixed tile size, but have higher level units claim a bigger area around them.

Ideally, with enough thinking outside the box, you'll be able to work out some new solution that isn't just a compromise between your opposing viewpoints, but actually something that you both consider better than either of your original approaches.

---

Of course, it's also possible that this won't happen, and that your viewpoints turn out to be simply irreconcilable — or that, even if you do come to understand each other's objections, you simply can't find any solution that would address all of them.

In that case, you may simply have to pick one option and go with it, flaws and all. Or, of course, you could also pick neither and just abandon the game — but so late in the process that seems like a bad idea. Sure, you don't want to fall into the sunk cost fallacy and continue with a doomed project just because of how much you've already invested in it, but you also don't want to abandon a nearly finished game just because it might not be as good as you hoped. In the end, at least in purely financial terms, releasing a crap game is still better than releasing no game at all.

One option might be for one of you to agree to assume full control of the project and of all costs and risks going forward, with a correspondingly higher share of any future profits. (Obviously, any prior investment should still entitle the other party to a share of the profits as well, unless they're bought out fully.) Depending on the agreement you come to, that might involve one of you starting to pay the other for any remaining work, or of one of you quitting the project entirely and the other one having to bring in additional people to finish any remaining tasks they can't complete on their own.

In general, that's also the point where you probably ought to involve a lawyer or two, if you haven't already. Still, if done right, this should allow one of you to continue with the project as they envision it, with the other one retaining a share commensurate with their past investment but no obligation to sink any more time or money into the project. If you really cannot reconcile your visions, that's really the best you can hope for.

(OK, one more option would be for you to find a third party willing you buy your whole game project in its current form and to assume control of it. Depending on just how promising and close to being finished your game is, that might be possible.)

Answer 2

This is opinionated question. It can be fun either way and boring as well. Only you (together) can decide what you like best and have a better chance of implementing well.

Start playtesting!

It does not have to be fancy - from what I can tell, you can try starting with an A5 piece of graph paper and play with your partner imposing 10-30 players with a set of color pencils. Or use an online Excel, or playtest in some online grid-cell 2D game like Factorio. You can even do it solo. Try it with static square size and try it with growing square sizes - see how it behaves:

• with growing player count
• dormant squares
• how world size restricts you
• how game dynamic feels
• how players get in the way of each other
• and how this can be resolved (e.g. player with 10x10 square level wants to capture 10x10 square area occupied by 100 different 1x1 players)
• how it scales up for 10, 100, 1k players
• most important - does it feel fun?
• etc.

Ask your partner about their concerns and scenarios - what plays well and what are the problem cases. You both need to try to convert your "gut feelings" into a deeper understanding of pros and cons design-wise (and effort-wise, since you have a strong limit on time/workhours) and compromise to pick one or another (or maybe a third alternative emerges).

That will be your answer.

Answer 3

TLDR;

From a game design perspective. The complete, consistent, and well understood model beats out the incomplete model with unresolved (or unresolvable) technical or conceptual issues.

Based on your descriptions, it sounds like the con listed for the scaling territory design is technical in nature, and the cons listed for the non-scaling territory design are more a matter of personal opinion.

In other words: The game could be made to work consistently in a readily understood manner with the non-scaling design, but the scaling design, as is, still has at least technical holes in it, but from my understanding it seems there are conceptual holes as well.

There are a lot of particulars that I think need to be answered but the biggest problem as I see it is that players can't see/interact with players operating on scales above and below them. This sounds great in that the big players can't just squash the newbies, but complete isolation isn't going to be possible in practice because players need to be able to cross into the next scale up as they grow otherwise they are all just playing 10 different games. Given that you indicated there were 10 different scales, this means that for any particular location, there can be 10 overlapping domains, but at any scale, the location can only be owned by one player.

Lets leave off the technical issues presented by the map API's for a moment, and just explore the multi-scale world conceptually for a moment:

Given these players, how does promotion work?
The Insurgent -- 'A' scale player getting promoted up to 'B' scale.
The Overlord -- 'B' scale player controlling the 'B' scale territory The Insurgent will be promoted into.
The Rival -- 'A' scale neighbor of The Insurgent before before promotion.

• How does control pass to The Insurgent?

  • Does The Insurgent automatically claim the territory from The Overlord?
  • Does The Insurgent have to fight The Overlord to win the territory?

• What happens if this was the only territory controlled by The Overlord? (Are they out of the game from a threat they had no options to defend against?)

• What happens The Insurgent's new 'B' scale territory is in the middle of an area all owned by The Overlord?

  • The Insurgent has an advantage against The Overlord because The Overlord now suddenly has 8 more border territories to defend? (assuming diagonal attacks are possible)
  • Does The Insurgent quickly lose the game because now they suddenly have just 1 'B' scale territory, and The Overlord can call upon the production of their other 20 something 'B' scale territories to put down the insurgency? (just small enough they didn't get promoted to Over-Overlord before the insurgency.)

• What happens to the long standing 'A' scale border dispute between The Rival and The Insurgent after the promotion?

  • Since The Insurgent can no longer operate at 'A' scale are their territories now undefended?
  • Can The Rival now just walk in and snatch up The Insurgent's 25 'A' scale territories in quick succession and get promoted into the same 'B' scale territory The Insurgent just claimed from The Overlord?

If you have solid answers for all this, the scaling design does seem like it could have some late-game benefits to it (no longer having to manage the minutia), but if not, it seems like the whole scaling scheme is incomplete at best, or completely broken at worst.

Answer 4

I very much agree with Ilmari Karonen's answer, and believe that the best solution here might be to generate more solutions to the problem, perhaps breaking away from assumptions you're making. Might I humbly suggest one that seems consistent with how your game appears to work?

Have you ever heard of a Voronoi diagram?

The basic idea is that, given a set of marked points on a field, each unit of area on that field is colored according to the marked point closest to it, with the result being an interesting emergent "mosaic" structure. More interesting patterns appear if the marked points are allowed to name their own colors and share colors with other points - you could imagine, say, in a field with red points on the left and yellow points on the right, a diagram with a red region on the left and a yellow region on the right with a jagged line in between depending on the points' arrangements.

I propose you could make territory acquisition work the same way: ownership of a given point of territory is determined by the building or unit closest to it. When someone tries to build a building, you simply figure out who owns the closest unit or building to it - if it's the current player, you let them build the building. When you want to highlight who owns what territory on the screen, you draw a Voronoi diagram with a marked point for each unit and building in the immediate area. To keep territory from extending too far (and avoid having to potentially query every single unit in the game), you'd impose a maximum distance for which a unit can be considered, either a fixed distance, or something similar to your scaling idea where the region of influence grows as you rank up.

A really cool pro to this approach is that territory acquisition becomes incredibly natural. For instance, if you have two armies fighting across a river (or other natural barrier), the territory acquisition pattern will more or less follow the river. If you have a small player marching into a much larger player's territory, the territory acquisition pattern will show the first player controlling a small enclave immediately around them. All of this works at any (continuous) zoom level, and it's all possible with not only not having to consider geological features separately, but also not even having to consider territory as a permanent entity at all - it is simply a function of the units and buildings currently on the field.

(As another plus, the lack of hard territory divisions also makes it easy to account for the fact that the world is round, allowing the game to be played just as well around the poles and avoiding inaccuracies caused by 2D map projections.)

Of course, there are some cons to consider, too:

• You had better make sure those units and buildings can be queried efficiently, especially if you have a scaling maximum distance. Using something like a quad tree, even in the database layer, is a must here.
• Gameplay would be slightly different: in order for a player to keep claim on territory, they would have to leave a building behind. You could probably make a cheap building for expressly this purpose, though, such as a flag.
• Depending on user feedback, you may need to account for geological features anyway. For instance, in the aforementioned river example, you may find that the results are really ugly when the territory line doesn't quite mesh with the river, so you'll want to make it a boundary of some kind for the distance calculations.
• Calculating exactly how much territory a person owns would be more difficult, because you'd have to consider all of the units on the field instead of just counting squares. It would be hard to give users a real-time update for how much territory they own, and you would need an efficient way to calculate an estimate on the server in order to grant rewards based off of it (essentially, you would need to draw a Voronoi diagram of the world on it very few hours, like a global census). Doing this might require you to supply your server(s) with GPUs, incurring additional hosting costs.

---

ADDENDUM: For something easier to calculate on a global scale, you could make it so that only buildings determine territory acquisition (i.e. marching units do not claim territory, but must build a building first). This makes it a lot easier to calculate global territory acquisition (since buildings normally don't move), but does come with some caveats:

• The fact that you have to build a building to acquire territory may be unworkable for your game's design. If it does work for you, you may find that you either need simple buildings to satisfy these requirements (such as flags), units that can still claim territory (perhaps a "commander" unit), or exceptions to the territory claim rule (such as being able to build on unclaimed territory, or perhaps a "campfire" building that can be built anywhere, including in enemy territory).
• You will probably also have to implement a maximum range of influence, so that you can feasibly have territory owned by no one. Otherwise, it becomes impossible for players to build if they don't have a building already.
• You wouldn't get the "cool" effect of territory acquisition following combat lines. You could probably calculate with units on a local scale and use global scales for the census, though.

Answer 5

Why not both?

Go with your approach first, as it has already been implemented, let's for call it Arj mode for now.

Then implement the other approach later, let's call it Partner mode.

Offering two modes, means offering two servers, with double the effort to maintain. But if one server is offline, the players can still play your game on the other server. You can also sell Partner mode as a game expansion, to cover the costs of implementation.

You and your partner could collect server metrics, and if Partner mode (or Arj mode) shows to have too few players, you can decide to shutdown that mode later.

I can see that both modes growing with different rules could be enjoyable for different reasons. As a player, I would like to play both of them, and to form my own opinion. But over time, your players will stay with the most enjoyable mode.

Even if some rules are weak, together they are strong. Market the rules as features.

For Partner mode:

• Not grind, but extremely hard.
• By being able to attack everyone, total freedom.

For Arj mode:

• Not being able to attack weak opponents, and not being attacked by strong opponents, fair.
• Progression of conquest tile size, dynamic growth.

There is a lot of things that could make Arj mode or Partner mode dead-ends, like powerful players being unable to find opponents, or new players unable to expand. Both modes can fail, so there is still more design decisions to be made. This is why I believe both should be tried.

Answer 6

Have you considered negotiating equity? If you're confident that this design decision will impact the sales of the game, and that there is no other way to convince this person that the group should go in your direction, maybe you could give him some equity in exchange for more control. If he gets an extra 5 or 10% of the cut, this might be enough to sway him to go your way - and then in the end both parties get more of what they want. And then in the end if the design decision ended up helping the game by significantly more than 5-10%, then you'll come out ahead.

Answer 7

IF you have "rounds" (the world is not persistent and each game ends after some time), like most such games, then most relevant players will be competing on the same scale, likely with additional accounts used to undermine the opponent. It could be an interesting back-stabbing game, but I believe it would make a pretty poor "classic RTS" given you have threats you cannot even counter (without alts).

Assuming rounds, there is also a possible "compromise". Game starts with tiny scale tiles, possibly your 5m. Then, after some time, say a week (or some other threshold like top player strength), ALL tiles grow to the next size. Probability to get the next square is 4% per smaller tile comprising it. You start small, then grow in size and power so you don't have to manage many tiles. Inactive players would likely die during merge. The game would play much closer to his proposal of fixed-size tiles than yours, but it would retain your "no need to take care of thousands of tiles" reservation of his approach.

If you want to have persistent game, his approach (as well as this scaling mentioned) will likely not work. Area grows faster than length, so bigger players are less vulnerable and will easily smash smaller ones. Your idea is pretty good in this case - top dogs will be fighting on global scale, but you could still battle other newcomers (and alts) no matter when you join.

Answer 8

Why not both? What I mean by that is start off with small squared, and expand them, however make each bigger square contain smaller ones. This might add to diversity in the form of having "small" players attack "big" players, and thus being big doesnt mean you can not lose. As a big one attacked on multiple fronts you will not be able to defend each attacked small square. So even though you win 10 battles, you will lose 1, and this might help for a weirder shapes formed. At least this is how I imagine it.

Answer 9

I dislike idea #1—as a territory system—and will try to provide a compelling argument. Unfortunately, these kinds of design decisions are hard to reason about.

I do know about a game that has world-territories that's worth reviewing: Ingress (by Niantic)

---

My Argument

I think, the multi-tiered territory feature is an over-engineered solution to a "solved" problem. That is, when I (as a player) think about games with territories, I think about static regions like squares, hexes, or polygons (Risk). This is an indicator that multi-tier territories won't meet expectations. I'm not suggesting you and your partner shouldn't have creative liberties in the game—but seeing what other similar games(products) do is a good way to reduce complexity—as someone else has solved it for you!

From a gameplay perspective, this sounds like a management nightmare. Most RTS's are about command bandwidth: quickly and accurately controlling your units. Having to zoom-in and out to regions seems like it would exponentially increase the complexity of controls at least one magnitude. Games with learning curves will limit your audience.

From a technical (maintenance) perspective, multi-tiered territories are significantly more complex to implement and maintain. In the future if you decide to refine your system, you are working with multi-tiered data versus an array of squares (oversimplified I know).

Finally, don't fall into a sunk-cost fallacy. Just because you spent 2 months designing and developing this for pre-alpha, shouldn't be an argument for keeping the feature in the game. A feature should be in the game because it's right, the only option, or because there isn't support/motivation to change it.

---

My Recommendation

Although the grid idea works, I think a hybrid approach would feel better:

Have the world broken into a grid of a base size (e.g. 5km x 5km). All game logic only care about that. This simplifies the coding and the gameplay.

Then visually, you implement groupings of the territories so you can see who owns what at increasing sizes. These wouldn't have an affect on gameplay but satisfy most of your "pros".