Wow..where to start. First..I never heard of or looked up those servers you mentioned. But more importantly, exactly what do you need from the server side component for your game? Is it to keep track of player locations in the game world, store all their info, profile, achievements, scores, etc? Give a little more detail on what you plan to do.
As for doing your own server.. not knowing how as the above post said..it's not terribly hard if you know one of the server side favorites, like Rails, php, or Java. The main problem you face is.. where do you host it? If you run the server at your home.. you run into a number of issues. Does your ISP allow you to run servers (do they have a policy that says you cant.. do they run bots to scan all ports to see if you are serving.. etc). If they do allow you to, now you face the problem of using a static IP, a dynamic IP routed thru a service like dynDns or no-ip, or actually buying a domain name and assigning it your static ip (or the dyndns/no-ip info) to route to your server. Now once you get it to your server, you've got to worry about scale.. should you need it. If at all possible you want to remain stateless on the server side so that you can avoid having to worry about a user that has say a session (via cookie perhaps) on a server that goes down.. and loses any/all data they have that was not stored. If you got hundreds of users on a server like that..you're going to have a lot of pissed of players. So assuming you remain stateless, then you mostly have to worry about a load balancer (and that needs to be fault tolerant as well) to round robin between two or more servers as you scale up. But, that is all stuff you need to think about once you figure out if you're going to do your own server side. Remaining stateless a basic server with 4 core cpu and 16GB ram should be able to handle thousands of simultaneous player accesses.. depending on the data coming in on each request. As for the right "protocol" to use.. I personally prefer REST. It is the easiest thing out there to implement on the server side, and at least for Java, Jersey (bundled with Java Enterprise 6) is very easy to use. It even supports automatic conversion of json or xml into JAXB objects, so that you as the developer on the server side do not need to deal with xml or json at all. AS well, there is a java client library that comes with Jersey that can be used by clients to send xml or json by turning JAXB objects into xml or json, depending on the Content-Type heading. I am not sure about Rails, I've read that it's quite easy to do this as well. Being that I've worked within the Java server side for years and have been directly working with REST the past almost two years, it's a real pleasure to be able to work with and it provides a very solid and yet easy to use API for clients. Even better, you're not tied to one platform. You can easily make REST calls from Android, iPhone, Palm, Blackberry, and any other client side technology. If your game is doing well and you are interested in pursuing this, shoot me an email directly. On Tue, Jan 19, 2010 at 1:07 PM, Miguel Morales <therevolti...@gmail.com>wrote: > Hello Atif, > > I'm developing my own server for a multi-player game, so I think I can > weight in with a degree of 'expertise.' > To start off, I've never heard of any of the servers you mentioned, so > I'm not going by first hand experience, but rather from the > information they have on their website. So, please don't take > anything I say to be 100% true. > > Red5 - Seems overly complex for such a simple project. Do you need > streaming? It seems that's one of its main features. > It has java examples and bindings so that'll make coding the client > and server a bit easier since your brain doesn't have to switch > between Java and something else. > I don't see anything that would actually help in creating a > multi-player game, beside mapping data. > (That is, being able to send data from the android client and the > server being able to interpret it and something useful with the data.) > I really can't recommend this for any game development. > > Not to mention that there are no specifications as to how efficient it > is, or how low its latency can be. > > ElectroServer 4 - Seems to be primarily an ActionScript/Flash server. > According to the site: "The ElectroServer API acts as a liaison > between the game developer and ElectroServer – formatting and > initializing all transactions that occur between the client and the > socket-server." > > As you can see, this can add a significant amount of overhead/latency > if this formatting isn't done fast. > > "Flash clients written using ActionScript 3 gain even higher > performance and reduce message size further by using the binary > protocol." > So, for ES4, it seems using the binary protocol is the best way to go. > > It actually looks fairly simply and complete and just might do the job. > > SmartFox - Looks pretty stunning. Not to mention they had mobile > devices in mind when they made it. So that probably means the > protocol is efficient. > They seem to APIs in a lot of languages. (Say you want to port your > game to iPhone later.) This one seems to be the most recommend-able > off-the-shelf server. > > However, to me, java and high-performance/low latency don't go > together. But for your kind of game, it should be more than enough. > There's also nothing like having professional support for a > server/platform. > > Now, I'm not sure if you even need all those features, or if you > have/are willing to spend the money on them. > > I, like a few posters, recommend that you make your own server. It > really is a lot simpler than you think. > You can do it in php, perl, etc. It doesn't have to be a new-age language. > > You simply encode your data in JSON, send it to the server. > The server performs some basic database operations and returns back > data encoded in JSON. > > That's it, doesn't get much simpler than that. However, you'll have > to code a lot of the logic and be dealing with databases. (Which is > not a bad skill to have.) > > Android has excellent support for JSON. > > I say this because sometimes, it's a real headache dealing with > commercial products, specially if it's just a simple card game. Also, > you'll be keeping most/all the profits. (Depending on the server's > pricing scheme.) > > Scalability, yes it's an issue. But a lot of the time it's just an > issue of knowing how to break down your game rooms. > For example, you don't expect to have 200,000 users in the same room > at the same time, do you? > 200,000 players overall should be feasible using simple JSON. > > It's sort of hard to recommend something without knowing more about > your game, but I hope that helps you in some way. > > Miguel. > > > > On Mon, Jan 18, 2010 at 9:52 PM, Atif Gulzar <atif.gul...@gmail.com> > wrote: > > Hi All, > > > > I am developing a multiplayer card game. And currently looking for best > > server. I have R&D on three servers RED5, SmartFox and Elctro Server. > > > > RED5 is open source but you have to right midle tier for android to > > communicate with server. > > SmartFox has inherent Android support. > > > > Would you please share your expert thoughts or point me some other > servers. > > Thanks > > > > > > > > -- > > Best Regards, > > Atif Gulzar > > > > I ◘◘◘◘ Unicode, ɹɐzlnƃ ɟıʇɐ > > > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Android Developers" group. > > To post to this group, send email to android-developers@googlegroups.com > > To unsubscribe from this group, send email to > > android-developers+unsubscr...@googlegroups.com<android-developers%2bunsubscr...@googlegroups.com> > > For more options, visit this group at > > http://groups.google.com/group/android-developers?hl=en > > > > > > -- > http://diastrofunk.com, http://developingthedream.blogspot.com/, > http://www.youtube.com/user/revoltingx, ~Isaiah 55:8-9 > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com<android-developers%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en >
-- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
