Security on my game is pretty much handled by the userid that is assigned and the RoR backend. Unless you are decrypting the stream from the phone you are pretty much assured that no cheating is going on. And honestly its just a game. If the JSON is not formatted properly nothing is going to happen. If I can't find you in my DB nothing is going to happen.
On Wed, Mar 17, 2010 at 11:03 AM, Kevin Duffey <andjar...@gmail.com> wrote: > Hey all, hoping more will join in on this. I am curious from a few replies > on some things. > > First, for services like ScoreLoop, what does it cost, as a game developer > to use? I found an apple only service called OpenFeint that used to charge > but apparently is no longer charging. > > As users of services already out there, not sure for Android anyway, but it > seems for iPhone you have to use their SDK to access their service. What is > it like, if anyone has used service SDKs, to use? From the few snippets I've > seen it seems like there is a bit to do to make it all work. > > How about security? As a developer, do you have to get some sort of API > key? Is it done over SSL/TLS, or both an API key and SSL/TLS? I am wondering > how invovled the process is to get set up to actually use one of these > services... or for those of you that wrote your own, what do you do to > ensure it's your game calling the server side, and not some hacker or > another game trying to use it for free? > > And an off topic question.. I see more and more people talking about > getting a free phone from google? Is there some place you sign up to get > this? I'd love to get a Nexus One to test on... sounds like some people are > getting just that.. a free phone to test on? > > Thanks again all. More to come I hope. > > > On Wed, Mar 17, 2010 at 10:37 AM, Justin Giles <jtgi...@gmail.com> wrote: > >> Just to throw it out there... >> >> There's also Google Apps Engine: https://appengine.google.com >> >> It's java or python based (your choice). The free quotas are rather >> generous. I keep my high scores stored there for my apps and for one of the >> apps I have over 75000 active installs and I have yet to go over the free >> quota. You do get charged if you go over your quota, but the rates, in my >> opinion, are reasonable. Same basic idea as the MySQL and Rails >> suggestions. >> >> No, I'm not a Google fanboy, but with a free device coming sometime soon, >> if Google asked me, I'd sheepishly say yes sir, yes I am a fanboy :). >> >> Justin >> >> >> On Wed, Mar 17, 2010 at 11:25 AM, Robert Green <rbgrn....@gmail.com>wrote: >> >>> Since no one else has responded I'll talk about what I did, though I >>> haven't gone cross-platform yet (which is why I didn't respond right >>> away). >>> >>> I chose cross-platform technologies just in case I ever wanted to and >>> I know that they will work for it. What works well for me for my >>> leaderboards and turn-based multiplayer code is to use Ruby on Rails >>> with JSON as the encoding. It's supported natively by rails and >>> Android comes with JSON parsing and encoding. It's such a simple >>> protocol that one could easily write an encoder/decoder for any >>> platform, though I don't think you'd have to because I'm sure one >>> exists for almost every one. >>> >>> There are many routes to go that will work fine, including having an >>> XML-based service. I'd stay away from things like Java Object >>> Serialization. That is not easily portable. I'd also stay away from >>> technologies like SOAP and WS. They are heavy and you want to keep it >>> light and simple usually on a phone and small server / high traffic >>> setup. >>> >>> >>> My first recommendation is to use Ruby on Rails / REST / JSON for your >>> basic server. >>> >>> How it works: >>> Rails runs either as a plugin to apache via Phusion Passenger or >>> standalone via mongrel/other server apps. >>> Clients make requests using REST, which means HTTP Get Post Put and >>> Delete which query, insert, update and delete respectively. >>> The requests and responses are encoded in JSON, which is a simple >>> encoding, human readable and extremely fast to parse. >>> >>> Advantages: >>> Any platform can implement a client for it. >>> It's very light and fast. >>> All of the necessary tech is inherent in rails and so this provides a >>> very low-resistance coding path. >>> Passenger (the apache plugin that runs RoR servers) runs great and is >>> easy to deploy and uses your standard web server. >>> You can actually easily run a game core written in Java wrapped with >>> the RJB (Ruby Java Bridge) - I do this for Wixel >>> >>> Disadvantages: >>> Another language to learn (though I don't mind working in it at all, >>> it's really kinda nice) >>> Doesn't handle native code well (if you have a game core in C/C++ that >>> you need to access, it's a little tricky with Apache/Passenger/Rails) >>> Is only good for scores/leaderboards and turn-based games. You can >>> only update as much as you can push HTTP requests and process >>> responses. It's not good for real-time games requiring faster than a >>> second or two turnaround, though it can handle scores and accounts for >>> them fine. >>> >>> If you want a cross-platform real-time game server, that's pretty much >>> what you need a robust game engine for. Most real-time games have >>> their own protocol and are inherently cross-platform because of that. >>> I'll be porting my engine this summer and designing it to be cross- >>> platform. Issues to overcome when going cross-platform are: Sound >>> handling, Image loading and processing (can't rely on your OS for that >>> anymore), Font loading and text drawing, How input is handled, How the >>> video context is created, Menuing systems, Networking, etc.. >>> >>> Basically you can't depend too much on any one convenience of a >>> particular OS and you kind of have to design the system so that you've >>> abstracted out the "connectors", that is, the input and output in the >>> form of user input in (touch/key/network/etc), sound, music, graphics, >>> vibrate, lights and network out. Each mobile OS will have a >>> particular set of hoops to get the connectors in. >>> >>> With that said, many people would probably rather go with a solution >>> like Unity who have made it their mission to handle as much of that >>> cross-platform overhead as possible. I believe you can run a unity >>> server and connect to it from any unity client. >>> >>> Hope this was a little helpful. >>> >>> On Mar 17, 10:15 am, shaun <shashepp...@gmail.com> wrote: >>> > We are considering the use of Scoreloop (http://www.scoreloop.com/) to >>> > add a social component to our games and apps. Since we have no real >>> > experience in that arena, I'll just leave this link as my >>> > contribution. >>> > >>> > On Mar 16, 8:08 pm, Kevin Duffey <andjar...@gmail.com> wrote: >>> > >>> > >>> > >>> > > Hey all, >>> > >>> > > I am curious how the various groups of game developers, primarily >>> mobile >>> > > (android in this case) and cross-platform (android/iPhone/facebook) >>> handle >>> > > storing high scores, achievements, and such as well as how multi >>> player is >>> > > done. >>> > >>> > > How does your game(s) access high scores, update the list, remove >>> them if >>> > > need be? The same would apply for achievements, and to a lesser >>> degree, >>> > > leader boards. >>> > >>> > > Are you using a service out there that you pay for... if so how much >>> does it >>> > > cost.. and do they provide some sort of java/objective-c SDK that you >>> can >>> > > just plug in to your code? >>> > >>> > > How do you dispaly high scores, leader boards, achievements, etc in >>> your >>> > > game? Do you provide your own web site with the same info, perhaps >>> jazzed up >>> > > a bit more or with more detail than your mobile game (due to limited >>> screen >>> > > realestate for mobile devices)? Do you provide a link to a web site >>> in your >>> > > game if they want to see things like high scores, achievements and >>> leader >>> > > boards? >>> > >>> > > I would also like to know what sort of things are most important for >>> your >>> > > games. High scores are so yesterday, so to speak. The latest craze in >>> most >>> > > games seems to be achievements and the ability to obtain extra items >>> for >>> > > your games, either by buying them, or earning them through >>> achievements, >>> > > etc. So what are some things you game developers would want to make >>> use of >>> > > in your game to add more appeal to your game, to draw in players for >>> longer, >>> > > especially long enough to pass the 48 hour refund time so that you >>> can >>> > > actually earn some money from your hard work. I look at games on >>> Facebook >>> > > like Farmville that are doing so well they are hiring more developers >>> at >>> > > good pay to work on it. I also look at games like World of Warcraft, >>> which I >>> > > play and got sucked into for a while, due to getting to that next >>> level or >>> > > getting that next awesome epic gear piece... those sorts of things >>> seem to >>> > > be what draws in players to otherwise simple games. A number of >>> mobile games >>> > > that seem to do very well often seem to be fairly simple games but >>> offer >>> > > that right mix of "I just got to get to that next...". I am curious >>> what >>> > > some of you developers have found work for games either those that >>> you >>> > > played, or are working on (or have written) that draw in players. >>> This leads >>> > > to the next paragraph.. making a living on game development >>> ultimately >>> > > requires that your game does well and that people pay for it in some >>> manner >>> > > and not refund it. Hence why I am trying to understand what it is >>> that those >>> > > otherwise simple games seem to do that draw in the masses. >>> > >>> > > Which brings about another topic.. how do games like Farmville make >>> so much >>> > > money being free games, that they can have a company behind it? I >>> can't >>> > > believe ads on the stie alone make up for all their revenue. I've >>> been >>> > > considering looking at ads in the game as opposed to charging for it, >>> and >>> > > that seems like players might keep a game longer than if they pay for >>> it and >>> > > then refund it within 48 hours if they don't absolutely love the >>> game... >>> > > although I am not entirely sure how much it annoys players to have a >>> small >>> > > portion of the screen saved for ads as opposed to just buying it. >>> > >>> > > Lastly, multi-player. I am curious how games work multi-player. The >>> only way >>> > > I can think of is the client (game) has to update a server of some >>> data, a >>> > > move, location of a sprite, etc, and at the same time has to poll the >>> server >>> > > often enough to update the game screen to keep things working. The >>> first >>> > > part of this, the game side, seems easy enough.. at least to some >>> degree.. >>> > > when your player makes a move, you send a server request to some >>> server with >>> > > the data, be it their new location, a weapon they selected, etc. The >>> second >>> > > part of this is the client polling the server often enough, fast >>> enough, to >>> > > keep things smoothly on the screen of all players. So how have some >>> of you >>> > > handled this and yet keep the game playing smooth as well? Probably >>> more >>> > > important is, the server side. Not necessarily the code bit of it, >>> but how >>> > > do you handle if your game takes off and you get 10s of thousands of >>> players >>> > > playing it... what sort of server side technology is used to handle >>> that >>> > > many requests, that fast, fast enough to allow all those game clients >>> to >>> > > provide a smooth game experience while keeping the multi-player >>> working >>> > > solid as well? >>> > >>> > > Thank you. I look forward to learning more about how these things are >>> done >>> > > in games. >>> >>> -- >>> 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<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<android-developers%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- Writing code is one of few things that teaches me I don't know everything. Make Call Girl Manager great! Join the forums. http://www.fuligin.com/forums -- 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
