The modified Island Demo that we showed at the Unite 2009 is finally available for everyone. It shows how Photon can be used on the server side and of course also for the Unity clients.
The pre-built demos are only usable on a Windows machine so far, as they connect to localhost (and Photon is Windows only). But you won’t have a hard time to build them against another IP and run Photon there.
I hope the readme is enough to get you started. We plan to extend this demo, add features and documentation and we are open for feedback of course.
Get the MMO Sample on our site:
Our next steps are: enable you to start a Neutron Trial via webpage, forum and of course the next version of “Lite” for Photon which becomes more flexible and offers more property-features.
Range based updating will surely help quite a few users
I consider myself one of those two and with the “unlimited trial” aka the $100 for 50 CCU license, I’m really tempted to take the idea to Photon and potentially this range sync layer once I can focus on it again.
I tried downloading an SDK last weekend, that seemed to connect to Neutron or something… couldn’t quite figure out what was going on there since I never started a server. Neutron itself confused me too.
From what I could quickly tell, it wouldn’t be possible to use unity’s physics engine server-side, so each client would need to update it’s own version of a physical world. Not such a big deal.
I also wasn’t sure if communication could be handled in an authoritative configuration. Anyway, it seems like a cool product.
Point in fact, Photon rocks, it is very solid and has some of the most useful tools I have ever used. Their staff are very friendly and highly knowledgeable on top of that they have the fastest turn around I have seen in a long time when you email them, they get back with you extremly quickly. So far I say they have some of the best CS around, not to mention the product is rock solid. You really can’t beat it for the price and what you get. It takes no time to setup and although they are still working on making the documentation easier to read, it is really straight forward, not a lot of mucking around in hyperspace if you ask me (an no they are not paying me for this post :))
In short: Photon and Neutron are two different products and while Photon is self-hosted and has a server-side framework to easily integrate game logic, Neutron is a hosted service with many out of the box features to do non-realtime multiplayer games and lobbies.
The samples in the Photon SDKs should not need Neutron. Most likely the sample tried to access our semi-public Photon server. Semi-public as in: it’s not a service with perfect up-time but a server we will update and modify to run the samples on it. Depending on our luck, we updated the server when you tried to run the samples.
That’s a good point. So far we only implemented smaller demo projects and used box2d on client and server side. Maybe we can experiment with Unity’s physics in the future.
Authoritative or not is completely up to you. The server’s basic logic is there and the API should enable you to do anything else.
zumwalt: Thanks! You make it sound too good to be true.
so basicly if i want to stress myself out considerably i could fire up vs c# 2008 express and could make my own networking library and plug it into unity. The only question I have and I apologize if this is off topic but how is the info sent? All the small scale net apps ive made used a bitsream reader and righter and a network stream with all the info sotred in a byte array i guess. are their any basic tuts on this not that im planing on it, just wouldnt mind messing arround
thats what any networking does actually.
How you structure it is up to you, how optimized it is too.
I personally prefer to ivnest into flexible and performant server backends (as Photon for realtime and SFS Pro for turn based) if there are any, as they save you a large amount of time for the development of the base itself but also on the longer run as these plugin / component approaches make it possible to easily change and expand functionality without breaking others while still running performant
birvin: dreamora is right. Anything that goes over the net has to be in byte-array form. Where SFS encodes into a xml (-alike) structure, Photon and Neutron use a byte-protocol to encode types but both are simply bytes to be sent.
Besides: It’s not really public (again, we don’t have a proper SDK yet) but the way you program Photon will soon be available as IIS “component” (don’t know the proper naming, maybe it’s called “application” but you get the idea). This means you could use your Photon “Lite”-derived application and run it in IIS as turn based solution as well. As extension for Neutron or stand alone but fully HTTP.
If there is serious interest in a turn based / HTTP approach, message me and we will hurry up.
its not realy a problem for me. It just may be an off project when im bored. I take it though either way you cannot use unity client then other server?
GETS and POSTS are nothing more than strings passed to and from web servers that interpret them, all these network systems do is act as a web server basically and interpret the data over the internet ports. You can actually post to web pages and get responses from them with your own self written web browser and never touch IE or Firefox or even Mozilla or the like, you do a POST to the site IP or URL it then responds, thats it, you do with the data as you see fit. These network libraries pretty much do the same thing if they decide to use port 80 or any other port that web servers use. It is all fat strings. Not worth a nickle beyond simple stuff, and that is the turn based systems, chats, the like.
I’m just trying out the demo projects (Win32-Grid-Island, Unity-Grid-Island Unity-Island). You can run all 3 at the same time, they are all clients of the same server (very cool).
I was surprised when I loaded the non-unity project (Win32) and was able to add AI players to the island and they would walk around correctly. I found that the y position was just being inferred in Unity via Terrain.activeTerrain.SampleHeight. So these projects are only syncing the x,z coordinates. Not a criticism or anything, just an observation.
I’ve been trying to figure out how AI players would be handled though. How would I add an AI player to the demo? Right now if I press ‘+’ in the Win32 app, I can add a player that randomly wanders around, but as soon as I kill the client, all the AI players it created disappear since they are ‘owned’ by the client.
You’d make an NPC service that plugs in to the server and thus doesn’t disconnect (you’d want failover and a reasonably timeout), with as many players as you have npc’s.
In the end, we didn’t really show AI but faked players. We wanted a bit of movement on the island and wanted to show that real players can walk around instead of server NPCs.
And you are right with the y coordinate being left out. I guess this developed from the 2D sample we had into the Island demo but in the end I would recommend it for any heightmap-terrain based MMO as it saved some traffic.
A single axis is not much of course but this multiplies rapidly when sent multiple times a second per player.
As duke pointed out, this would be part of the server logic.
You have the C# source to implement them on the server yourself. You would need to do the logic for NPCs, maybe provide special operations to interact with them and you would make them send the same events you use for players. At the moment: position updates and name information.
We didn’t integrate server AI so far but it sounds like a good idea for a sample.
