Badlogic Games

Today we celebrate our 100th sale of Newton on the Android market. We released the full paid version last week and are pretty happy with the outcome. As stated earlier the paid version is more like a “support us by buying us some beer” version and it seems to have worked out.

Out of the 100 sales 11 have been cancled. At a price of 0.99€ that’s a pre-tax income of 88,11€. Now here comes the fun part. Google takes away a bit for it being an Android market app as well as for doing the payments via Google Checkout. So how much does that leave for us in the end? 56.59€. Yes. The taxes make up around 35%. Pretty hefty. On top of that i have to pay my tax department a little (as long as i stay beneath 700€ per year i’m luckily not obliged to pay taxes). Oh well, becoming rich and famous is probably out of reach anyway

Thanks to all the people that bought the 0.99€ version. We really appreciate it. Another shoutout to the soul that just donated 5$ to our efforts on other stuff like libgdx etc. via paypal. We’ll drink our beers thinking of you guys

Today i updated my Nexus One which i received from Google for being awesome to Froyo. I followed the process described at http://www.androidpolice.com/2010/05/22/breaking-nexus-one-users-download-your-froyo-here/ which went pretty smoothly. I had the stock ERE27 build and didn’t encounter any problems. The performance increase is really pretty nice. Flash works reasonably well altough probably 80% of flash games out there are useless on a keyboardless device such as the Nexus One (like Manufactoria ). I’m happy to report that libgdx runs without problems on Froyo as far as i can tell from my (limited) test cases. The only thing that doesn’t work is the frame buffer stuff, i’ll have to look into that sometime, it’s not a priority at the moment. Newton is not build with libgdx. Here’s Newton on Froyo:

Fuck indeed. Seems like the text rendering is borked on Froyo. I’ll fix that this weekend using libgdx’s text rendering module which works without a problem on Froyo and other Android versions.

On a related note: i included the patch that Olivier send in earlier this week. Thanks again for your efforts, much appreciated. You can get the fixed sources from the SVN repository or wait for the weekend for the next libgdx (bugfix) release.

Google Analytics tells me that a lot of my traffic comes for searches on the topic of onset detection. To make things easier i now put them in a new category called onset detection tutorial. Hope that is more convenient now. Also note that you can reproduce all of the tutorial code with libgdx if you want to do that stuff on android.

It’s not often that i find a game that keeps me playing for more than 10 minutes. Today i stumbled across Manufactoria, a flash game by Pleasing Fungus. It’s a finite state machine/semi-Turing machine game where you have to essentially accept certain string by constructing a machine that checks the string. It’s highly adictive for programmers and even for non-programmers (Stefanie made it up to the Androids level at the moment ). It’s also a nice way to prove that not all you learned at univeristy is lost. Here’s a screen of my solution to the dreaded Androids level:

You can play the game at http://pleasingfungus.com/. It’s awesome, i challenge you to construct a smaller solution for the Android level (20 parts, 0:28 runtime).

I’m more or less happy with the badlogic games logo you can see to the right. However, i don’t have a logo for libgdx. I’m a shitty graphics artist and don’t have the slightest idea how to do that (i did the badlogic games logo but that was shear luck and some cheating). So, to anyone out there who feels like it: create a logo for us either for badlogic games or for libgdx or for both. All i can offer you in return is a life long free pass to all of your games (which is not a lot i know). Maybe someone finds it to be fun enough to do it for the honor . You will at least get credit everywhere we put in credits.

So today we go a little bit web 2.0 by adding a plugin so you can share our posts on other sites. Yes, spam! I love how the new button in the bottom of each post adds to the overall ugliness of the site

A couple of weeks a go i had a beer with an old friend of mine. He’s a pretty talented programmer as well as graphical artist. We started brainstorming over some beers and came up with a couple of game ideas which we might implemented together (he’ll take on the artistic side, i do the coder monkey job).

We are not yet settled on what we are going to do yet, but for me there’s a clear winner already. Back in february i did a lot of research into onset detection, culminating in a tutorial which you can find on this blog. I love music and i think a music driven game would be an awesome thing for Android, more so if you can use your own music. We will definetely not do another Audiosurf and we’d also like to get away from the standard Guitar Hero formula. We are not yet settled on the final game design, far from it but hopefully we can come up with something more original. In case we don’t it’s ok too i guess

In any case, i decided to document the development of our next game here. I hope this will give some insights into the development process, maybe get us some followers as well as input from you out there. We are in no hurry so development might actually take some time (months).

Update: so that’s how that’s handled over there http://www.jmonkeyengine.com/forum/index.php?topic=13854.0. Ridicule and “i couldn’t find any contact info”. The thing is that if it was about getting into contact a simple google search for libgdx would have brought them to the site. Additionally there’s a big fat link on the front page of the google code site to this blog. Idiots.

Really, in this day of age how hard is it to compose an e-mail to someone you’d want to get in contact with. The JMonkeyEngine guys seem not to have heard about that yet. So instead they posted defects on the bug trackers of libgdx and gl2-android over on google code. Here’s the text of the “defects”:

Hello,

(@badlogicgames: you might have noticed me posting on the gl2-android
project as well)

I am not a robot, but I suppose for the purpose of this visit I might as
well be. I just wanted to drop by real quick to check if you are at all
familiar with the jMonkeyEngine project. It seems our projects might have a
thing or two in common.

http://jmonkeyengine.com/blog/blog/2010/02/10/android-support-confirmed-

for-jme3/

http://www.jmonkeyengine.com/forum/index.php?topic=13176.0

http://www.jmonkeyengine.com/forum/index.php?topic=13217.0

We are on the lookout for an Android developer to help us bring jME3′s
preliminary Android implementation to a mature, fully functional state.

http://docs.google.com/View?id=dhkt6vsf_251c54bg9hp

Maybe you could be that developer? or, maybe you know someone who might be.
Naturally we’d also appreciate having more testers or plain Android-savvy
people around in our community. Any reason at all for you to contact us,
feel free! Contact information can be found in the docs link above.

Thanks for your time,

~ Erlend Sogge Heggen

If you want to spam then do it somewhere else. The bug tracker is really not the place to do it.

Their efforts to bring their engine to Android is nice though. I looked at the engine a few years ago when it was in its infancy. It seems to have developed quiet a bit. I’m not a big fan of scene graph engines though, for most of my games that’s just extreme overkill. Their current android port seems to have a few problems, but once they are resolved it might well be a valuable addition to the tools available for android game developers.

See, free advertisting for you, suckers!

I was looking over some collision detection code today which can be found at http://www.peroxide.dk/download/tutorials/tut10/pxdtut10.html. It’s the old flawed collision detection code adapted from Paul Nettle’s description. It does not work for border cases, e.g. some stair configurations and so on. The funny thing is that there’s an improved version advertised on the site which is equally flawed. The big problem with the improved version is that it does not gracefully handle cases where the sphere already intersects the plane of a triangle at t=0.

Now in my ongoing quest to find a proper collision detection method i stumbled over this old flipcode COTD. The author explicitely states the problem of the Peroxide/Paul Nettle approach and provides a self-contained implementation of a different approach (which looks an awefull lot like the improved Peroxide version at first glance). I might at some point port that over to java and see how it works out.

Another approach based on Voronoi regions by David Eberly can be found at http://www.geometrictools.com/Documentation/IntersectionMovingSphereTriangle.pdf. This is a pretty new article created in march this year and might be a bit heavy on the math for some people. The idea is pretty neat and the implementation seems to be straight forward.

Oh well, if only the day had more than 24 hours.