Any introductions to Photon Engine with procedural terrain?

graphe

Hey

I'm new to Photon Engine, but not to coding or procedural generation.

Could you point me to posts or tutorials that show or explain the following topics?

For simplification, let's assume an "infinite" top-down 2D procedural game with an "infinite" 2D plane (x/y) that consists of "tiles". Each tile is basically a rectangle, so to speak, nothing fancy. It is clear that the world terrain tiles/chunks base on a "seed", that I can sync share this "seed" between clients.

a) This works for a procedural readonly/static world. But how would you update single tiles that the player changes?

b) The Viking Demo Project. When you open a standalone client and a Unity Editor client, you can manipulate the terrain object itself inside the editor. When you alter the position of the terrain object, the standalone client syncs wrong positions. I suppose, it is by design and that I have to tell -- in such a case -- the terrain object to be synced too, right? But we do not want to do it for all or numerous "terrain tiles", right? Only for those that were moved?

c) In our top-down examples, tiles are constantly destroyed (actually, the game objects are not, they are put back in a tile cache) and "recreated" when the player changes his position (much like a viewport movement that adds tiles on the left, when you move left). When the player moves to the left by 2, 2 tiles are removed on the right and 2 tiles are added on the left.

What do you do when Player A and Player B are in completely different areas, with distances of 1000-10000 between them? Do you suggest to store the changes on the server? Are you taking care of it, when: Player A makes a change at the position (50, 50), but Player B is at position (10000,10000) and not able to see the change, so it does not affect him. Do you tell Player B when he is close to (50, 50)? If, how? Or, do I have to implement it?

d) So far, most examples are about player input. When we assume dozens AI characters per sene -- I suppose it is the same as player chars?

e) Sometimes a tree that is idle suddenly gets active, does something, i.e. drops "loot", "fruits" or changes into a new character. I suppose that this too is connected to a) and d), right?

Any help is much appreciated. The sooner I can jump into your framework, the better. I do not mind 2D or 3D examples.

Of course it is about efficiency, and as compact and as rare sync updates as possible.

[Deleted User]

Hi @graphe,

sorry for the late response, hopefully it will be satisfying for you.

a) This works for a procedural readonly/static world. But how would you update single tiles that the player changes?

At this point we need to separate between Cloud and Server possibilities. Since you don't have any custom logic when using the cloud you might want to think of another solution. As long as you don't have uncountable changes you can use the custom room properties to store some data, e.g. a changed tile. As said this might work but as the amount of changed tiles rises, we need another solution. At this point we might want to use the Server (OnPremise) where we can add custom logic using the Plugin system. There we can easily store changes in the server's memory or even on other servers or services, e.g. a database server.

b) [...] I suppose, it is by design and that I have to tell -- in such a case -- the terrain object to be synced too, right? But we do not want to do it for all or numerous "terrain tiles", right? Only for those that were moved?

To the first question: yes, you have to synchronize the terrain's position as well. When moving the terrain you might have for example a situation, where the local player stands on top of a mountain because his terrain has been replaced, on the other client this player however stucks in a tree. This causes the physics system to handle by pushing the player out of the tree but it gets set in there over and over again because of the synchronization. To the second and third question: yes, since you are using a seed and every client can create the same world based on that seed, you only want to store tiles that differs from the 'original'. This is connected to your first question.

c) [...] What do you do when Player A and Player B are in completely different areas, with distances of 1000-10000 between them? Do you suggest to store the changes on the server? Are you taking care of it, when: Player A makes a change at the position (50, 50), but Player B is at position (10000,10000) and not able to see the change, so it does not affect him. Do you tell Player B when he is close to (50, 50)? If, how? Or, do I have to implement it?

Short: Yes to mostly all the questions.
In detail: Of course we want to know about every change a player make, so a player will send the change to the server, even if there are two or more players heading in completely different directions, but you won't update the other players. At least not if they are far away. This is Interest Management. Store mostly all input from each player, but only forward messages when a client is interested in something he is close to. This is something you have to implement on your own. You can use regions for example. A region is an area of - let's say - 100 x 100 tiles. Player B now enters the region, which is noticed by the server. The server will send the change made by Player A (affected tile is 50;50) to Player B so that he can process the change. When finally entering the tile, the previously made changes are visible to player B. Thereby it doesn't matter, if the change was made a few seconds or a few hours ago.

d) So far, most examples are about player input. When we assume dozens AI characters per sene -- I suppose it is the same as player chars?

e) Sometimes a tree that is idle suddenly gets active, does something, i.e. drops "loot", "fruits" or changes into a new character. I suppose that this too is connected to a) and d), right?

Mostly yes. Therefore I'd like to share a talk from David Salz from Unite Europe 2016 which is about the game Albion Online. He talks about how they managed to do some stuff that is somehow equal to your questions. I guess this gives a better understanding.