Print

[Taschenmogul]

Hi there!

Iīve been looking for some answers to these questions but have found nothing regarding them:

1. How big can an area be? Iīm not talking about the heightmap, Iīm talking about the "logical" extent of an area. I would guess that itīs something like "till you reach the max value in either direction"; is it like that? And if it is, what is this max value, how are coordinates stored? Floatingpoint, it seems to be, but how many bits?

2. Is it necessary for movement to have a groundplane/heightmap somewhere under your feet?
Iīve noticed that even when flying/falling you stop at the edge of the heightmap, in midair.
On the other hand while out of character using the fly mode you can move freely, so I guess it can be scripted so that you donīt need a heightmap for your character to fly around.
Is this correct?

3. Is it possible to seamlessly link areas in 3 dimensions? So that an area is seamlessly linked to other areas on all 6 sides?

The reason Iīm asking this is because we wanna add spaceflight, and even though I have seen and read that at least some of the needed/wanted functionality is there or can be scrippted, abovewritten questions are a little more specific than "can we navigate in three dimensions?".

So, if someone can shed a little light on this, please do!


EDIT PS

No answers as of now, but Iīll add another question nonetheless:

4. Is there any way for characters to interact across the boundaries of seamlessly (2.0) connected areas?
Weīve noticed that characters canīt see each other even when standing in front of each other, if one of them is in another area.
Targeting is also interupted when one character moves into another area.
So, say one character chases another and the former flees across the border to a seamlessly connected area, then the latter both looses target and loses sight of the fleeing character.
In the same way, say one character stands not far away from the border, he couldnīt see a character coming from the other area and could practically be ambushed without a chance to see whatīs coming.

Is there a way to resolve this issue or a reasonable workaround?


PPS: *BUMP* Nobody? Anybody, any tip? Come on people! ;-)

[Stadi_Thompson]

here is some area size info,
http://hewiki.heroengine.com/wiki/Area_Server

[JoshHalls]

You can seemlessly link across x/y/z coords, I haven't tried it outside the extent of heightmaps though (in theory it shouldn't be a problem though).

As far as size, that is a good question (as far as if the engine has any hard limits), but zone size typically has more to do with processing, crowding, and memory usage than with hard limits.

As with not seeing people, I thought it worked in clean engine as we had to add something to make sure the proxy information was getting back/forth, but perhaps it is not working even in clean engine.  I guess HE team can comment on that better.

[Taschenmogul]

@info360covers: Thanks for the link, but if I havenīt overlooked something, the wikipage doesnīt offer any real answer to my question.

The wiki article practically just reminds people of keeping the amount of content in mind when defining areas.
And thatīs somehow trivial - if you put one billion polygons worth of geometry in your area plus a gigabyte of textures, your game will likely be not very playable, with your PC probably going to hang and crash.

Now with open space this is a little different as geometry-density will be very low there.
You could travel thousand kilometers without encountering a single asteroid, let alone another spaceship.
So this "most people use areas of 500mē to 1000mē" is not very applicable in this case.

@joshhalls: Hm, Iīve tried it out but when I make a link and take the linked terrain and move it upwards, at some point it just vanishes and canīt be seen anymore.
I guess area content is cut off when exceeding a certain Y position.

About the interaction across seamless borders, I would also think that there is a solution to that.
I could imagine the server running a master coordinates table that tracks characters across areas; this way you should at least be able to show other players (or AI creatures) on radar, even if they are within another area.
As to directly seeing them Iīm confused; normally those seamless links are there because you should not see (and thus load) all contents of the other area, else splitting the gameworld up into areas wouldnīt make much sense.
So I hope there is a reasonable workaround that, say, lets a character see other characters in a certain radius.


PS: Perhaps I can put it a bit more precise.
When adding an area to another area via a seamless link, both areas are shown within the confines of the coordinate space - you can see them simultaneously in your viewport.
Now the question is - how big is this coordinate space?
At which point will your maximum coordinate value be reached and you will bump off the "border" of space, and can these confines be changed?
Can I e.g. change an area to only be 1km x 1km x 1km big, thus limiting itīs extents so that it wouldnīt be possible to add, say, a heightmap bigger than 1x1 km?

[FI-ScottZ]

Floatingpoint, it seems to be, but how many bits?

I believe that is part of what you need to take into consideration for area size as well.

This page on Reference Frame Adjustment talks about how every area has its own origin (0,0,0).  It's recommended to begin an area around the origin and building outwards, since the farther you get from the origin, the more that the limited precision of floats can lead to artifacts as the location and motion of things become less precise.

Where that might happen exactly is tough to say; there are a lot of variables involved.  You may have to experiment and see how big your areas can be without problems.

I haven't worked with seamless a whole lot, but maybe the re-homing could have to do with tracking players across areas?

[JoshHalls]

I think I forgot to post my edit.  I am not sure how much testing has been done with linking across the y axis (something is above/below).  You also then have to remember you now have a much larger linked area to manage.  With just normal x/z axis you will have 8 neighbors if every neighbor is connected.  Adding the y direction you are just adding a lot links and a lot more zones and complication to the mix.  I guess my question is do you really need it?  We have space flight as an after release feature so I haven't had much time to mix around zones without heightmaps, but you might be better looking at your links from the x/z axis and putting an artificial limit on how high/low you can go in the areas.  It does take away the free roaming ability to start moving up/down the y axis like you do the x/z axis, but it might be better from a design aspect in the long run.

[Taschenmogul]

@ScottZarnke: Thanks, Iīll look into the Reference Frame Adjustment a bit more, though I havenīt seen anything directly related to my topic yet.

@joshhalls:

Thatīs why I PSed my last post here.
Itīs no problem in general to alter the Y-position of an area when linking it, apart from it disappearing at some point, that is.
The question is, more generally put, how to manage area transitions in open space when you havenīt got a groundplane as a reference.
As I understand it, according to my testing, you donīt have an absolute confinement of space for areas (e.g. I have not yet seen a possibility to state "Area01 is a box of 400^3 meters"), instead those areas are generally defined by their geometry, that is in most cases a groundplane/heightmap.
For to enter a linked area I have to move into this space that is confined by e.g. itīs heightmap; and when flying in cameramode it is possible to fly around this area, not entering it.

So if flying like in cameramode would be enabled for players, there should be a way to limit the playerīs movement as to make it impossible to fly around the entrypoint to the next area.
It would also be nice to be able to confine an area directly by a numeric input (like the 400^3 meters) and to be able to state that once you have reached the areas limit at e.g. Y-position 400, you enter the next area.
Though Iīm pretty sure this can be achieved via scripts (by e.g. saying "If characterposition on Y-axis in Area01 >= 400 Then move character to Area02") or perhaps via a trigger ("If Trigger01 is triggered, teleport to Area02"), it would be nice to have this done without excessive coding; and especially without losing the inbuilt management tools for arealinks.

PS: And, sure, enabling area-navigation in all three dimensions would increase the number of connected areas to the power of three, not the power of two.
We will definitely have to think about that when we know what will be possible in general.
You would not necessarily have to use this option all the time though - you could e.g. have 90% areas that are connected only in two dimensions (or even just in one) plus 10% areas that offer three-dimensional linking.
As of now we are still assessing possibilities though, so itīs (obviously) not yet decided how we will do it in the end.

[HE-JAY]

As Cooper notes, the illusion of vast, open spaces is often far more effective (and efficient) then explicitly mapping out thousand-kilometer swaths of space.  I can understand the desire to satisfy personal curiosity about the limits of an engine in order to better understand what it can do and how it operates, but the more appropriate question to ask is "What exactly am I trying to achieve, and how can I get there as convincingly and inexpensively as possible?"  Many games employ tricks designed to convey the illusion of vastness: modifying movement speed relative to perceived distance, or using fast travel (warp, for example) to visually transition between two bridged areas.  In the end, your choice of implementation will be guided not by some arbitrary upper limit, but by an intelligent assessment of what you can expect to accomplish with the resources available.

As to your other questions:

• The default character controller uses physics to sweep the area directly under the player to determine whether the character is currently located above collide-able geometry each frame.  If this test fails, the controller interprets this as a 'collision' and refuses to allow the character to move any further.  This behavior is completely customizable and there is no constraint on the character (whether it be a biped, a ship or an amoeba) as far as position or orientation goes.
• Currently, seamless travel is not set up to handle three-dimensional seamlessness automatically. While it's true that seamlessly connected areas may have arbitrary spatial correlations (they can be on top of, next to, or within another spatial area), triggering the transition is currently done 'under the hood' and is related to physics. There are ways to get around this, but true three-dimensional seamless transitions aren't currently supported 'out-of-the-box without any additional tweaking on your part.'
• Characters most certainly can and do interact across seamless 2.0 boundaries. The HSL code must take advantage of language features designed to work with seamless 2.0 (such as proxylocal and proxyforward methods), but this is fully supported.  Hero's Journey (and to a lesser extent the mock fantasy template that is delivered to HeroCloud customers) - while an excellent reference to get the general feel for how to implement certain features - should not be considered an authoritative source for optimal design or implementation. In the case of Hero's Journey, all of that code was created before seamless 2.0 was even added and will thus not showcase these features.
• Camera control is completely customizable and may be restricted, modified, sliced, diced and whipped to your taste. With some manipulation, you can create many useful illusions regarding rate of travel and creating soft barriers, and you can indeed create triggers that will respond to their presence or absence.

Thanks,
-Jay

[Taschenmogul]

@HE-Cooper & -Jay:

Thank you both, thatīs some info to consider!

And sure, as said weīre still just assessing possibilities, we donīt know yet how we will solve these issues in the end.
And I do believe you that it would be hard to implement spaceflight without some form of illusion or workaround.

So, as Iīve understood you both, movement without a groundplane is no problem; but after some hours of reading and trying, I still got no real clue how to link together areas without geometry.
When linking such areas, the area linked to is not visible (as it has no geometry in it) and doesnīt even show a boundingbox (or Iīve made some stupid simple mistake).
I guess in this case you would have to input the wanted coordinates/position/orientation numerically, but I have not yet found a way to do that with Seamless 2.0 links; only found something about that (if Iīve understood the text correctly, that is) in the Reference Frame Adjustment article, but that only seems to be applicable to Seamless 1.0 links.

So how do I change the position and the extent of an area that is linked via Seamless 2.0?

[jcsmith562]

Could you use a large box and then mark it as Hidden and have it ignore collision?

[HE-JAY]

jcsmith's suggestion is probably the best under the circumstances. The current editing tools are very geometry-centric in that editing offsets and making connections is done with the geometry as a reference point. With no geometry, editing the area offset would need to be done via script. This is simple enough to accomplish and could be automated to create reference objects at the origin and then link areas to one-another with a predefined offset.

[Taschenmogul]

Thanks for the suggestion, though Iīve already tried something similar.
Will try it again then, perhaps I get it working; problem had been that geometry vanished when scaling up the object (in my case a simple plane asset) or when using a big object in the beginning.
But it will probably suffice when all I need is some orientation for linking the area.

[Ashtefere]

If you are doing a space based sim (saw it mentioned) perhaps you should be thinking about "simulated distance" as a techique for creating large areas of space.

Its a system my team will use when we get around to our space mmo (the next project after our current one) and I will try describe the system lightly.

Essentially, instead of having a giant great big game area filled mostly with space, you have "hotspots".

1: Each hotspot is a focal point, e.g. a planet, moon, space station, emplacement, etc - you get the idea.

2: Each hotspot is normal or small sized, with manual seamless transitions based on the direction of exit from the "hotspot" - this is done via scripting.

3: Upon exit the hotspot, an instance is loaded of pre-made empty space with a custom skybox based on the area the player should be in.

The Empty space area:

1: Has a predefined size that has standard seamless transitions, but to another (same area but different instance) empty space instance.

2: On leaving an empty space instance, it is destroyed.

3: Each empty space instance gets a 3d co-ordinates reference in a "virtual" space, like a gigantic rubix cube. A good system to use would be STARNAME-101-32-18 or similar.

Now, to combine this with multiplayer:

1: If a player leaves a hotspot, and enters an instance in the virtual space that is already occupied, instead of building a new instance, an existing instance is entered.

Using scripted placement, distance objects can be created at smaller size in rough direction of where they would be if the space was enoooormous.


For a star system that has 8 planets and 20 moons, the amount of areas required would simply be 29 - 8 planet hotspots, 20 moon hotspots, and a single "empty space" re-usable instance base.

All of the hotspots can also be relatively small as well, thus being more resource friendly.

Another tip is to scale down your player objects to give a sense of more size.


The end result is a highly efficient, very fast, very small universe that ends up appearing to be ridiculously large.

We have only done preliminary experimentation with this proposed system, and the above outlines are working from my memory, but from what I have learned in my short time with hero engine this should definately be doable.

Its just script heavy as opposed to area build heavy

-Jon

[Taschenmogul]

@Jonathan: Well thanks for your input! This is pretty much what we have come up with, only that we are not yet sure how to do that within HE.

Especially what you said about scripting is what bothers me - I already wrote that it would most probably be possible to achieve seamless transitions between areas of empty space via scripting, but that would take away ease of use, especially it would take away intuitive insight.

A special case would be giant objects like e.g. moons that you would want to feel like they really were huge.
Now I know that most (if not all) spacesims accordingly donīt depict moons and planets as being even just remotely as big as they would have to be; but even if we visually shrank the respective celestial body to about one thousandth of itīs normal size we would often have to deal with dozens of areas for one such body.