In need of some advice

donnysobonny

Hey guys,

I am currently in the midst of re-thinking the architecture of a game that I have been working on for a number of years after taking a break from it. I am currently at the part that goes over how PUN will be used to implement the networking solution, and I can't help but feel that I am maybe using the wrong tool for the job, and that using Photon to create a custom server back-end might be the better solution. The problem is, I really don't have much experience on this and I can't quite work out what path I should be taking.

Some feature requirements of the game:
- first and foremost, it's a space based, semi-twitch combat, MMO game
- as you fly around the universe, warping from landmark to landmark (planets, moons, asteroid belts etc), each of these landmarks has a unique identifier which ends up being the name of the "room" that you joinOrCreate. Basically meaning that players are split into rooms based on where they are in the universe.
- to allow seamless travel between landmarks (and between rooms), i have had to implement a solution (work-around?) where we don't server instantiate the player's ship, we server instantiate a placeholder object which reads the properties from a local, non-networked ship, and writes to a remote, non-networked ship.

In addition to the above, and because the game relies heavily on a large database, I have implemented a data server into the whole project, which is separate from the networking.


I think the main thing is the seamless travel, as it feels as if the solution that I have come up with is just awkward, and possibly outside the realms of what PUN was designed to do. Does this sound like something that should be done using Photon Server and a custom back-end? If so, if you could direct me towards any resources that I can look at to help me understand it a little better, as I have literally no experience in that type of thing.

Many thanks in advance

Tobias

hey.
That sounds pretty cool. Would like to see such a game

I think you can get quite far without a customized server, if you prefer to go that route.
PUN is designed to do some things, which are not really useful in your case. Switching the rooms will make usage of ViewIDs more complex. My feeling is that you would be better off when you skip the PhotonViews and do your own instantiation.

You could base your game more on Custom Properties and RaiseEvent. The only thing your input moves around is the ship. That can be moved by events and is easily described in Custom Properties (holding the ship config). You can implement instantiation based on those values and use RaiseEvent to move.
Players would only be identified by their ID in a room, while they are in. Other objects of course need some IDs but you could make them up in the level structure you do anyways.

donnysobonny

Hey Tobias, it's been a while!

Firstly, your suggestions have given me some hope so thank you for your input. I have a few questions in return.

1 - There was some time ago that I made a post about the difficulties in using custom properties some time ago (viewtopic.php?f=17&t=2979&p=13773#p13773), I assume these issues have been resolved?
2 - What sort of data would you recommend to store in custom properties? For example, static data (data that never changes), semi-dynamic data (data that changes irregularly), dynamic data (data that changes regularly, likely every single frame)
3 - I haven't yet used the RaiseEvent, my understanding is this is a relatively new feature to PUN? How efficient is it going to be to replace using the stream and serialization with (I assume) RPC like events? Surely that will be harder for the server to handle at a frequency of something like 30-60 messages a second?

The more I think about your suggestion the more sense it makes... If I understand you correctly, the solution would rely on a player connecting to a room, and us then using the OnPlayerConnectedToRoom (sp?) event and the player's custom properties to handle insantiation, and the RaiseEvent to handle interactions between players within the room?


As for seeing what i've done so far, I am definitely keen to showcase things, however a huge amount of what i've done so far is the business logic which means there' not a huge amount to show at the moment. There is a rough demo showcasing the movement mechanics of ships, and the different sizes that ships will be: http://sbth.extorio.com/ship%20sizes/ship%20sizes.html

Any feedback is welcome. Thanks again for the help!

[edit]
I've taken some time to look over the RaiseEvent and RaiseEventOptions classes over my lunch break, and I am struggling to find any examples of it being used, it would be great if you could direct me towards them? From what I have read so far though, it seems very interesting indeed. Would it be possible to literally have all players connect to one single Room, and simply use the RaiseEventOpsions.interestGroup to interest manage the interactions between players? Would this be able to handle hundreds/thousands of players in one room? Exciting stuff!

Also, I've been reading up on your Photon Realtime application, and it looks like if I don't actually need things like PhotonNetwork,Instantiate and the features that come along with that, that I don't actually need PUN. Would your Realtime application maybe be a better solution if I were to go down the path of using custom properties and events?

Tobias

I was at Unite, so sorry for the late reply.

1: That did not change. When you update a property, we locally set it right away without the roundtrip.
I can imagine a work around (just had an idea) but it's not in yet. You can probably also use the new SetCustomProperties() variant with another parameter "expectedValues" (or similarly named). It makes the server check if your expected values are correct and the server decides if it can set the new values (replacing the defined old ones). If you use any simple expectedValues (something you know is correct), the server will send back the props changed and we don't use the local shortcut (which excludes the roundtrip).
This does not guarantee that the properties are visible in the lobby then by everyone though. The lobby sends updates to clients in regular intervals, so it can aggregate updates. You can't know when those are done. Also, you set the values on the Game Server and they have to travel to the Master Server first.

2: I wrote something about that here:
http://doc.exitgames.com/en/pun/current ... -and-state
Infrequently changed values are best for properties, I think.

3: The server only sees a bunch of byte[]. It doesn't have to read everything and RPC is actually built on top of RaiseEvent (but it wasn't exposed).
Actual effectiveness is up to you. RPCs contain a few values you can't skip and in principle, the RaiseEvent path can be leaner. But it depends on what you put in.
There are no good examples of use for PUN yet. The API is a bit different but aside from that, it's the same as in the LoadBalancing API.
http://doc.exitgames.com/en/realtime/cu ... time-intro


It's not a good idea to have all players in one room, even if you use Interest Groups. One group (0) will get a lot of events for all. This can't be avoided and it will still cause enough traffic at some point to ruin your game. Also, Interest Groups are "dumb". The client defined what it needs to see. It never gets updates of something in a group not subscribed, even if it would have reason to be interested.

PUN is basically a wrapper or an alternate implementation of the LoadBalancing API for Realtime. If you ignore PhotonViews, RPCs and such, you can use it in a very similar way. But yes, you could switch, if you prefer.

robbskinizer

Hey. man you stole my game

Im working on the exactly the same game... I got every thing to work, thou im running pun server and my own mysql. The game will be released on both iOS and Android next month. Im only use PUN for my Connections, the server handles all sql calls. But they dont know about it.