Print

[PN-Dwight]

Hello community!

We are currently in the process to port over all of our assets and systems to HeroEngine, but I am wondering what your experience would say what the best solution is to my current issue.

In the attachment, you will find 3 potential scenario's for our seamless world grid. The game itself is based on an island structure: the player will travel from island to island to discover new abilities, new quests, and so forth. Hence, I believe that most area-load would be on those islands. What would the best option be?

Scenario #1:
Each Area consists of only 1 heightmap. Both in the X and Y direction, we will start expanding. Each heightmap will have 1 area server (a la 15MB of RAM on average on the server).

Scenario #2:
The island will be built on a single heightmap in the area, with 8 surrounding heightmaps creating a nice and even area which can be seamlessly linked in a better way. The other area's, which won't have a lot of players, consists of one large heightmap and an ocean the same size of a standard island-area.
Advantages: we are increasing the size of an area which isn't highly populated and we do have a whole area server for a single island. The RAM on the area server, if an area if 4 times as large but less populated would be less than 4x15=60MB. When there's less populated placed, increasing it size would be rational if game-design requires it so.
Disadvantage: ?

Scenario #3:
We will create a single area with a single heightmap which only has the island. We would then be creating L-shaped area's with 2 heightmaps that go around an island-area. The blue waves indicate the ocean.
Advantage: the island-area is smaller, and thus the world server can concentrate more on that island.
Disadvantages: ?

I would love to have your input on our area design concepts! We believe that most of the time, the player will start exploring the area's at the bottom of the sea and will visit islands solely to trade goods and do quests. Quests of course will be handled by a different system area, and thus won't have a large impact on the island-area server.

My plan is option 3 due to server load and player-management.

Kind regards,


Dwight

[Thazager]

From what I have seen and read about, linking 4 areas at a corner point is not very good. It might be better to link them where 1 is half way between 2 others, or have the row of areas offset by half an area.

[Prometheus2012]

Uhhh Dwight you are back?

[PN-Dwight]

From what I have seen and read about, linking 4 areas at a corner point is not very good. It might be better to link them where 1 is half way between 2 others, or have the row of areas offset by half an area.

So you won't get players, by chance, going around in circles where the 4 areas meet. That's actually a good idea! I will build some testing grounds and see how it works! Thanks a lot Thazager!

Uhhh Dwight you are back?

I was never gone; I lurked. But yes, I am back now in active development again after we developed the game in a different Engine. Porting assets over as we speak and developing the 3D Studio Max toolset again

[Amanda_Brooks]

From our testing work it seems that laying out seamless links in a brick like pattern, with each junction being a "T" shape between 3 sections, is the one that works the best.

[PN-Dwight]

Thank you so much for your input so far, it helped create a whole new plan for the island-environment.

Has anyone come up with a solution on having the size of a water plane the exact same size as a heightmap? So far, the heightmap units and water-units are not the same.

[nocake]

here is a guide to seamless stitches:

https://docs.google.com/document/d/14Mq8t9lDWGXSMC21Fu5_ScC7BeeZXsY8acBFCVPOreA/edit


You will want a square inside a square for the islands imo.

Say like A1 being the bigger square then A1-Island being a smaller square inside that area. That way the island only loads once they hit A1 instead of loading while in B1 or something.

Hope that make sense.

Also as far as I know there is no easy way to make an ocean. I think you have to tile Ocean Water objects.

[PN-Dwight]

And henceforth, my plans get optimized, I believe:

The Scenario by Thazager and Amanda would be to use an alternating brick pattern to not have a small position where the player can seamlessly cross borders with 3 adjecent area's and thus loading and unloading things in memory.

- The brick pattern is something very advantaguous and would resolve a lot of my issues, and not create new ones to the current extent of my knowledge.

Taking nocake's advice into consideration (Scenario nocake), I hope you mean something like as depicted below?

- Advantage here is that the island won't get rendered as long as the player is not in the vicinity of the border of the ocean-area surrounding the island directly.
- Advantage as well is that as soon as the player is on the island, I only would be needing to render the area with the yellow arrow depicting the viewdistance additionally, which would not be resource intensive, as it would only consist of a heightmap and ocean.
- Disadvantage is that the minimum render-distance is of that of the largest island in that area for the entire world, but that can be solved by having different environment-settings on a per area basis.

Having the render-distance decreased in the area surrounding the ocean would even leave enough time without a loading screen to render the island.

To conclude: To whose who have a lot more experience with HeroEngine over the years since its development and testing, would you also suggest the scenario as depicted by nocake, if I have understood it correctly?

(P.S.: This has been a really helpful discussion, so I want to thank you all for your input so far!)

[Thazager]

The island could go either way, with 1 area in side another, for small islands, or with a bigger island, 1 area surrounded by others. Some buildings where the player can enter are also 1 area inside another, though those are more for seemless type areas. If you have zoning at doors, it can be a totally separate area.

[nocake]

The island could go either way, with 1 area in side another, for small islands, or with a bigger island, 1 area surrounded by others.

Actually opposite of this. Large islands should be an area inside an area to prevent the other areas from loading such a large island.

The smaller islands can be just places inside the normal area square.

It really is all about load and what you are trying to accomplish but smaller islands take less assets so they are ok to be loaded in the main area.

Yes your illustration is exactly spot on. The wiki article also goes over a lot of the stitching approach while my tutorial gives your the tips and tricks to get it done.

[Prometheus2012]

Nice design ideas here.

Dwight you still around? You should join the HE skype group.