Print

[JoshHalls]

Zone size is arbitrary to the point where you have to look at how many players are in a certain amount of space and what they are doing in it  The suggestion they put out is to have as many distributed processing areas as possible to support a high density of players.  If you are going to have a ton of players in a 250m area then you probably want a 250m area, but if you are going to have 5 players in a 4+km area then you mostly have to worry about memory limits on the client with that much terrain and then props.  Using half/quarter resolution helps in that area at least as it greatly reduces the density.  Honestly, we are using half density so far and find it is more than enough and there isn't a lot of difference in visual quality once it is "fully dressed" and there is a lower memory footprint and it loads faster so plus/plus. 

[Amanda_Brooks]

Reading this thread has brought up a potential problem for our project that we've started work on - it's a comic book based game, set in a large city, and one of the requirements for it will be the ability to fly to any point in the city - so what kind of area size would we be looking at as the maximum we could create that would allow for seamless flight?

[Stadi_Thompson]

Depends how far you want your view distance vs the fog density, no game has an infinite view distance. Remember when you enter another area, it's neighbor will load, revealing another slab of new land. Good Luck.

[Amanda_Brooks]

The view distance would need to be quite long - but our main concern is seamless flight across the city - and this part of the HE wiki isn't so reassuring:

Naturally if you would like to have flying mounts, or something of this nature, the junction requirement can be a tad restrictive. Where as with land-based travel it is easy to block movement with walls, buildings, mountains and such, a flying creature can just bypass all of that. So the question is, how could you handle this in HeroEngine:
 
One way is to have flying having altitude limitations. Therefore you can create large mountain ranges that block travel (and sight-lines) between areas. Then create mount pass (or gaping caves, or other interesting means) to serve as junctions between areas. This is the most straight-forward approach. It works especially well if flight is not free-form (in other words, it is on a rail). If it is free-form, it will still work but you have to be more careful with your level design.
 
Depending on the limitations you are willing to accept, you can do this sort of game play today.

Free-form flight is pretty much a fundamental gameplay requirement for a comic book game.

[HE-Cooper]

None of those concerns would be specific to an HE related concern. The engine doesn't care whether you are touching a heightmap when you cross a seamless border. Heightmaps are arbitrary assets in an area of server simulation.

Have you talked to an engineer on your team about what your concern is with free flight and seamless areas?

[Amanda_Brooks]

The engineers are currently usign the wiki to read up on the HE - they were the ones who brought this to my attention.

Our ealry design work suggests we'll need an area roughly 9x9 miles (14.5x14.5 km) or slightly smaller to fit in all the planned districts of the city - this means that if we use 500mx500m seamless area sections we would require about 200 of them to cover the whole area of the city, and we're concerned about just how seamless that woudla ctually be for players using a flight power to travel around the city.

[HE-Cooper]

As with any game design, you'll have to balance simulation and client to server communication, how you implement your game systems, etc. We tell world builders not to use areas larger than 256 by 256, but even that, if you chose to simulate 10,000 things in that area would of course fail.

The easiest thing that new game developers, especially ones new to online game development get hung up on is area size, but it's the least of your concern. What's going on in an area, and how you've implemented it, how and what you choose to simulate and communicate is the tough part. We just happen to correlate the two for you by pointing out that an area represents a unit of simulation, so don't make it too big, unless you aren't simulating anything in there.

[Amanda_Brooks]

The easiest thing that new game developers, especially ones new to online game development get hung up on is area size, but it's the least of your concern.

Well, we're working under the guideline of "think big, work small", and espeically as we're currently a volunteer/amatuer project, we want to avoid wasting precious time and resoruces on false starts, so that's why we're looking to get the exact area size of the city nailed down early on, as we don't want to design and model art assest for the districts only to find that we don't actually have room for all of them to fit in.

[HE-Cooper]

Yeah, what you've described there, is pretty much the reason why most online games fail. The belief that you can somehow get it right the first time. :-) So don't do that. Build, prototype, experiment, figure out the limits, and what you can sacrifice, versus what's important to you. I would plan on 3 to 4 months of engineering work before you bother building as area that's anything other than throw away or prototype.

[Amanda_Brooks]

We'll be combining the experimental phase with learning HSL - so we'll basically just be "playing around" at th start until everyone's comfortable with the engine and its language, and we've established some of the things that it can and can't do.