6
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ Comments are not for extended discussion; this conversation has been moved to chat. \$\endgroup\$ – DMGregory Oct 23 at 12:16
  • 2
    \$\begingroup\$ Tangentially relevant: you mentioned 5km x 5km squares of his approach leading to 26 million squares. But then your 5m x 5m squares would lead to 26 * 10^12 such squares in total. Unlike mere 26M squares where you would have simple grid, this requires sparse representation on the global map. So, how do you plan to handle tons of users? \$\endgroup\$ – Zizy Archer Oct 23 at 13:01
  • \$\begingroup\$ Would you be able to give some context on the timelines for this decision. e.g. What was originally in the design ~2 years ago, what caused the decision to redesign the territory expansion, what kind of territory systems have been in the previous prototypes of the game, and is this feature (territory ownership in general) a major part of gameplay - or something that has been added in as a "nice to have" at the end? \$\endgroup\$ – Bilkokuya Oct 23 at 13:25
  • 1
    \$\begingroup\$ Is there any potential gameplay interaction between players with different size scales of territory, or are they basically on different planets? \$\endgroup\$ – Bridgeburners Oct 23 at 14:45
  • 1
    \$\begingroup\$ @Cireo Actually, it can - you just turn off "geodesic" and map "squares" become rectangular instead of curved. It's a feature of the API. There is some North/South "stretching" at high/low latitudes due to Mercator's projection, but that's to be expected. \$\endgroup\$ – Arj Oct 24 at 5:53
21
\$\begingroup\$

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.)

\$\endgroup\$
  • \$\begingroup\$ Thank you very much for this detailed and well-thought-out answer. This gives me a lot to think about when approaching "part 2" of my question: how to handle the relationship. \$\endgroup\$ – Arj Oct 22 at 23:46
  • \$\begingroup\$ I thought I'd also address some of the gameplay suggestions you made above: "Irregular tiles". Arj: Actually this was my first approach. Technically, it's almost impossible to align different shapes to the google map below it consistently across the globe. Also, having "shapes" rather than rectangles significantly complicates the architecture for many technical reasons I won't go into. Having a "grid" system is the only reliable way. "Moving/changing tiles": Arj: This would make it a very different game with far too many game rules needing to change :( \$\endgroup\$ – Arj Oct 23 at 0:49
  • 1
    \$\begingroup\$ This is definitely better than the current highest voted answer, shows many different perspectives on solving (or not solving) the issue. +1 \$\endgroup\$ – Redwolf Programs Oct 23 at 0:51
  • \$\begingroup\$ "Hierarchical relationships". Arj: This is a very good idea, and exactly the thing I implemented in a previous commercial game I was the lead designer on. I have been thinking about it for this game as well, but I don't think we can get there until we solve this fundamental game design issue first. \$\endgroup\$ – Arj Oct 23 at 0:52
  • 1
    \$\begingroup\$ @IlmariKaronen You're right - almost anything is possible given enough time and money :) The API definitely allows for any type of geometry and the ability to move it around. However, besides the technical effort of doing so, going back to redesign how the game would work without a grid just doesn't seem like the best investment of my time right now. After all, like others have suggested, good or bad we could ultimately go with one of the two options if we had to and just "see what happens", rather than design a whole new system from scratch. \$\endgroup\$ – Arj Oct 23 at 22:34
34
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ Thanks for your answer Kromster. Unfortunately, we live in different states and only work remotely, so getting together like this isn't possible - everything is either demoed in-game or using screenshots etc. However, there is a lot of merit in your suggestion of asking him to try to "draw" his approach so that I can visualise it. I'll add the fact that we work remotely to my (already long!) question. \$\endgroup\$ – Arj Oct 22 at 23:23
  • 7
    \$\begingroup\$ You could probably replicate something like this with Google Sheets. Either way, this answer is correct: for a game design question like this, there's nothing like playtesting. \$\endgroup\$ – Merus Oct 23 at 3:11
  • \$\begingroup\$ @Arj Merus is right, go Excel/Sheets or some other online way (e.g. some grid-cell game where you can color tiles). Worst-case - go solo and draw each your own playtest with your and others approach, then compare it with your partner. \$\endgroup\$ – Kromster says support Monica Oct 23 at 4:29
  • 3
    \$\begingroup\$ TabletopSimulator would allow you to multiplayer this, it has pens you can use to draw on the virtual table. As well as any other components you might need. \$\endgroup\$ – Erik Oct 23 at 5:35
  • \$\begingroup\$ At our company we use Microsoft Lync for collaboration with people at other branch offices. It allows you to do voice and video chat, share your screen, share virtual whiteboards and collaborative text editing. \$\endgroup\$ – Philipp Oct 23 at 11:26
10
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ Comments are not for extended discussion; this conversation has been moved to chat. \$\endgroup\$ – Vaillancourt Oct 24 at 14:41
3
\$\begingroup\$

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?

Voronoi Diagram. 20 random points on a square field are marked, and the regions closest to each point are colored with a random color.

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.
\$\endgroup\$
  • \$\begingroup\$ Thanks for your answer. I'd never heard of a Voronoi diagram. I'll look into it further, but you're right in that the calculations involved may be too much for a global MMO. We have the architecture so efficient now that introducing something like this could be months of work on its own. However, I like the idea, and it may be something to look into down the track... \$\endgroup\$ – Arj Oct 23 at 22:58
  • \$\begingroup\$ Yeah, it is a problem for global calculation, but it's honestly not that big of a leap locally - you likely don't need to consider any more units than what you already would need to manage normal RTS game state. In fact, I presume that the question of "what is the closest unit to (X,Y)", which you would need to answer "which player owns (X,Y)", is already being asked in order to let units auto-select attack targets. When building a building, you only need to answer that question once, for the desired (X,Y) of the building. And when drawing, you answer it once per pixel. \$\endgroup\$ – TheHansinator Oct 24 at 3:07
2
\$\begingroup\$

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.

\$\endgroup\$
  • 1
    \$\begingroup\$ Thanks very much Marcos. Unfortunately, we are nowhere near the stage of being able to release, promote and maintain two different game mechanics on two servers. It's really only viable for us to release one version for pre-alpha to get some feedback (it's basically only me doing all the coding). Also, I do worry that my partner has set a troubling precedent here where he thinks abandoning a game so close to an alpha launch is an acceptable thing to say to his business partner because he doesn't agree with one feature :( \$\endgroup\$ – Arj Oct 22 at 23:50
  • \$\begingroup\$ This is sad. I understand this very well. Maybe should be better to decide who is the lead designer now, or end the partnership before things get worse. \$\endgroup\$ – Marcos Zolnowski Oct 23 at 0:13
  • \$\begingroup\$ Hmm. That's an interesting thought. You may be right. I was always a little bit nervous about sharing design responsibilities (particularly with someone who hasn't done it professionally), just as sharing any responsibilities equally comes with risks in business. I don't think either of us wants to end the partnership as we do work well together overall, it's just this one difference that seems to be such a big issue so late in the day. I guess I'm also worried that if the lead designer were (say) me, he wouldn't have much interest in continuing with the game :( \$\endgroup\$ – Arj Oct 23 at 0:18
  • \$\begingroup\$ If you have one vision for the game, and your partner have another, my solution would help to somewhat have 2 games in 1. Being artists, you both should dream of how the game should be in the end. But if the partner had authority on the graphic/sound assets, and you in the mechanics/programming assets, it could still stay like a 50/50 collaboration. \$\endgroup\$ – Marcos Zolnowski Oct 23 at 1:12
  • 1
    \$\begingroup\$ Actually, I think we have a very shared vision for this game - we have worked together on it for almost 2 years and while we have not always agreed 100% on a particular feature, we always seem to work it out in the end. It seems that it's just this 1 feature where we've reached an impasse. And because we share design 50/50, we need to reach agreement before we can proceed. \$\endgroup\$ – Arj Oct 23 at 1:36
0
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ Wouldn't giving away equity increase the other partner's risk and/or decision power over the project? \$\endgroup\$ – Rodrigo Borges Oct 22 at 21:42
  • \$\begingroup\$ I would think it just depends on how they agree to it. I don't see why someone with less of a share of equity can't have more "written-in" control over the project. \$\endgroup\$ – Steven Sagona Oct 22 at 22:01
  • \$\begingroup\$ Thanks Steven. It's not a bad idea, but I'm personally uncomfortable with re-negotiating our business agreement. There are two main reasons for this: 1) the relationship will start becoming more problematic as one partner will definitely have more control than the other. The lesser partner has less incentive to stay in the partnership if he feels he has less control over the business/game direction, 2) if we can't resolve a dispute to do with "design" (because I feel this is more about design than business), then I am already worried about our relationship going forward :( \$\endgroup\$ – Arj Oct 22 at 23:57
0
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ Welcome, and thanks for your suggestion. Forgive me if you meant something else by "rounds", but this is a true RTS - players have buildings they build in specific addresses, and have actual units they move around the map in real time. There are no "rounds" - everything happens in real time. Maybe if I understood what you meant by "rounds" I could comment further? \$\endgroup\$ – Arj Oct 23 at 8:07
  • \$\begingroup\$ @Arj I meant that map lasts for say a month, then this current game ends and a new one begins (possibly with many server instances running in parallel) - like Travian. In contrast to "persistent MMO" that does not end - for example Ogame. I will try to clarify. \$\endgroup\$ – Zizy Archer Oct 23 at 8:11
  • \$\begingroup\$ Oh right, I see. Our game is persistent - there is no intention of having it end. This may certainly change once the game goes live and we find there is a natural "end point", e.g. there are so many Generals that the game reaches a global stalemate. We are only planning one server at the moment, but if it becomes popular enough then additional servers will basically be "copies" of the first server, with the difference being that the world will be a blank canvas with no claimed territory or user accounts. \$\endgroup\$ – Arj Oct 23 at 8:21
0
\$\begingroup\$

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.

\$\endgroup\$
  • 1
    \$\begingroup\$ Thanks for your answer. Actually, this is my concept exactly :) Where it differs in execution is that the "smaller" squares get "assimilated" into one larger square when you level up. So for example, if you had 25 smaller squares in the shape of a cross, when you level up they are merged into one larger 5x5 square centred on the former 25 smaller squares. It seems that from the feedback to this question, players wouldn't like having their territory "re-shaped" in this way. \$\endgroup\$ – Arj Oct 24 at 22:23
0
\$\begingroup\$

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".

\$\endgroup\$
  • \$\begingroup\$ Thanks for your answer and the link to Ingress - I will check it out. I did want to say something at this point about many of the replies that are suggesting "using existing mechanics" by sticking to a fixed grid/square size. \$\endgroup\$ – Arj Oct 25 at 2:38
  • \$\begingroup\$ I think the RTS genre has stagnated as can be seen by so many articles written about this fact, and the dearth of titles released in the past few years (decades?!). We are taking a big risk here trying to make a game that is: 1) an RTS (problematic already), 2) global (scale issues), and 3) persistent (costs, user numbers etc.). One could successfully argue that we're already taking a big enough risk with these 3 facts - why over-complicate the matter with a different/more complex territory system? \$\endgroup\$ – Arj Oct 25 at 2:38
  • \$\begingroup\$ Well, apart from the many design decisions that I think may have already led us to this point (unique addressing, "starting small" etc.) there is also one personal factor to bring into the mix: I want to innovate and bring something new to the RTS genre. A more complex territory system could maybe kill the game. But I'd like to think that RTS players are "slightly more intelligent" than casual gamers, and this will NOT be a casual game. \$\endgroup\$ – Arj Oct 25 at 2:39
  • \$\begingroup\$ I don't mean any offence to anyone here - it's just that "traditional" RTS games, by their nature, have a higher learning curve. I don't want to take that aspect away from the genre, and whilst we're doing our best to simplify where we can, I feel that this system - if explained well to new players - has the potential to bring something new to the table and possibly "crack" some of the problems already inherent in trying to make a global, real-time strategy MMO. \$\endgroup\$ – Arj Oct 25 at 2:39
  • \$\begingroup\$ If I'm wrong, so be it. Worst case scenario we revert to a fixed size grid. Worst, worst case scenario the game shuts down and we lose 2 years of our lives. I think it's a small price to pay to try to innovate and make RTS games better, grander in scope, and more interesting. \$\endgroup\$ – Arj Oct 25 at 2:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.