Return to “General”

Post

Re: Zones

#46
ThymineC wrote: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.
"Like in real life" is not a strong argument for me, since not everything from our reality is necessarily a good fit for LT or any other imagined world.

That said, I agree with this generally. There's nothing wrong with thinking of describing space conceptually, but as an actual working piece of software Limit Theory has to have some kind of implementation for "who owns [this piece of] space."

I think breaking up space into equal-sized chunks and tagging some of them with different-strength ownership IDs is a viable approach, but whatever is both effective and efficient in meeting Josh's gameplay design criteria will work for me.
Post

Re: Zones

#47
Flatfingers wrote:
ThymineC wrote: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.
"Like in real life" is not a strong argument for me, since not everything from our reality is necessarily a good fit for LT or any other imagined world.
That's true, but if my proposed system is analogous to a real-world system, then it helps improve confidence that the system is at least internally consistent i.e. works given the assumptions it's making (that corporations in Limit Theory will demand licenses to operate in given volumes of space for mining/production purposes in a sufficiently similar manner to corporations in real life).
Post

Re: Zones

#48
ThymineC wrote:if my proposed system is analogous to a real-world system, then it helps improve confidence that the system is at least internally consistent i.e. works given the assumptions it's making
What you're saying is not wrong, exactly, but I believe the right context is larger.

Yes, implementing some object or process in some apparently realistic way helps some players understand how to play with that object or process. Seeing something recognizable from our world sets expectations in the imagined world.

But that cuts both ways. OK, now you've modeled X in some apparently realistic way... well, why didn't you also simulate Y to an equal level of real-world fidelity? What about Z? Or Q? Or C(3)a?

The point is that once you accept "should be like the real world" as a guiding principle for parts of a made-up secondary reality, you have no grounds to object when someone demands that some other part(s) of the game be based on real-world stuff as well.

And then your game is doomed to be considered a failure, and on two counts:

1. No matter how many things in your game are modeled from the real world, you will never get them all. You will always have missed the One Thing your game "really needed to be fun."

2. No matter how accurately you model any object or process from the real world in the wholly imaginary world of your game, it will never be sufficiently accurate for some people. Like Patsy said, "it's only a model." By agreeing that trying to model some part of reality is a correct goal, you set yourself up for failure because it's impossible to fully model any real thing in a computer program.

Between these two effects, I do not recommend ever, even once, accepting the claim that anything in a game world is automatically right or better just because the developer tried to make it look or work like it does in the real world. Even for games that have a realistic setting, they're still games -- and that means the correct measure for any feature is not "is it realistic?" but "is it fun?"

Certainly there are some applications where more realistic = more fun. But "more fun" is still the top-level goal, "more realistic" is just the means by which those very specialized games achieve that goal.

The real test for any game feature has to be, "Does this feature, interacting with all the other features, fit the aesthetics and dynamics and mechanics and kinesthetics of this unique invented world that I am creating?" If it does, then it may be worth implementing; if not, then it undercuts the logical and emotional coherence of that new world and should be excluded regardless of whether what's left is how things would work in our real world or not.

As I said to CutterJohn, there's nothing wrong with looking to the real world for inspiration about features for the game world. What I'm saying is that I think there are strong game design reasons why realism should never be the ultimate test for the features that go into the imagined world of a computer game.

If you're just saying your geometry system was inspired by a real-world system, and not that basing your geometry suggestion on a real-world system automatically makes it better for LT than some other system, then my apologies for wasting your time with all this. ;)
Post

Re: Zones

#49
Flatfingers wrote:[...]
If you're just saying your geometry system was inspired by a real-world system, and not that basing your geometry suggestion on a real-world system automatically makes it better for LT than some other system, then my apologies for wasting your time with all this. ;)
I wasn't really saying either. I came up with the idea, discussed it in IRC, and then mcsven informed me that a real-world system works similarly to it. That didn't make me think the idea was "better", it just meant made me think "well, it's likely to be internally consistent at least". But the fact that it's used in the real world doesn't really mean I like the mechanics any better or worse than otherwise.
Post

Re: Zones

#50
ThymineC wrote:the fact that it's used in the real world doesn't really mean I like the mechanics any better or worse than otherwise.
In that case, I have no complaint, and I thank you for letting me exercise my typing skills. :D
Post

Re: Zones

#51
ThymineC wrote: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.
Mmm, still gonna have to disagree. When I say 'the geometry is unimportant' I guess what I really meant was that the underlying implementation of the geometry is unimportant, with respect to gameplay. The player should only ever have to deal with zones (that asteroid field, this station, that planet, this system, etc). If you ask the player to deal with raw geometry at any point - cubes, spheres, coordinates, whatever - I feel that's a game design failure.

This doesn't mean zones have to be super-simple. They can still be hierarchical, for instance. The game might be calibrated to split up asteroid fields and gas clouds of a certain size up into smaller chunks. But they should be split up in a manner appropriate to the field in question (eg, splitting it clean in half), not split up by a grid aligned to an arbitrary axis. There also no compelling reason I can see to divide up vast swathes of empty space.

As an aside, I do realize that the geometry implementation is important from a software development perspective, for reasons of efficiency etc. But those low level details have nothing to do with how the player (and importantly, the ai) interact with zones.
Post

Re: Zones

#52
As I read Josh's notes about platemesh yesterday, I actually think we seem to be moving away from any kind of "grid" (if LT ever had one) and more into defining things purely based on relationships to each other.

And the more I think about it, the more I like that.
Post

Re: Zones

#53
McDuff wrote:As I read Josh's notes about platemesh yesterday, I actually think we seem to be moving away from any kind of "grid" (if LT ever had one) and more into defining things purely based on relationships to each other.
Oh yeah, you're quite possibly right about that. Harder for me to conceptualise how that would play out, though.
Post

Re: Zones

#55
McDuff wrote:I have a notion of how I think it might look. Not sure exactly how to describe it in words. Something involving ping pong balls, jelly, and rubber bands, probably.
Ping pong balls are nodes, rubber bands are edges, jelly...because who doesn't like jelly?

Edit: And by edges, I mean the connection between nodes (viewed as actual nodes in a graph). Not ship edges.
Last edited by ThymineC on Fri Mar 21, 2014 7:03 am, edited 1 time in total.
Post

Re: Zones

#56
Rubber bands are connections between nodes.

Jelly is for filling in gaps, i.e. should you be building a ship out of various bits of platemesh and needed to make sure it didn't have any holes in it.

Or for covering ping pong balls in so they can get bigger, smaller, or funny-shaped.
Post

Re: Zones

#57
I've been thinking a little more about jelly -- sorry, I mean zones -- and in particular about how zones let you understand and interact with the structure of space.

What if the "zone" concept followed these rules:
  • Zones are spherical, with a central point of interest and a radius of effect.
  • Zones have owners (the owner of the central point of interest) with a default of "None".
  • Zones have types (asteroid zone, station zone, political, etc.).
  • Zones of different types can overlap.
  • Zones of the same type with the same owner can overlap.
  • Zones of the same type, but different owners, cannot overlap.
I'm thinking this formulation has some interesting consequences:

1. It allows space to have more texture than a "one point in space can only ever belong to one zone" rule permits.

An asteroid, for example, might simultaneously be part of -- and affected by the rules of -- an asteroid zone, an ice resources zone, a space station mining zone (if a mining station is built in an asteroid field), a piracy zone (from a nearby pirate base), a Planet Qorg political zone, and a System XQR-1744 identification zone.

Engaging with an object thus means potentially triggering gameplay effects associated with each type of zone covering that object. Harvest that ice asteroid and maybe that notifies the nearby mining station of your claim, annoys the local pirates (who think they own those rocks), communicates economic activity to the Qorg government (who actually do own those rocks), tells the ice asteroid zone to regenerate some new asteroids, and so on.

2. Through the intersection of similar zones, it allows zones to combine to have non-spherical extents (not unlike the "fusion" moment of meta-ball merging). A faction that expands its mining operations in multiple little zones can eventually, when those same-type, same-owner zones overlap, be treated as having one large, organically-shaped zone.

3. Being able to select zone types in the node map display allows you to understand space in specialized ways.

For example, you could bring up the node map for a system and tell it to display zone info, select "economic" zones to find good places nearby to sell ore, then select "political" zones to overlay areas of civilization where prices might be higher for certain goods than, say, a station off in space by itself. You could also do this with non-overlapping zones, but there'd be less value in selecting multiple types of zones and overlaying them.

Something like this may already have been proposed, in which case thanks for letting me add support to it. Otherwise, I'm interested in reactions to this revision to what Josh has described (no overlap).
Post

Re: Zones

#59
Flatfingers wrote:[...]
Agree with all of this, it's what I was hoping/expecting for anyway. I'm not 100% confident Josh meant when he said zones can't overlap. I hope that this doesn't apply to zones of different types, so we can get something like this.
Post

Re: Zones

#60
Flatfingers wrote:
Spoiler:      SHOW
I've been thinking a little more about jelly -- sorry, I mean zones -- and in particular about how zones let you understand and interact with the structure of space.

What if the "zone" concept followed these rules:
  • Zones are spherical, with a central point of interest and a radius of effect.
  • Zones have owners (the owner of the central point of interest) with a default of "None".
  • Zones have types (asteroid zone, station zone, political, etc.).
  • Zones of different types can overlap.
  • Zones of the same type with the same owner can overlap.
  • Zones of the same type, but different owners, cannot overlap.
I'm thinking this formulation has some interesting consequences:

1. It allows space to have more texture than a "one point in space can only ever belong to one zone" rule permits.

An asteroid, for example, might simultaneously be part of -- and affected by the rules of -- an asteroid zone, an ice resources zone, a space station mining zone (if a mining station is built in an asteroid field), a piracy zone (from a nearby pirate base), a Planet Qorg political zone, and a System XQR-1744 identification zone.

Engaging with an object thus means potentially triggering gameplay effects associated with each type of zone covering that object. Harvest that ice asteroid and maybe that notifies the nearby mining station of your claim, annoys the local pirates (who think they own those rocks), communicates economic activity to the Qorg government (who actually do own those rocks), tells the ice asteroid zone to regenerate some new asteroids, and so on.

2. Through the intersection of similar zones, it allows zones to combine to have non-spherical extents (not unlike the "fusion" moment of meta-ball merging). A faction that expands its mining operations in multiple little zones can eventually, when those same-type, same-owner zones overlap, be treated as having one large, organically-shaped zone.

3. Being able to select zone types in the node map display allows you to understand space in specialized ways.

For example, you could bring up the node map for a system and tell it to display zone info, select "economic" zones to find good places nearby to sell ore, then select "political" zones to overlay areas of civilization where prices might be higher for certain goods than, say, a station off in space by itself. You could also do this with non-overlapping zones, but there'd be less value in selecting multiple types of zones and overlaying them.

Something like this may already have been proposed, in which case thanks for letting me add support to it. Otherwise, I'm interested in reactions to this revision to what Josh has described (no overlap).
i agree with the most of this EXCEPT for the "similar zones with different owners dont merge" part, as i dont see how we could ever get superiority in a zone if we displace it somewhere else when we build a concurrent building next to it.
basically negating everything what i suggested about ownership and ownership changes. which, as i read out of the devlog, is something josh wants to include

Online Now

Users browsing this forum: No registered users and 20 guests

cron