SmartFox API 1.1 released + 4 Unity tutorials

Hi everyone,

I wanted to announce, that the version 1.1 of the API has been released.

Besides bugfixes, the 1.1 API also introduces a new "queue mode" specifically designed to make it work more safe with Unitys non-thread safe environment.

But thats not really the best part - the best part are 4 full tutorials with free access to the source code for 4 tutorials - Unity projects included.

The 4 tutorials are:

* basic connection setup. Absolute bare minimum project

* a lobby - slightly revamped from the earlier Unity sample project distributed with the 1.0 API

* a fully working turn based tic-tac-toe tutorial that is 98% interoperable with the 2 flash based tic-tac-toe demos released with SFS itself

and lastly the main one

* a networked island demo complete with basic interpolation, animation synchronization and ingame chat

I hope you enjoy these, and if you got any questions then shoot them at me.

The API is totally free, and the sources for it are also freely available.

SmartFoxServer itself is a backend server system with licenses that are free to use for up to 20 simultanious connections and prices starting from there.

And no - I dont get paid a % of sales

Some links:

http://www.smartfoxserver.com/forums/viewtopic.php?t=4629

/Thomas

 

That's really great! Thank you for all your efforts!

I see here that SmartFoxServer works on, well Unity (thanks to you) and iPhone (among others). But it seems that, Smartfox right now, requires .NET 2.0.

Is there any plans, to make Smartfox Unity works on Unity iPhone?

And that's a shame!

 

Yes - and fully featured too. So your SFS Unity game will be able to (on the networking side) run fully unaltered on iPhone too and even be interoperable between all the different platforms that SFS supports.

There is a technical problem with the current Unity iPhone version that prevents me from releasing it though. So I cannot give you a deadline.

I'm pretty sure that the marketing drums will be slammed hard once the date approaches.

 

Amazing work Thomas!

I already had SFS installed from when I was testing it a long time ago. I downloaded your IslandDemo, started up the SFS server, and everything just worked.

In less than 5 minutes I had 2 computers walking around that island.

It will take me a bit longer than that to pick apart your examples, but not much longer based on how nicely laid out everything is

 

Thanks! I really hope it can inspire a bit.

Beware - I also write that in the tutorial - that the island demo needs some work before using it for a production game. Its more to show the possibilities.

Things you would need to consider is to make your own protocol that limits usage of bandwidth - as well as server side zoning etc.etc.etc.

 

You rock

 

This is extremely cool. Thanks Thomas. Can you elaborate the issues with the iPhone a little? Is it something that the overworked guys at Unity needs to fix and then you can work on it?

 

Thanks guys - really appreciate the kind words, and happy as ever that anyone uses it.

On the iPhone port:

The overworked UT guys need to get a new Unity iPhone update out for the general public. *I* already have SFS running on my phone, as I got a bugfixed build to continue my port ;-)

That will happen after 2.5 in case anyone wonders. Cant come as a surprise.

So yes - I already have tic-tac-toe tutorial ported and I can play a game from my phone vs. the tic-tac-toe tutorial on my Mac. Took around 30 mins to port it - mainly fixing up the GUI. Still not beautiful, but working.

But I am really not supposed to blabber about all this - so sshhhhhhhh. Secret ;-)

Screenshot from actual phone:

 

Perhaps this is just me but there seems to be a problem with CreateRoom on SmartFoxClient

independent how not-null the hashtable is, it will always fail and insist on beeing provided with a null object.

Using JoinRoom for an unexisting room also does not seem to work.

Im working on the more or less untouched island demo from above / sfs page

 

Do you have some code examples? Either post them here or mail me the stuff - thomas a fullcontrol dot dk

 

Can post it here, no problem.
Didn't have the time before as I had to run to pickup my GF

The following code is the replaced Start from NetworkController in the SFSIslanDemo

Code (csharp):

1.  
2. void Start() {
3.         Application.runInBackground = true; // Let the application be running whyle the window is not active.
4.         smartFoxClient = GetClient();
5.         if (smartFoxClient==null) {
6.             Application.LoadLevel("login");
7.             return;
8.         }  
9.         SubscribeEvents();
10.         started = true;
11.        
12.         smartFoxClient.JoinRoom(Application.loadedLevelName);
13.                
14.         Hashtable tempTable = new Hashtable();
15.         tempTable.Add("name","guild_000001");
16.         tempTable.Add("maxUsers", 500 );
17.         if(tempTable == null)
18.             Debug.Log("You will never see me");
19.         smartFoxClient.CreateRoom(temptable); //<-- This will fail
20.         smartFoxClient.JoinRoom( "testroom_000001", "", false, true );
21.         // alternative
22.         // smartFoxClient.JoinRoom( 11082, "", false, true );
23.        
24.         }

A small question thats partially related: is it possible to get multi room joining working from the client side? Above will not work even if I choose present rooms to join while dontLeave is set to true

This is Unity 2.1 Pro, SFS Pro 1.6.5 trial

 

One fast reply (sitting in the middle of a refactor with my head there)

SFS API is async. So you should in general not fire off a series of commands right after each other, but rather wait for the response callback.

The NetworkController class doesnt subscribe (if you took the default) to the OnRoomAdded callback or the OnCreateRoomError callback.

Try to add the following and see what happens - especially the debug message callback should point you in the right direction.

Code (csharp):

1.  
2. SFSEvent.OnRoomAdded += OnRoomAdded;
3. SFSEvent.OnCreateRoomError += OnCreateRoomError;
4. SFSEvent.onDebugMessage += OnDebugMessage;
5.  
6. public void OnRoomAdded(Room room)
7. {
8. Debug.Log("Room " + room.GetName() + " was created");
9. }
10.  
11. public void OnCreateRoomError(string error)
12. {
13. Debug.Log("Room creation error; the following error occurred: " + error);
14. }
15.  
16. public void OnDebugMessage(string message) {
17. Debug.Log("[SFS DEBUG] " + message);
18. }
19.  

 

I had the room added present already to be able to react to it, but it actually never got fired back then due to the crash.

Your input with the async helped me to get rid of the null object error and even joining multiple predefined channels works without problems, so the room joined delegate works.

The main problem remaining is that

Code (csharp):

1. smartFoxClient.CreateRoom(tempTable);

never returns. I've debug output in front and after and the one after never gets called.
Is there something special that needs to be enabled / setup to have room creation working?
I've checked the server config and the sys setting that would prevent room creation is not set, so from the config point of view it should work (its actually the same as the original one but with a limbo room added)
This code now is in the onJoinedRoom delegate and is called if the room that has been joined is identical to the zone name (I renamed a channel to have "zone wide" channels made simple)


Thank you for the input so far, was of great help

 

Super that it selped you along a little. Lets crack the last nut too

In general - all that hashtable stuff is inheritted from the action script API that I used as template when porting. Wanted it as close to the existing AS3 API.

But exactly this room hashtable is a fugly thing - and one I want to get rid of in the next iteration of the API. Hate that you insert a hashtable with certain values vs. creating a NewRoom object instead to take some of the guesswork out of things.

Anyways - try to add this additional to the room object you create:

tempTable.Add("isGame", false);

(or true if its a game room)

I think that will do the trick.

From the tic-tac-toe tutorial I do this:

Code (csharp):

1.  
2.             Hashtable roomObj = new Hashtable();
3.             roomObj.Add("name", smartFox.myUserName + "'s game");
4.             roomObj.Add("isGame", true);
5.             roomObj.Add("maxUsers", 2);
6.             roomObj.Add("uCount", true);
7.  
8.             Hashtable ext = new Hashtable();
9.             ext.Add("name", "tris");
10.             //ext.Add("script", "it.gotoandplay.extensions.examples.SFSTris2");
11.             ext.Add("script", "sfsTris.as");
12.  
13.             roomObj.Add("extension", ext);
14.  
15.             smartFox.CreateRoom(roomObj);
16.  
17.  

So that certainly works. The extension part is optional, so you can skip that completely.

Already put stronger validation into the todo list for next release.

 

Yeehaa
You are right, that little missing line did it.

I already feared something like that.
The main reason I didn't add it is because the documentation mentions it as optional, which does not seem to be the case then.


Thank you again for the great input.
never would have assumed to get that much going within a day actually.
The past evaluation cases with alternative network server backends took multiple times longer to get onto a similar level and lower levels than SFS got us within a day.
And we didn't even need to touch extension. The possibility to use Terracota makes it a pretty powerfull server backend technology for professional users

 

Super - very happy it got you going, and yeah. Seems like a bug in the code / documentation One of those small things.

In general I'm also seeing SFS as super powerful for a very reasonable price. Thats why I ended up spending my own time to code the API, having previously wasted man months coding my own server backend.

SFS isnt perfect - it doesnt have the most bandwidth friendly protocol etc.etc., but those are things I know will improve "soonish". But for most of the use cases for indie games its absolutely great to use - imho.

Buzz me if you have any other issues or questions!

 

Thank you for the offer, will do so.
Will naturally also buzz you if I have something to contribute

I agree with you on the power potential.
Can't comment on the bandwidth yet, thats something we will see over time.

But hey, at least those information are easily accessable from anywhere

 

Bandwidth can be managed by using extensions and writing your own compressed (though still string based) protocol. But you can do a lot of bit shuffling there and optimize things.

Another issue on a higher level will be having to code actionscript/javascript or java for backend extensions. Might not be a big issue, but some might shy away from having to code in a different language and/or having to port game code to the server side for authoritative servers.

There is a workaround to that issue that we are using - we run mono on the server side, and have written an extension that acts as a "bridge". So the exact same C# code can be run client side (for single player va. AI games) as well as server side (multiplayer or networked vs. AI). I dont know yet if that tech will be something to buy from me or something I'll release later for everyone. Too early to say.

Other than that - I dont really see any issues, and the EC2 / Terracotta scalability potential makes this one great package for small teams.

 

Oh if that is all to get better bandwidth, then its really a no prob as such stuff would have been done either way likely to make the stuff cheat save

I expected having to write a lot of extensions. After all we before had planned to write the whole backend ourself so it can only be less work if the backend already does a fairly large amount of the world.


I think the SFS creators should make something like an affiliate program or alike, as you likely have sold them a few licenses already and more in the future

 

Yeah - would be nice with %, but I'm happy if there are some smaller consulting jobs dripping off this (and they have already send me some lumps, so thats really cool) + it helps our own game dev too. Win for SFS, win for me, win for everyone using the API.

 

Excellent work Thomas, this is a great deal, we all thank you for the api.


Let me just remark that i am kind of noob on the networking side, and hoping to learn from this geat community,

I have a few questions:

1- why did you considered SFS for the backend server?
any particular reasons you like it or features?


2- did you considered or tried before you choose SFS any other servers? ie: raknet, or Enet? or they just way too complicated to work with? or because unity's present .net networking library will make it easier to do so.

Again, sorry if these questions are kind of dumb on my side to ask, but like I stated before, I am just beguining to dive into the networking side for games.


thanks again for your time and keep up the good work.


reards

 

1. Flexible usage, platform independent powerfull server, easy extendable through plugins.
It can be plugged into TerraCotta and comes at a very fair and more than competitive price (especially in relation to the two major alternatives listed first in 2)

2. We evaluated Photon (realtime Neutron) which is a server Backend solution as well as NetDog which is an MMO oriented network library without any Server Backend solution. Especially ND, at least out of our view, does not justify its license costs right now. Its license fee is in a price range as if it offers a basic client - fullscale single server backend solution, sadly with only offering a network library at least at the time we evaluated it. The license costs have been mentioned on the board in the past by Paul, precise quotes can be gotten from them directly.
ENet does not exist for .NET, but we considered lidgren at a point as it is similar. But its .NET focus in the end made it a no-option again.

 

Dreamora said some of them.

In my previous life, I tried to implement a complete J2EE based backend with webservices. While I somewhat succeeded, it showed me how big a job it really is.

SFS is cross platform (on the client side), its battle proven, it scales, it is very easily extended (in the pro version), and it is not "just" a protocol layer. It actually has existing starting content. On top of that, the price is very fair - I have spend man-months coding my previous backend system. Even the largest SFS Pro license is way way cheaper than that.

So thats some of the main reasons for me to pick SFS.

I looked at some (wont call it evaluation), and picked SFS from the bunch. Mostly because its used heavily in the flash game community - with some of the flash portals even hosting SFS servers for the game developers to use. Additionally I knew several people who used it, and could put their thumbs up.

I urge you to do your own evaluations though - SFS is a tool like many others, and you should always use the right tool for the right job. Specific requirements or game types can make the choice for you. For some its the build in Unity networking, for some its Netdog - and for some its SFS.

/Thomas

 

Thank you guys for your great explanations.

indeed, i was browsing thru SFS site and got to see all their features, great stuff.

Also looked at Paul's thread about netdog here at unity forum, and looks like a great option for mmo, but back to reality, well at least myself as an indie dev. it will be kind of hard or nearly impossible to afford their great technology without any major help of funding resources, and I see why SFS come right into place, at least its pro license is 10 times less expensive than netdog. so this makes it more reachable to indie devs.

Now, since SFS is TCP, I think this will be great for FPS type of games right?

But if you want to create an RPG type of game, I have read that UDP will be the best way to go , am i correct?

Besides this, what other type of games or genres will be good using SFS?

I not sure if the above TCP or UDP is correct, since like I stated on my first thread I am kind of noobish on networking and trying to get my feet wet on this interesting area.


Regards

 

Ahhh - without writing a book about networked games, the short version is that UDP is prefered for FPS type games. One of the reasons is the lower overhead on the packets. Lower overhead = less bandwidth

The disadvantage is that you can loose packets in transit and also get them in the wrong order (amongst others), and need to code various mechanisms to work around this issue.

These days with everyone (almost) having huge connections at home, the argument isnt that big anymore in my oppinion. But if you have a MMO with thousands of players, then you certainly want to have lowest possible bandwidth on the server side simply due to (usually) paying for traffic in/out of the datacenter.

In general SFS is used best with turn based games, point and click games (a lot of MMO games use this mechanism) - and less with first person shooters. While possible to do in low numbers of users, I would definitely do some performance testing if you require hundreds of FPS users in the same scene. But in those cases we are already way way out of indie budgets and it is a science in itself to get your game to perform under those circumstances - not only the server technology.

The place where I would possibly be careful is running physics simulations over network. Here I would do some feasability studies on Unity networking instead. Having tried to make an online flight simulator - here is my advice: never ever try to run a physics simulation on both client and server side....... No matter what you do, it is very very very VERY hard - even with Unity. Just dont - run simulation on one or the either, but never networked.

/T

 

Thank Thomas,

Those are great points you made, no wonder large scale mmo games outhere use UDP to minimize bandwidth.


Thanks for the advice on networked physics, indeed i have heard pretty bad experiences on running physics on server side.


When you mentioned SFS is best for turned based games, point and click games.
what exactly you mean by that?
excuseme for my ignorace but can you provide examples of point and click tyle of games so i can get the idea.
Since I would like to use SFS, I would like to plan which game will be best to work with SFS.

Thanks in advanced.

 

Just on a note about the physics thing. The Source Engine/HL2 is a good example of this. Me and a genius fellow called Justin Krenz made a mod called Empires for this game, that was a hybrid multiplayer FPS/RTS. The first release was slow as all hell, and while I can't pretend to know all that was going on behind the scenes, several things were done that both reduced bandwidth and drastically improved performance, including physics:

-Radius-based updated.
-Physics, where possible, didn't affect gameplay (didn't collide with the player).
-Only start and end points were updated from client to server. This was especially useful for ragdolls. We had a thing where an engineer could revive a dead player, and with ragdolls, where the player ends up could be different from client to client (because it's a clientside calculation and we wanted to keep it that way). So i'm not sure how it was done, but once the body had settled, there was the same end position across all clients. It could look stupid because to you he'd appear to be somewhere and then shift a few meters over, but it was the only solution.

I'm sure theres a lot more going on that was optimised, but in general, when it comes to networking, you have to think of how to do something with the smallest footprint possible. Anything involving shooting a player in the head - consider a hit chance % rather than a physics sim, etc.

 

Turn-based is the opposite of Twitch. In twitch games, you shoot at someone, control your vehicle, whatever. You're not following something that can be predicted and you require the results of those actions immediately. A turn-based approach means you're following rules. You click on a player, then press a button to throw porkchops at him, the server works out based on math how much damage you're doing to him. It's a slower, more logical client-server relationship.

With a twitch game, it's all about predicition and dirty tricks to get things back and forth as fast as you can.

 

Turn based games can be anything from classic turn-based like chess (and all other tile based games) down to games like World of Warcraft.

WoW and a slew of other games implement the "click button to make things happen" method - at least from what I can deduce. You e.g. click on a button to throw spell X. That sends a single command message to the server, verifies its OK and returns a "you are allowed to cast that spell". Notice how the animation of the spell is already started on the client, but no damage yet applied. Thats the waiting period where the server has to verify that you are not cheating. Once you get the OK from the server onto the client, you can play the real damaging animation, as well as show the damage applied. The entire battle scene plays on the client only from my guess - triggered by a single command sent to the server. Very bandwidth friendly and also in the category "turn based" when I talk about it here.

The opposite is first person shooters, where there is a constant stream of transforms being sent back/forth between clients and servers, where you need to implement lots of things like predicition and interpolation to keep things in sync. Those kind of networked games are an art in themselves to get running and scale. And thats where you either cut down the number of simulatnious players - or employ heavily optimized protocols that you can buy from someone - e.g. netdog and others.

/Thomas

 

Ahhh, I think I am getting the idea, it kind of makes sense now, specially with the WOW example.

But, Still confused with the connection protocols:


TCP is proven to be a reliable protocol since the packets are received in the same order as they were sent, if one pocket was not received it will be resent until received propertly, but the downside of it will be thet the last packet wont be proccessed until the previous one is received, in most cases is good like for chat/voice, but for the rest, specially if a large of simultaniously connections will create a big problem therefore the lag issues. and ofcourse the bandwidth overhead.

Last I heard WOW uses TCP, which makes sense with their large volume of players that has constant lag issues, and what about the player position packet updates? wouldnt it be even worse if packets dont arrive and the last update wont process until the previous one is received then you will see a very bad player position lag. ofcourse if the server is well balanced then it will be no issue at all, specially TCP will be best for example no pocket loss if a player loots an item, the item will still be there, compared to UDP, if a packet is lost and this happened when looting an item, then this will create an issue.

Some say UDP is best for large scale multiplayers since UDP can handle larger connection since there is no solid connection and some say TCP is better because of the reliablity, but the problem is the bandwidth overhead like you stated before.

Some devs build their servers as a hybrids to overcome this issues.


But offcourse, we are talking about WOW, this is a fenomenum, in most cases we as indie devs or at least myself if I ever build a multiplayer game, with a few hundread symultanious players connections will be enough and I think TCP, in this case SFS will do the job nice and smooth.

 

Fully agree on the TCP points

And should the position updates ever require UDP and some lower latency / drop old packet methods: SFS is java, its not like Java and .NET do not offer UDP sockets, is it. As an MMO requires a server side extension anyway for syncronization range, its not an exactly large step from there to UDPed position handling. And position / transform handling is likely the only thing that might require to be UDP in a common persistent online RPG (anything with less than 10k concurrent players out of my view does not qualify for the MMO part, so I call them PORPG, which is more realistically representing what it actually is)

 

On another subject - can I write the server extensions in C# or am I limited to js, as, py? In other words, is the Unity/C# API just for SmartFoxClient ?

 

yes, unity api is only on the unity end.
Server extensions are restricted to AS, JS, Java and py unless you do a lot of work to link in C# in some way (not worth the effort, java isn't that different)

 

Veeeeery good question!

The short answer for all you artists out there - no!

SFS extensions by default are only supported with java, actionscript and python. Java being the preferred one, as SFS is a java application server. The other languages are slower in execution.

The longer question - yes. It is possible with some code grease.

The formula is to use mono to start a standalone "extension" written in C# and using my API to connect to the server - and then have a java extension being a bridge server side. That way you can tunnel all regular client <-> extension communication to the mono extension and back again.

We have a complete framework that we might sell later that allows you to have 100% the same game logic code+data models locally in your Unity game as well as on the server side. Totally transparent from the actual Unity game client logic. But thats a different story.

/Thomas

 

Yes, but then you can't use Terracotta, and for me that's the main reason to choose Java for server logic.

(I'm assuming here we're talking about a game that would actually need scalability. Something small might not, so maybe Terracotta isn't a factor in that case.)

 

Well, you say that WoW is a point and click, but there is also movement using the WSAD keys.

Is an fps really that much more server intensive than an rpg with WSAD movement?

Just curious, because I am fairly new to all of this.

 

Seriously more demanding.
1. Its low latency. Shooters require <= 100ms latency, better 50ms, that means that your server simulation layer needs to run at a far smaller intervall than an MMO RPG one would where you target for 100 - 200ms latency

2. FPS also require a far larger amount of server side collision logic (and related to that interpolation and extrapolation logic that is zone wide consistent)
MMO RPG only require bounding box collision or the capsule collision for target selection. FPS requires animated polygon collision or requires a larger amount of capsule coliders attached to the skeleton to register hits.

3. You will likely have more than just submachine gun weapons so you will also have really flying projectiles like rockets etc which add further network traffic.
MMOs near never have physically collideable projectiles. They are shot and either homing or go straight. but their hitting and damage is all precalculated by math, not by player "targeting skill" (there were slight spinoffs of that for example in tabula rasa which had click ability execution. that meant you had to click your target similar to a shooter to execute the ability ie weapon. But other than that it was pure MMO style damage and hit chance calculation as well)

 

oh, wow. thank you for that explanation dreamora. I didnt realize there was such a huge difference.

Thank you for clarifying.

 

Hello all,

I read all your messages in this topic. I just have some questions that I did not find the answer neither in SFS web site or here:

- I know SFS can handle 500+ connections. But with unity API, is it tested? I mean, the speed of connections between player, was good with how many players?
- I saw about the phisics system and how hard could be... but using the phisics of Unity will not be enough? I mean, from doing in the client side?

What I need to do:

I'm still learnning Unity, did some small tests already, so far so good. I pretend to use Unity and SFS for one of my jobs atm.
I used other engines in some small games and now I think Unity will be the best choice for me.

I need to make a big place (like a big store, or a big room) that can handle 1000+ users in the same place (instance). The game itself will be simple: the user can walk and chat, thats it. So far, as I read, SFS can handle this. The GM needs to be able to control all players if want to and some players can have special skills (like going to other places). Simple for an MMO game.
My client want this to be achieved in no more than 1 year. I'm used with programming, so I think to learn Unity will not take more than 2 months, and SFS no more than 1 month.

Do you think SFS and Unity is the best tool for this job?

Thanks in advance.

 

In the SFSIslandDemo example, I had a difficult time since it appears that the zone variable is set to "SimpleChat" sometime after the initialization of the code.

I changed the zone variable at initialization to "TestServer" for my own test. It connected, but couldn't log in. I ended up using simple print statements to find out that even though I initialized zone to "TestServer", it had been changed back to "SimpleChat". I searched everywhere to no avail, so I'm assuming that it does this somewhere in the dll. I had to add another line to finally get it to use the correct zone before logging in.

Let me know if there is something I missed. Otherwise, it's been a pretty easy example to do some quick testing within my own SFS development. Thanks!

 

Hi

You should change the zone in the Unity inspector and not in the script. The variable is exposed as public and thus the inspector settings override the script value.

Thats at least my guess at what your problem is.

login scene -> Login GUI -> Zone

Best of luck!!

/Thomas

 

That was it...once changed in the inspector, it's good. Thanks.

 

Those are some pretty stiff requirements. I believe only a few games actually handle that many concurrent players where synchronization is an issue, EVE being the largest. WoW, the largest MMO doesn't deal with nearly that many itself since the servers are sharded and fill up with 2000-2500 players per side (horde/alliance), closer to 5000 total on a server.

By that definition WoW probably wouldn't be an MMO since it edoesn't need to deal with players across servers with the exception of battlegroups for battlegrounds/arenas and those are actually just instances anyhow. Even consider a server/shard in wow-speak, each virtual server is still split up between multipe instances - such as Kalimdor, Eastern Kingdoms, Outland (including Exodar/Silvermoon), and Northrend.

You will notice from time to time that a particular sub-server will crash while the others on that world server (virtual server I guess you can call it) will still be up and running. Even though the worlds are able to hold around 5000 people each, if they all go into the same locales, the particular regional server (example around Ironforge for a demonstration) will crash and has done so in the past. That's with one of the largest MMOs in the world. EVE is actually really amazing in dealing with these issues since they really are dealing with all those players on a single cluster.

 

Great! Looks like a good multi user solution!

One Question though: After installing java and the SFS Server the IslandDemo says "Connection lost/No connection to webserver".
The Flash examples are working fine.
I tested with an external Server as well but the same result.

Do I have to configure something special?

Best Regards
Jo

 

Hi

All you need to do is to change the IP to your server if it doesnt run on the same machine as Unity. I dont have it open right now, but I think I exposed it in the inspector for you to change.

/Thomas

 

Hi Thomas, thanks for the quick reply

I did one Test on the same maschine and one test on an external server (ports open, correct ip, etc).

The Flash examples worked well, so I dont think, its an connection problem.

However the IslandDemo does not work. Later at home I can test the other Unity examples on a Mac, lets see...

Greets
Jo

 

Sorry, I didnt recognize that the "lite version" of the SFS doesnt work with unity.

Now I installed SFS Basic and all works fine!

Great solution! Time to play,

ByeBye
Jo

 

Dear Thomas:

I've problem with CreateRoom(), too.

I've add your code here into SFSIslandDemo, but it still could NOT work:

My code is here (to CreateRoom() in "simpleChat" zone after connect session):

Code (csharp):

1.  
2.     /************
3.      * Callbacks from the SFS API
4.      ************/
5. void onCreateRoomError(string error)
6. {
7.     Debug.Log("onCreateRoomError: " + error);
8. }
9.  
10.  
11. void onRoomAdded(Room newRoom)
12. {
13.     Debug.Log("onRoomAdded: " + newRoom.ToString());
14. }
15.  
16.  
17.     void OnConnection(bool success, string error)
18.     {
19. SFSEvent.onRoomAdded += onRoomAdded;
20. SFSEvent.onCreateRoomError += onCreateRoomError;
21. SFSEvent.onDebugMessage += OnDebugMessage;
22.  
23. Hashtable newRoom = new Hashtable();
24. newRoom.Add("name", "testNewRoom");
25. newRoom.Add("isGame", true);
26. newRoom.Add("maxUsers", 2);
27. newRoom.Add("uCount", true);
28.  
29. Debug.Log("Create New Room");
30.  
31. smartFox.CreateRoom(newRoom);
32.  
33.         if (success)
34.         {
35.             SmartFox.Connection = smartFox;
36.         } else {
37.             loginErrorMessage = error;
38.         }
39.     }
40.  

After login, CreateRoom(), there was nothing happened. No new room created, No any error message.

And I could still land on Island after JoinRoom() into "The Garden".

I had using AdminTool of SFS, and could NOT see any new room created either in login session, nor join room session.

It's so hurry to me, would you please help me?

Thank you very much.

 

I somewhat fail to see the points people are making about UDP and TCP here. Those are both, as Thomas puts it tools.

UDP (User datagram protocol) provides a facility to unreliably send a packet of data. Unreliably means, if the packet is lost in transit, the receiver will never see it, and the sender wont know it was lost.
The advantage is, that its fast.
If you send several UDP packets, you also cannot rely on them arriving in the same order, and unless you provide your own functionality for it, you cannot reorder the packets correctly on the client side.

TCP (Transmission Control Protocol) provides a facility for sending a sequence of packets, ensuring that all packets arrive, and that they arrive in the correct sequence. Disadvantage is that it is slower than UDP.


So, why is UDP preferable for real-time intensive applications (such as movement updates in FPS's) ? Because most packets actually DO make it through, and because packets generally DO arrive in the correct order, and because fps'es can relatively easily be coded in such a way that its OK to loose some of the information. If you need to resend a package, you'd rather drop that package and send the updated information anyway.

Why is TCP preferable for data intensive applications (such as e.g. web or mail or chat) ? Because with data heavy applications, it matters ALOT to get *all* the data, and get it in the right order.

So, what should you use in your game ? I'd say TCP, unless you really know what you're doing, in which case you want to use TCP for most of your stuff, and only UDP for really latency vulnerable stuff. So, it's not so much "TCP FTW in RPG !". Its more about using TCP for e.g. chat, maybe for combat comands etc, and using udp for movement updates. it's not like the two are mutually exclusive. Of course, your application needs multiple sockets then.

 

You saying in mixing TCP with UDP sometimes?

I read in somewhere that this is really not recomended, dont know why. Is that true?