More Documentation?

Kreag
edited July 2010 in Photon Server
Hello,
I've been looking at photon with Unity 3d. I'm coming up a little short.
I can follow (somewhat) the flow of how the sample works, but am having trouble understanding the best way to extend the server side to handle common tasks. For instance, when a client connects the server (liteserver?) gets in incoming ExecuteOperation call with the join operation code. It looks like this is abstracted on the client side somewhat by the PhotonUnity3d.dll. I'm unclear as to what is the best way to add something like login or another in game event (chat messaging?). Do I add operationcodes for every other type of message or do I package the packets differently?

I've looked at the documentation that says all of this is easy to do, but haven't seen anything on best practices. Are there any examples of the best way to add on some of this functionality? I'm sure I could get something working, but I really want to know how I *should* be doing this stuff.

On a side note, I notice with the Unity demo that there is a significant delay in a player disconnecting and the player disapearing from the other players board. Also, and I'm sure I'll figure this out when I study the code more, but even if the server is turned off (app mode, no service) I can still start the demo client and it runs.. giving me server ping time and all stats. What is it connecting to? I've read everything on these forums and on the Developer Network. I see information about the xml config file (which seems very straight forward to me) but nothing about what looks much more complicated to me. Am I missing some docs?

Comments

  • We've been working on documentation for Photon, but also refactored many of the less intuitive parts of Photon. The many changes we did are the reason why we did not work on the current documentation. Now, server- and client-side SDKs are in the pipeline for a release.

    In the mean time, I hope this helps you:

    "Photon" is the name of the server software you are running. It opens (incoming) ports on your server machine and clients can connect to it. The "Lite Application" is a basic application with server logic, which is written to implement our interfaces to be run by Photon.

    I hope I'm not making it more complex now:
    The application interface of Photon does not mind Join or Raise Event. It only knows "operations". It's Lite that gives each operation code some meaning and implementation.

    So far, our client side API did not distinguish Photon from Lite. As example: "connect" is targeting Photon and tells Photon which application you want to connect to (example: Lite). The Operation "join" is a RPC call implemented by Lite, not by Photon itself.

    In the new SDKs, we have make the distinction between Photon and Lite more visible (PhotonPeer class and a LitePeer respectively).

    The refactored clients are released as RC SDK: Photon-Unity3D_v5-7-0-RC1_SDK. The LitePeer.cs is attached to this post, so you can see first hand how we use the Lite Application on the client side.

    Hope that helps.
  • I'm still not getting it.
    I've been studying the MMO sample and I'm still stumped. I think that because it is so abstracted, I am having trouble understanding the code... and I do C# stuff for a living!

    Just a simple explanation of how things interact and a few examples of how to do common things would likely help make the lightbulb switch on for me. For example, where would I put the code that checks the DB for a username/password auth? I build stuff like this everyday, but I'm just having trouble with the abstraction (don't get me wrong, this looks like a very well laid out, efficient architecture).

    Are the docs coming soon?
  • Yes, coming soon. Need to add a few more sequence diagrams and that's pretty much it.
    Since you ask about authentication... It would be the EnterWorld operation (if you don't want to add an additional state): MmoOperationsInitial.EnterWorld
  • Thank You! I'm not sure why I didn't see that before.
  • FYI - the new photon server RC2 contains more MMO documentation. Hope it makes it easier to understand.
  • Ciao guys,

    I just wanted to follow up on this post and see how the documentation is coming along and what was available. I just downloaded Photon + Unity this weekend, because I would like to begin work on a MMO.

    On the unity side, I've completed several of their tutorials and feel I have a good command of what is going on. I've already started building the game from scratch without issues and with all the documentation available for Unity, I don't expect any problems. For Photon, I've setup the demo and worked through the mmo fesibility concept and read most of the code without issue - but I'm just not quite getting it.

    Are there any good tutorials available for Unity + Photon out there? Specifically, I'd just like to be walked through exactly how things interact, the primary scrips to call within unity to attach the client -> server messaging, and a brief example of how to execute an activity (something like, executing a trigger when an object is impacted by a spell, sending the required data to the server, executing a server side function to adjust the object's hp, and return that hp to unity/gui).

    Thanks in advance for your time,
    Chris
  • No tutorials yet for that.

    I will be starting on a few, likely by the end of this month or so (first for LiteGame, then the Mmo one) to cover such aspects.

    Client -> Server communication in this case would be done through an Operation you implemented for the purpose.
    Server -> Client would be done by setting the items HP Property and let it sync to all interested objects on the client basically.

    The "within unity part" goes towards 0 in this equation by the way, the majority will be implemented in a PhotonUnity3D layer (thats basically the PhotonDotNet one but you replace the referenced photondotnet with the photonunity3d in the lib folder and you additionally might reference the unityengine dll). That project additionally would be set to compile to .NET 2.0 (will throw at you an error due to extension methods when it reads properties. you can easily overcome that by not use the generic read method used there but just use (targetType)Properties["someKey"] casting)
  • That doesn't sound encouraging :)

    When you get the tutorials up, let me know - I'd enjoy paging through them.
  • Sure sure :)
    I will post them here, on the Photon Thread on the Unity boards as well as my blog (unityversum.com) and naturally my website (gayasoft.ch)
  • Specifically, I'd just like to be walked through exactly how things interact, the primary scrips to call within unity to attach the client -> server messaging, and a brief example of how to execute an activity (something like, executing a trigger when an object is impacted by a spell, sending the required data to the server, executing a server side function to adjust the object's hp, and return that hp to unity/gui).

    So far, we tried to avoid such in-depth tutorials and instead we wanted to provide plain and simple ones. The realtime demo in the Unity SDK is not really complex but on the other hand, there is not much to distract you from the core.
    Granted: it's not very Unity-like. The script used is as in most other platforms and barely scratches Unity's features. There is a Game class and a Player class. Those show how to connect, join/create a game and how to send/process events. This same principle can be used for everything else.

    There should be a documentation pdf, which also favors "plain" over "complex" but lists every class there is and each method is described.

    I hope this points you to at least a bit more of information. Let us know if you got more detailed questions. Maybe we can actually create a tutorial for something you miss most.
  • I don't think I can add anything to this thread, except to say that I'm working through the provided samples and documentation, and I "get" the sample for the Unity Client SDK (although if I'm putting it all together correctly, the included PDF is specifically talking about the LITE and not the more basic PHOTON level server...?).

    For me, it would be helpful to basically strip away the "helpful" implementation examples and just focus on the absolute bare minimum of what a developer would need to begin work on adding his own logic to the server: here's the source for the basic server; to extend it, do this or look here; here's some suggestions on what ELSE we can do with the base server. In all honesty, the Unity tutorials (as opposed to just straight up documentation) are WONDERFUL, and have gone a long way towards getting me up and running with Unity quite quickly. Perhaps a more "tutorial" approach would be beneficial.
  • You can look at the lite application. Thats actually source built on top of the very basic layer (and what you would do yourself for a "multi distinct session" application). There is no lower level than what is used in lite.
  • So we would, in effect, be adding on to the "Lite", as it stands in the provided SDK? I'm looking at it now, having loaded the SLN into VS, and it includes the TestConsole, and Tests projects as well. Building this project creates a Lite.dll for the Lite project. I know this will sound rather daft, but...then what?

    There's references to Photon.SocketServer, PhotonHostRuntimeInterfaces, EditGamesLibs, PhotonDotNet...are these "standard" references that we should know about? I'm mainly trying to get a handle on what pieces are needed to go forward.

    Thanks!
  • The idea is that you extend Lite. It is a basic framework which you could change but it might be easier to add to it simply. It's pretty basic already but implements some common requirements: peers, rooms, porperties.

    This is what LiteLobby does: it includes Lite as reference and extends it. The nice part is that you can see the code of Lite while you extend it this way.

    The MMO Demo shows how else you could work with Photon. Again, this is hopefully a base you can extend to make it more game-specific.
  • All right...In reading through the documentation that came with the server SDK, let me see if I have this straight:

    With the Lite source code, we can create our OWN Operations (.cs files and their associated Enums in the Enums.cs file) to do what we need: taking the hash table parameters to perform a db lookup, formatting the results and returning them to the client, for example.

    Once we have these custom operations set, we compile down to Lite.dll, which we then can copy over to the provided distributions included in the SDK package: bin_Win32 and bin_x64. Then we deploy that whole folder to wherever we we want the server to reside.

    On the CLIENT side, we then call Peer.OpCustom(), passing over the OpCode defined in the Enums so the server knows which Operation to execute, and what parameters to expect. The server grinds the info and raises events to return results to the client.

    Am I on target?

    Thanks!
  • Yep, you are!

    If you just modify Lite, it will mean some more effort in case we update Lite in some way or another. In most cases, extending it should be cleaner for future changes.

    If you modify Lite, the server is setup to run it from the deploy folder. In case you create a new solution (similar to LiteLobby), you would have to adjust the server's setup file: photonsocketserver.xml (in the bin_* folder you are using). You most likely put everything in it's own folder and maybe change the name of the .dll. Then it does not run out of the box with the SDK (it simply does not know your code / binaries).

    You can run everything locally and test it with the client side on the same machine.

    One detail: there is a slight difference between events and operation responses. The operation RaiseEvent is creating events from what you give it and sends them to other players in the room. You (the peer who called the operation) will get a response for RaiseEvent. This is the return for it. If your operation was executed, return values and such. And: return values are only sent from Photon and only if the operation was reliably sent.
  • Tobias wrote:
    Yep, you are!

    If you just modify Lite, it will mean some more effort in case we update Lite in some way or another.

    So at this point, in order to avoid potentially having to re-write extensions to Lite, what is the recommended path? Let me just explain what it is that I'm looking to do, and it may help illuminate my confusion.

    I'm not looking to make an MMO, so all of the MMO trappings provided in the MMO sample are going to be overkill. Instead, I want a small scale (4-10 players total, say) multiplayer game. Players will create a character (give it a name, select some stats, etc) and will then drop directly into the game world. No lobby, no matchmaking. Players can move from zone to zone, and each zone will contain "things to do". The rest of the mechanics aren't relevant at this point, I don't believe.

    So with this in mind, would it be a correct assumption that I'd be taking the Lite server as is and simply create extensions? Is there any LESSER option that provides less overhead then what Lite would offer (not sure WHAT overhead, but I like to start off as simple as possible and build up from there), yet still handle connections and the major server-style events (connect, disconnect, login, logout, etc)?

    Thanks for all the help guys! :D
  • The part "will then drop directly into the game world" is a little bit nebulous. We can only guess how you keep players from crowding in one area / room.

    The two models "Lite" and "MMO" in our samples are pretty much only a basis for whatever falls into each category. Not much overhead, nothing performance eating but all well established, easy patterns we really believe you should employ.

    In your case, Lite seems to be the better starting point. Each game is separated, as is every peer. Everything that's not room related can be done in LitePeer, while rooms are feed via message queues, which keep concurrency (and thus needed locking) low.

    This is what we strongly advise.


    It's part of Photon that you are able to skip Lite and start over from the interfaces to Photon Core (which are pretty tiny). However: we spent a lot of time, solved many issues and avoided some hard to debug situations, before we came up with Lite in the current state. You might find a better way for your needs of course but in general, Lite should save some time at least.
  • OK, I think that's the general clarification that I was looking for.

    Thanks!