Just to take what Justin posted a little further perhaps, here is the
latest email response I received from Scoreloop:

"It's completely free. Our Android API (Core Social) is completely
customizable and allows you to make calls from directly within your
games' UI (In
fact, it doesn't have it's own). The product that does have it's own
UI that
developers can easily (our Standard SDK) is only available for the
iPhone. There has
never been a fee for either of these products.

You're also correct that we do offer professional support to
developers integrating
Core Social, though we do not charge for this either. It's in both of
our best
interest that our features are well integrated.

And just to complete the story: We can license our tech for free
because there is a
rev share on the virtual currency used in Player Challenges (if a
developer decides
to integrate this feature)."

partnerships [at] scoreloop [dot] com for more information.

On Mar 18, 2:50 pm, Kevin Duffey <andjar...@gmail.com> wrote:
> Shaun, yah.. saw that too. No big.. so it looks like its limited on Android
> at this point. They provide an iPhone SDK which means you're dependent on
> their SDK code working correctly with their service.. and as well if they
> change/update their service probably have to update the SDK and possibly
> rebuild your game with it. Not sure their policy on supporting older
> versions of SDK/apis.
>
>
>
> On Thu, Mar 18, 2010 at 11:37 AM, shaun <shashepp...@gmail.com> wrote:
> > @Kevin
>
> > About Scoreloop, I just tried to access their SDK for Android and here
> > is what is listed:
>
> > "Android SDK
> > Core Social for Android is being released to a first group of
> > developers. If you're interested in early access, please email
> > partnersh...@scoreloop.com"
>
> > On Mar 18, 2:41 am, Robert Green <rbgrn....@gmail.com> wrote:
> > > Kevin,
>
> > > First of all, let me clarify some numbers:
>
> > > Your average EA game costs a lot more than 10s of thousands of
> > > dollars.  I bet no iphone port of any game cost them less than 100k to
> > > do.  I wouldn't be surprised if they spent 100k-500k on an iphone
> > > version of an existing title.  They deal with games that go into the
> > > millions in development cost.  How much does it cost to pay a staff of
> > > 25 for 9 months to develop something?  Even at a modest 50k per person
> > > (which is reasonable for a junior level artist dying to make game art)
> > > you're looking at around a million dollars.  That's a normal size
> > > staff and a very conservative timeline for a big title.  They're also
> > > difficult to compete with because of that.  It's harder for us to put
> > > together content that people won't scoff at.  Just the other day I got
> > > a comment saying that one of my games looks like it took 2 weeks to
> > > make.  That's after 6 months of development.  How much is 6 months of
> > > your time worth?  At my last job, that would be around 50k.  One could
> > > say that the true cost of developing that game was then 50k.  I won't
> > > recoup those costs, but I think that over the course of releasing my
> > > next few games which are far nicer than anything I've ever done before
> > > (partially due to my experience from working on past games and the new
> > > artist I work with) I think I'll get far better returns on future time
> > > invested.
>
> > > Also, being at the top of the market helps a ton.  It can really make
> > > a game, but take, for instance, Polarbit's last few games.  They got
> > > the market late and STILL nailed it (relatively speaking).  It's the
> > > games themselves... They brought a handful of high quality 3D games to
> > > a platform with very few, and people took notice.
>
> > > People (myself included sometimes) complain about how unfair the
> > > mobile markets are.  It's true to a degree, but when I see good apps
> > > and good games make breakthroughs, it reminds me that it's still
> > > really about the well executed idea getting strong word of mouth
> > > recommendations and making it.  It still works that way.  The problem
> > > is that as the market gets more and more apps and games, you have to
> > > make a bigger splash to get noticed, which takes more people and more
> > > time to do.  It's at that point that people complain that the gold
> > > rush is over.  I think that anyone who is here for a gold rush ought
> > > to just pack up there bags and head somewhere else now because I can
> > > only see those who are truly into what they do succeeding in markets
> > > like this.  We'll see people succeed and act like they are lucky but
> > > they really aren't.  Maybe they got some luck along the way but much
> > > of what makes people successful is a genuinely well executed, good
> > > idea.
>
> > > Build truly great products for an audience who actually needs or would
> > > really enjoy them and you'll do ok.
>
> > > On Mar 17, 10:54 pm, Kevin Duffey <andjar...@gmail.com> wrote:
>
> > > > I too am interested in how developers make money off of games... and
> > other
> > > > than the usual sell for .99 or ads in the game. By this I mean, unless
> > your
> > > > game is shown on the android market near the top, how do you either
> > avoid
> > > > your game going further down the list so as to most likely never be
> > found by
> > > > most people searching? I think that's the kiss of death, as some others
> > have
> > > > written about from time to time. When iPhone first opened it's store,
> > it was
> > > > ripe for new apps to make good money. Now, it seems very few apps make
> > good
> > > > money, enough to run a business around. I am amazed at companies like
> > EA and
> > > > even smaller ones that put a few games up each year... it must cost 10s
> > of
> > > > thousands in development dollars to make those games, and at a couple
> > bucks
> > > > a pop, I wonder if they ever recoup their costs, much less profit.
>
> > > > I see games even on Android with over 250,000 downloads, but how much
> > of
> > > > that is turned into money for the developer. At $3 a pop, some of the
> > > > defense games are really good, provides hours of fun, and worth $3, but
> > I
> > > > wonder if they've actually made $750,000 with their 250,000+
> > downloads.. or
> > > > if about 95% of that is downloads then returns a day later to avoid the
> > > > costs.
>
> > > > I am also very interested in how many end users (not developers)
> > actually go
> > > > thru the trouble of setting up an account to pay for things. I still do
> > not
> > > > understand for the life of me why google (and even iPhone) did NOT make
> > this
> > > > charge directly to the carrier bill. It's a clear way to make it super
> > easy
> > > > to get people to pay more frequently. I would actually buy $1 apps,
> > many of
> > > > them, if I could just simply be charged on my phone bill each month and
> > not
> > > > have the hassle of going thru a setup process, google checkout, etc.
>
> > > > I am also curious from another thread posted, with regards to games
> > being
> > > > able to do their own in-game charge process.. to allow players to buy
> > game
> > > > items, gold, etc using real money... or buying game money with real
> > money,
> > > > then using that to purchase game items, etc. Has anyone actually done
> > > > this... or is this completely against googles rules... and thus google
> > would
> > > > take down/ban the game from the market?  I know you can offer the game
> > via
> > > > your own site for download, and other sites that don't have quite the
> > rules
> > > > as android market, but just wondering if that is an actual issue.. or
> > can
> > > > games provide in-game patches, game packs, game items, etc and charge
> > for
> > > > them? It seems really ridiculous for google/android to prevent that in
> > my
> > > > opinion. It only helps solidify the platform that much more, especially
> > when
> > > > it concerns other avenues for developers to make some money off of
> > their
> > > > hard work. I think allowing it would bring more developers and a lot
> > more
> > > > apps to Android sooner.
>
> > > > On Wed, Mar 17, 2010 at 7:40 PM, Miguel Morales <
> > therevolti...@gmail.com>wrote:
>
> > > > > I'm writing a 2D MMO using realtime movement I can tell you that
> > > > > realtime movement can get very tricky.  Don't think that you can
> > > > > simply poll the server fast enough to grab all player locations.
> >  This
> > > > > may work fine in a LAN network, but not while the device is out and
> > > > > about.
>
> > > > > You have to take network latency into account.
>
> > > > > For the server end I use a Perl/Erlang system, data is stored in a
> > > > > PostgreSQL database however, data that is transient and requires fast
> > > > > read/writes I use Mnesia, an in-memory database for Erlang.
>
> > > > > The results so far have been phenomenal, I don't have to bother with
> > > > > JSON (although I love it.)
> > > > > Don't forget that that decoding things can take precious
> > milliseconds,
> > > > > so I find it better to work with bytes directly.
>
> > > > > Passwords are stored encrypted on the database and checked against
> > the
> > > > > POSTed password.
> > > > > Other than that, the protocol is sent as-is.  The reason is two-fold.
> > > > > One, the client doesn't actually generate any game information, it
> > > > > only asks for information, and it 'asks' if it can perform a function
> > > > > (i.e. move to a tile.)
> > > > > The only thing encrypting packets would do is lessens the chances of
> > > > > bots, but I want to encourage client development.
> > > > > The second reason is that I plan to open source the protocol to try
> > to
> > > > > get some other clients going with the help of other developers.
>
> > > > > This way the game is inherently cross-platform.
> > > > > I'm interested in how developers monetize from the games.
>
> > > > > On Wed, Mar 17, 2010 at 6:35 PM, mike <enervat...@gmail.com> wrote:
> > > > > > On 03/17/2010 05:05 PM, Bob Kerns wrote:
>
> > > > > >> Yes, SHA-1 is what you should go with. It's really a matter of
> > just
> > > > > >> requesting a different engine; the API doesn't care which one you
> > use.
>
> > > > > >> One thing to consider is that a salt doesn't prevent replay
> > attacks.
> > > > > >> If you want to prevent people driving up their score by replaying
> > the
> > > > > >> packets already sent, you may want to include a nonce in your
> > > > > >> protocol.
>
> > > > > >> I'd suggest using a secure random, and the current time, and
> > remember
> > > > > >> recent nonces, and reject anything that's either not recent, or
> > has a
> > > > > >> nonce that's been recently seen.
>
> > > > > > Ie, a Kerberos-like replay cache :) I sort of wonder how often
> > > > > > they actually need to send results up... if it's pretty infrequent
> > > > > > and/or not very intensive, is there a reason to just not use TLS
> > > > > > to deal with _all_ of these problems, and way more (like MITM
> > > > > > attacks, etc)? I know it seems heavy handed, but it's just a matter
> > > > > > of changing http to https on the phone side of things. The server
> > > > > > side would need a cert, but that's not terribly hard to come by
> > > > > > these days, and you'd get the assurance that strengths and
>
> ...
>
> read more »- Hide quoted text -
>
> - Show quoted text -

-- 
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

To unsubscribe from this group, send email to 
android-developers+unsubscribegooglegroups.com or reply to this email with the 
words "REMOVE ME" as the subject.

Reply via email to