## Zones

Post

### Re: Zones

#31
McDuff wrote:Yup. Dissimilar metaballs would just flatten when they met. No grids needed.
i still say that they should just merge, as when one of them is considerably stronger he owns the space nonetheless, with flattening or without.
and if they have similar strenghts they just merge into an "neutral" or "contested" zone.
no special cases needed IMO

(the area for "contested" should be between about 40% ownership of the zone to 60%, so below 40% percent the other has the control, above 60% you and inbetween its "not decided")
Post

### Re: Zones

#32
Personally I like the idea that each object emits its own zone, and intersecting zones get merged in a larger zone.
This would mean that a zone containing 200 asteroids would be larger than the zones of the 200 separate asteroids.

The reason I think this would be nice to have, is so you can expand zones by creating structures in them. Suppose you find an asteroid field, you can then place a station next to it, and have a bigger zone in all directions.
Assign this station and its docked fighters to protect this zone, and they'll undock automatically and attack any unauthorized ship entering the zone (if detected by sensors).
The zone would be like a sphere of influence (but not a sphere) that can be treated as a single strategic point.
Beware of he who would deny you access to information, for in his heart he dreams himself your master.
Post

### Re: Zones

#34
McDuff wrote:Why is a border a "special case"?
if you mean me: not borders are a special case, squishy metaballs are a special case, because you cant just go with some distance fields that you just add on each other to generate them.
but some more fancy functions to actually squish them
Post

### Re: Zones

#35
Sasha wrote:The problem I see with dividing space into a grid is that it defeats the purpose of having zones around points of interest.

If space is going to be divided into a grid, all of space must be divided into a grid. Otherwise you just have isolated cubes around points of interest instead of spheres. (Spheres are easier to implement)
The grid-structure of space extends everywhere in a system, but it's only visible (in the appropriate visualisation mode) around places where ownership has been established - the grid tapers off into transparency a little beyond territorial borders. In addition, the coordinate space of grids is set relative to the position of the point of interest.
Sasha wrote:I also think dividing space into a 3D grid would look a bit messy. Too many lines (personal opinion)

I also think that if space was divided into a 3D grid, in a heavily contested system you'd see a whole bunch of differently coloured semi transparent cubes stacked around each other. IMO, Isolated spheres would look better
Possibly. There's something quite similar to this that Josh has already implemented and used in other areas of Limit Theory (the command interface) . You see this at 10:19 onwards in Development Update Video 8, and to me the grid-like structure looks really pretty. Granted, however, that he's showing a 2D grid and not a 3D one. However, I don't think that that my implementation would look very much different from the other implementations with pure spheres and metaballs; it'd really only just look more voxelly.

As regards two territories meeting, the following two things would naturally follow from a grid-based implementation:
• Metaball-like merging - if two territories owned by the same entity meet, then all the sectors inside the union of those two territories would be under your ownership, and this would look very much like a voxel-like merging of two metaballs.
• Contested space - if two territories owned by different entities meet, then a boundary of contested space would naturally form between them.
Cornflakes_91 wrote:i assume zones spherical and continous because of joshs notion that they are intended for AI usage.

The AI does not need "cube 132.548.32 with 436 points of czerka corporation ownership"
The coordinates are for the benefit of the player as well as the AI. Bear in mind that the AI should be treated in the same way to the player, so that whatever precision of data is available to the player should also be for the AI. If with the metaball scheme the player is only told "There is unlawful activity occurring near to station 5", that is all the AI is told as well. With the grid-based scheme, the system could tell you "There is unlawful activity occurring in sector 56.42.10 around station 5", and the same information would be given to NPCs.
Post

### Re: Zones

#36
ThymineC wrote: The coordinates are for the benefit of the player as well as the AI. Bear in mind that the AI should be treated in the same way to the player, so that whatever precision of data is available to the player should also be for the AI. If with the metaball scheme the player is only told "There is unlawful activity occurring near to station 5", that is all the AI is told as well. With the grid-based scheme, the system could tell you "There is unlawful activity occurring in sector 56.42.10 around station 5", and the same information would be given to NPCs.
you simply dont NEED the information, a simple marker on the map would be suffecient.
noone would care about the coordinate numbers, one would see "trouble around station 5" switch there and look for the blinking red light in the zone.

coordinates would have some sense when single zones would become so large that they'd fill significant volume in the system, or something happens in non-zoned space.
but still, no one would care for the actual numbers game but only for the blinking red marker on the map

in unzoned space it could just be just a message "task group nr2 in uxednumnodje is under attack" with some hotlink like clickable that brings you to the map, already focused on the task force
Post

### Re: Zones

#37
Cornflakes_91 wrote:you simply dont NEED the information, a simple marker on the map would be suffecient.
noone would care about the coordinate numbers, one would see "trouble around station 5" switch there and look for the blinking red light in the zone.
Well, the coordinates would give you an immediate rough idea of where in the territory the event is happening. If my territory had a radius of 50 sectors, and I knew where sectors 50.0.0, 0.50.0 and 0.0.50 are, and I was told something was happening in sector 40.22.10, then I'd get a rough idea of where that was straight off of the bat. It's a small point either way, because then I'd probably turn to the map and its blinking dot to get a better idea of where this was happening whichever implementation were used.
Cornflakes_91 wrote:in unzoned space it could just be just a message "task group nr2 in uxednumnodje is under attack" with some hotlink like clickable that brings you to the map, already focused on the task force
Hm, good point. If it helped me pin events down faster, I'd like if there were "mega-sectors" - bigger versions of sectors, maybe 100 times or 1000 times as large - and then, the system could report something like "Ship 10 is under attack in mega-sector 7.12.10". It may be that Josh's map already displays information well enough that this isn't necessary, however.
Post

### Re: Zones

#38
Yikes. Cubes, coordinates, spheres. I think this all might be a bit aside the point.

Unless I'm misreading the devlog tremendously, a big bonus of the zone concept as described is a zone is conceptual, not spatial. This is how people (mostly) think. You look at a map and say "Ah yes, I need to get to that mountain over there!", not "Ah yes, I need to get to coordinate (34.74, 04.23)!" This is especially useful for space, and particularly space where we have rapid-transit lanes. The vast majority of space is empty, and so uninteresting, and the effective distance between two zones is not how far apart they are, but how long it takes to get from one to the other.

For the most part, conceptual zones are just so much more useful that spatial zones. It's desirable for the AI to be thinking about conceptual zones, because that's how players (mostly) will be thinking about space.

It's not my intention to try and dismiss a bunch of perfectly good reasoning, but IMHO it seems like the discussion's gone a bit far afield.
Post

### Re: Zones

#39
Revoke wrote:Unless I'm misreading the devlog tremendously, a big bonus of the zone concept as described is a zone is conceptual, not spatial. This is how people (mostly) think. You look at a map and say "Ah yes, I need to get to that mountain over there!", not "Ah yes, I need to get to coordinate (34.74, 04.23)!" This is especially useful for space, and particularly space where we have rapid-transit lanes. The vast majority of space is empty, and so uninteresting, and the effective distance between two zones is not how far apart they are, but how long it takes to get from one to the other.
OK... but then aren't you really describing points, rather than volumes?

In which case, why have zones at all? If we're just talking points of interest, how do you designate which faction has control over a region of space (which is, I think, what "zones" are meant to support) and thus whose rules apply there if enforced?

It's perfectly true that sometimes when I look at a map, I might think, "hey, that point of interest looks intriguing." And I have no objection to being able to do something like that using maps in Limit Theory; it's not a bad idea at all.

But sometimes I might benefit from being able to look at a map and think, "hey, this says I'm near the boundary of a country who like to put tourists in jail as 'spies' -- maybe I'd better not cross into that zone."
Post

### Re: Zones

#40
I'm not really talking in spatial terms at all. That is, zones have some spatial data associated with them, but what type of data that is can vary, and it's detrimental to the concept to describe locations in terms of a cube, or point, or whatever. It doesn't make sense to a 'a zone is a sphere' or 'a zone is a cube' or even 'a zone is a point of interest', because the definition of a zone doesn't include specifics about its spatial data. This is important, because you need different kinds of spatial data to describe an asteroid field, a planet, and a station.

I guess what I mean is - a zone can be any arbitrary region of space, and that's what makes it such a powerful idea to work with. It means they can describe any kind of geographical (astrographical?) features you might care about.
Post

### Re: Zones

#41
revoke wrote:[stuff]
Thats is the reason why i stick so fiercingly to spherical arrangement and metaball merging.
it adheres closely to "in the area of" thinking.

If a single object is alone the feeling of "in the area of object xy" can be approximated as a sphere (when we assume the object being spherical or a point)

For multiple objects it behaves as with merging spheres or metaballs, when they get close enough together you dont think of "area around a" and "area around b" as different areas, but as a single area encompassing both a and b.

analogous with nested zones.
you know that a, b and c are stores which are in a shopping center. You want to go to b
So a and b are both in the area "shopping center".
You may not remember exactly where b is, but you know it was close to a, so you go in the area " around a" and search for b there.
Post

### Re: Zones

#42
The exact method you use of defining the geometry is kind of irrelevant to the zone concept though. As long as your implementation can define sufficiently arbitrary geometries - it's good enough. Whatever's used under the hood is...well, under the hood, and that's the point. No one who has to think about zones (both the player, and the AI) needs to worry about that.
Post

### Re: Zones

#43
Revoke wrote:The exact method you use of defining the geometry is kind of irrelevant to the zone concept though. As long as your implementation can define sufficiently arbitrary geometries - it's good enough. Whatever's used under the hood is...well, under the hood, and that's the point. No one who has to think about zones (both the player, and the AI) needs to worry about that.
I provide sufficiently arbitary geometries and my generation sheme for them is so simple that one can precisely define what he has to do to shape the zone to suit his needs.
Post

### Re: Zones

#44
Id also suggest that sub-zones can have different contestion/ownership states as their super-zones.

For example: two station groups in an asteroid field that are separated by an great distance but are still both definitely inside the asteroid field.

in each station group are two factions present.
At first faction a has ownership of both sub-zones and owns also the asteroid field because it has the most ownership points in the asteroid field zone.

Faction b starts to expand its assets in one of the station groups, now the sub-zone of this station group is contested because a and b are at approximately the same strenght in the zone.
But in the other station group faction a is still superior and has the most points in both the sub-zone and the asteroid field super-zone.

B expands further and gets on top of a in the station group and the ownership of the station group sub-zone switches to b. But b is still inferior to a in terms of super-zone ownership points, so they now have a sub-zone inside a's super-zone, but a's control over the super-zone as whole has not faltered.

This nesting sheme can be applied to everything.
So that this asteroid field zone is only a sub-zone of the bigger system super-zone which can be controlled by even another faction.

This enables conquering systems/asteroid fields/station groups piecewise with changing ownership of single areas without the whole system becoming contested.
It could even be upscaled to using systems as sub-zones of bigger multi-system zones enabling bigger and bigger meta-gaming
Post

### Re: Zones

#45
Cornflakes_91 wrote:
Revoke wrote:The exact method you use of defining the geometry is kind of irrelevant to the zone concept though. As long as your implementation can define sufficiently arbitrary geometries - it's good enough. Whatever's used under the hood is...well, under the hood, and that's the point. No one who has to think about zones (both the player, and the AI) needs to worry about that.
I provide sufficiently arbitary geometries and my generation sheme for them is so simple that one can precisely define what he has to do to shape the zone to suit his needs.
With sectors, you could get even more arbitrary geometries, since you could not only get voxel-shaped spheres, but also cubes, cuboids, tetrahedrons, octahedrons...anything, really, just like in Minecraft. With the pure meta-ball approach, you couldn't do this; everything would be spherical, and it's harder to approximate (for instance) a cubic shape using spheres.

Not that it necessarily matters - I think ownership is best represented with a spherical pattern.

Another reason I like sectors is that I think of them as the volumetric equivalent of nodes, which is a strong theme in Limit Theory.

While an isolated sphere representing a territory might be very easy for AI to reason about - "everything within x units of this point belongs to me", it becomes more complicated for the AI to reason about territory when you start getting merging and squishing pure metaballs, as I think Flatfingers mentioned earlier. However, something analogous to this merging and squishing would already happen with sectors, and it would be much easier for AI to reason about their territories using a sector-based approach; all they have to do is keep all of the sectors that belong to them in a list (edit: or as I am obnoxiously going to call it from now on, a "sector vector"):

Code: Select all

``````vector<Sector*> controlledSectors;
``````
Finally, geometry is important because a sector-based approach makes it easy to lease standardised volumes of space to other agents, like in real life. So the underlying geometry is really a pretty relevant thing to consider, Revoke.
Last edited by ThymineC on Thu Mar 20, 2014 4:50 pm, edited 1 time in total.

### Online Now

Users browsing this forum: No registered users and 0 guests