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.
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?
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.
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
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.
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
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
void Start() {
Application.runInBackground = true; // Let the application be running whyle the window is not active.
smartFoxClient = GetClient();
if (smartFoxClient==null) {
Application.LoadLevel("login");
return;
}
SubscribeEvents();
started = true;
smartFoxClient.JoinRoom(Application.loadedLevelName);
Hashtable tempTable = new Hashtable();
tempTable.Add("name","guild_000001");
tempTable.Add("maxUsers", 500 );
if(tempTable == null)
Debug.Log("You will never see me");
smartFoxClient.CreateRoom(temptable); //<-- This will fail
smartFoxClient.JoinRoom( "testroom_000001", "", false, true );
// alternative
// smartFoxClient.JoinRoom( 11082, "", false, true );
}
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
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
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)
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:
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!
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.