Unity and Photon

edited January 2010 in DotNet
I'm currently developing a MMORPS with Unity but so far I can't figure out how to handle the networking. I don't know very much about .NET or networking in general and I couldn't understand enough from the Photon SDK to integrate it into my own project. My aim was to get at least 250 in on one server. Would Photon work for a project like this?


  • The number of players is depending on a range of factors: how much "work" do you spend server-side on each user, how much interactivity does it have, how is persistence handled, how performing is your code, etc. Also the hardware is a factor.

    250 players are no problem per definition. It sounds like a feasible number and Paradise Paintball surpassed this number.

    Like many experienced developers, I can only encourage you to start with really small steps. Making any MMO game is a feat and making it alone is doubling the effort. Maybe you can divide your project in many smaller steps, which all build against your goal but are easier to achieve.
  • Well I plan to make the Demo first (The Training area for the main game will be the Demo) then expand to a certain goal (making one of the large main maps) and keep going from there. My real problem with Photon seems to be the fact that I don't have much .NET or C# experience (something I'm trying to remedy).
  • Unity is using the Mono framework - which is basically another implementation of .NET, so if you've been developing with Unity, you might already be at least "a little" familiar with .NET ;-)

    And C# also shouldn't be too hard to get into (and I'd use it for Unity as well ... for consistency ;-) ).
  • Thanks for your help. I think I'm going to start on learning more about C# and hopefully soon I'll be able to develop a fairly efficient game.
  • Caring about efficiency or better optimization at the start of a project is normally not helpfull.
    You won't know how it will look and work at the end, for that reason its normally impossible to optimize the code / behavior in a way that makes this "final code" faster, often you just make the code less flexible and harder to maintain and optimize the "good way"

    Exception to that are naturally basic optimizations like "store an object reference to an object you get from a function" if you use it several times in a row and alike.
    Or in case of multiplayer games, if you write the code accordingly you can avoid sending events if nothing has changed since the last sending.