Making the switch to uLink (as initially planned)

Hey all,

I've been working on a unique multiplayer flight game demo for a while with a small team. Our research showed that uLink would be the best choice for us and this is what we used in the beginning. However, certain factors including the departure of the main programmer to a large studio and the lack of solid understanding of uLink of subsequent programmers, forced us to scale down the demo and go with a non-authoritative, single-instance setup and use Smartfox instead, basically starting over.

This is ok if all you want is to get a prototype working in order to show potential investors. However, I strongly believe that we have something good going and should take the alpha-funding route - getting the game out early on to as many players as possible to play for free and contribute to further development costs by pre-ordering in-game packages. This greatly improves the chances of further funding if needed because there is a user base to show. This means though that we need to switch again to a different networking middleware solution like uLink because I don't know how far Smartfox can go. And perhaps the time to switch is as soon as possible.

What is your take on this? It seems really hard to find someone knowledgeable enough in uLink. Sure, there are a lot of requirements you don't know but the highlights are that the world is non-persistent, matchmaking will be automatic (no lobby needed), a database is used to store user profiles and in-game items but will need to be extended to stream asset bundles because planes are built from items in the database.

Nick

 

I'm a noob and I have only known about uLink for 24 hrs at this point, but from everything I have read in their manual and seeing how they setup their tutorial project I am convinced it is the correct solution for authoritative servers and really probably the correct solution for non-authoritative as well. Not to be rude, but if your programmers didn't understand it I would bet they haven't bothered to look over the tutorial game nor read the manual. It may be a different design pattern than they are used to, but I wouldn't call it difficult to understand. It is a very elegant solution imo. Granted, like I said I have only known about it for 24 hours so I have only had time to read the manual and look over the server side of the tutorial game.

Edit: Also, you can use uLink in a non-authoritative manner as well. With an authoritative uLink setup you have creator (server), owner (your player) and proxy (other players). The creator creates the network aware game objects, the owner asks the creator to do things like move his character, and the creator agrees to the action and tells the owner and proxies about the resulting state change (character position moved). I THINK you could temporarily go with uLink non-authoritative mode and essentially the owner would become the creator as well instead of going through the server and the owner would just tell the proxies where his new position is etc. Once you got a better handle on stuff like movement prediction, which I assume will be the hardest part of going authoriative, I THINK you could fairly easily refactor the code to have the server become the creator. That way you can use the framework you know you will ultimately need while temporarily using a solution that is a bit easier to accomplish.

 

You're most likely right about the programmers. Although this game does have requirements that even experienced engineers would find challenging like having to stream and reconstruct player planes using items in the player's profile in the database, treat them as one object while effectively managing camera, movement, shooting issues, movement/collision predictions and performance over the network. But would love to be proven wrong. Anybody finding this work intriguing and piece of cake let me know!

Thanks for the edit Fyndor. That may be the way to go to ge it rolling quicker.