And here we have some iTunes promocodes for iOS version for you:
KHR9P4PX3RFY
K9MWRLLMXKRH
LTKJM46T3E4X
XXH3A3YJAXLT
KPXWAYNLPMTP
NA4XKYLH376T
FFMWKPM6LJTN
KK96AHAPXW9A
3ETLFW37RJRE
3PPF7HX9YFXA
F4NTMMEPLXXP
FR7T4E49J44M
XLY9F766ARTK
J7TAPMYNT6NT
3KAR3TPJFNN7
EAWF6KN9YA3A
XN3M6JA7JNWF
APMP79EL9XWM
YKKMHPT7XYTF
ATHM7F7AMHF6
NL364AH6MPAY
JLLKLYNXWHMT
L7W7N9LKXA3R
EXKATMLPFLER
NN4K6MTL3YY7

Have fun!

It’s currently available on the android market and pending in a bunch of other places so I’m sitting on versions for windows, linux and osx. In all honesty I focused more on getting it ready for the igf (student edition) and less about scouting marketplaces.

“Is this the part where you tell us to buy it?” the crowd asks. Well yes actually: “Go buy it!” Or at least +1 it on the android market or tell your friends and family and that cousin George you haven’t spoken with since 3rd grade about it. Yes the one with the bigger thumb on his left hand.

Some of the features will roll out to the free (ad supported) version relatively soon (the updated graphics and music), while others will be kept a version behind(mostly new levels and such).

And here’s a trailer for you(can someone please tell me how to embed videos? the code just gets eaten up)

Thanks for reading

GAME PAGE

]]> http://www.ludumdare.com/compo/2011/10/30/urth-gets-submitted-to-all-the-things/feed/ 0 http://www.ludumdare.com/compo/2011/10/14/monster-match-alphabet-completed-and-submitted/ http://www.ludumdare.com/compo/2011/10/14/monster-match-alphabet-completed-and-submitted/#comments Fri, 14 Oct 2011 15:14:54 +0000 EgoAnt http://www.ludumdare.com/compo/?p=76190

Dream no small dreams for they have no power to move the hearts of men.
- Johann Wolfgang von Goethe

When I was younger that was the motto I lived by. Now that I am a bit older I am finding that there is definitely a place for small dreams. I’d say that small dreams are essential to my survival.

I saw the October Challenge 2011 page late last month and immediately start planning something awesome. I was going to use October to finally learn Flixel, put together something awesome, and submit my first app to the Apple app store. After a week I was still learning the ropes in Flixel, making random art assets for a new game that I hadn’t even finish the design on, and had yet to renew my Apple developer account.

It was time to take a step back and evaluate if maybe I had been dreaming just a bit too big for a 1 month project that was being done in between doing my full time job and raising 3 children under the age of 3. I dug down into my unfinished prototypes directory and found a match game that I had started building to get a free PlayBook from RIM. It was a simple match game that I had designed to help my son learn the alphabet (and distract him when he launched into a terrible-twos induced fit). It had fallen by the wayside because I had decided that I wanted to make an app for Empire Avenue using their API instead.

I converted Monster match Alphabet to an Android project so that it could be brought to market as fast as possible. Then I spent some time working with the art assets and made sure that it played fairly well both on small screens and on tablet sizes.

Some of the monsters in Monster Match Alphabet

Is it original? Nope.
Is it epic? No.
Will most people taking part in the October Ludum Dare want to play it? No.
Is it done? YES.
Will my son enjoy playing it? YES.
Is it available on the Android market? YES! Yes indeed it is.

Since there is still some time left in the month I think I might actually try to continue making some changes and testing with the Android version. If I can I’ll also submit it to the PlayBook and Apple app markets, too.

Overall I have to say that this October dare taught me a valuable lesson: sometimes it is better to achieve a small dream than to have an unfulfilled big dream.

• unfinished visual novel engine (android) – I believe I misplaced the source
• unfinished bullet hell engine (android) – Needs everything except the actual bullet engine
• LD21 entry: Urth - Needs about 2 tons of polish
• MiniLD29 entry: Redeye - Needs about 20 tons of polish
• Something completely new – no

Urth had a little head start on the android market, so I’ve fixed it by strapping beta to the end. How does that fix it you ask? Well it doesn’t really fix it actually, but I’m October challenging with the non-beta (gamma? ), which I intend to have for non-mobile platforms as well.

• never EVER hardcode menus ever again
• good coding practices aren’t necessarily compatible across programming languages
• having a deadline positively influences productivity
• next time use a real font and not gimp+a tablet
• some things just aren’t meant for 3D and fancy lighting

• reduced processor load
• improved the gui so it doesn’t look like it’s held together with duct tape and chewing gum
• replaced difficulty cliff with difficulty curve

Images:

Main menu: Merged two buttons and added a new one

The level menu now matches the main menu and has pagination

A sneak preview of one of the new levels

 COMPO ENTRY ~ IN THE MARKET

I’ve also used PhoneGap to compile my HTML5 + box2d source code into a native Android app and it runs GREAT on my phone with super smooth FPS.  Coming soon to an app store near you… =)

Anyone who made an HTML game, be sure to check out PhoneGap – you can compile your app to Android, iPhone, iPad, Blackberry, etc.  Completely free, open source goodness.

This means that I am “done” the low level engine and have the rest of the weekend to make it look pretty!

Click this image to play in your web browser!

Follow the adventure and friendship between two lonely young heroes. From humble beginnings, their partnership are all that the world needs to save them from an evil tyrant. Recruit allies and meet people and creatures along the way toward the boss battle.

This was created using art that I’d made previously. I created all the avatar art (cats, dragons and people) using Poser Pro 2010 and DAZ art assets. Most of the backgrounds were created in Vue 8.5 xStream.

I decided that my challenge for this weekend would be to build my first MOBILE game. Using Phonegap and jQuery, I created the entire game in HTML. Using Eclipse to compile a simple .java class, I packaged phonegap and my html sources into a non-signed Android .APK which is designed to be used on phones like the HTC Desire, or any Android 2.2 device with 800×480 resolution. It might also work on tablets and older phones as well. Because it isn’t a signed .APK, it is not yet ready for prime-time (it wouldn’t be allowed to go on the app stores, and you need to enable “debug mode” on your phone and “allow unsigned apps”).

For the Windows .EXE, I used Appcelerator Titanium to create a stub executable which is really just a chromeless web browser (using a variant of xulrunner).

For the web version, all I had to do was upload my HTML sources to my web server. The sound is done with soundManager2, which can use HTML5 audio but generally sticks with more reliable invisible Flash.

Although this is a very simple game right now – just some conversation and one battle – I am very proud of what I accomplished. As a tech demo for a future, more advanced RPG or visual novel, I think this is a great start. Perhaps I will flesh out the adventure, add a few more characters, implement game saves and inventory and a quest manager and craft a more robust RPG game like I’ve always dreamed. Who knows?

In any case, it was really fun working on this. Hope you enjoy it!

I now have a visual novel engine capable of handling multiple-choice scenes, can display jpg backgrounds and png avatars which smoothly fade in and out, can play mp3 music and voiceovers, and it all works on Win/Web/Android.  Now that the base code is there, it is time for me to actually work on the “game” part!  Whew!  I almost gave up on the sound and mobile parts.

I love that feeling when you’re so frustrated, about to give up, and you keep saying “I’ll just try one different method, maybe it will work this time” and at long last you finally hear your mp3 over the speakers and it is like a huge weight floated off your shoulders and you know: it was worth the persistence.

NEVER GIVE UP!  YOU *CAN* DO IT!

Here is my silly little game engine running on my phone:

This is not my first time, and I hope is not the last

Planning to use on this one the current beta version of  my framework that I started on LD15, that was made in Java, meanwhile I add Lua language to the mix, and support for android …  here is the link for this alpha version http://jaga.athanazio.com/2009/12/alpha-version/

for graphics inkscape and gimp

for the audio  SFXR e audacity

After my LD #11 ‘Minimalist’ entry was voted “most innovative” game, I’ve been trying to pride myself as “that guy that makes innovative games”. So I thought long and hard about the theme for LD #13, “Roads”, trying to come up with something innovative. But the creative juices just weren’t flowing, and it didn’t happen (I’d also just bought Shaun White Snowboarding: Road Trip for Wii, which was taking time away from ‘designing time’). After 12 hours, with no good ideas for a game I was actually enthused about making, I decided to make a simple Frogger clone – at least this way I could hone my Processing skills, and learn the ins-and-outs of Mobile Processing.

Some thoughts about developing for mobile devices

Turns out there is a whole “other world” of mobile development that I just hadn’t really thought all that hard about.

I’d assumed that the whole write-once-run-everywhere thing would have been done properly for Java on mobiles. J2ME (and by extension, Mobile Processing) would have some sort of smart abstraction layer that makes things behave gracefully across various phones … right ? Wrong. Not so. It has become clearer to me now why J2ME MIDIlet development can be a royal PITA: significant differences between devices – screen resolution and aspect probably being the most immediately troublesome. This will more than likely apply to Android powered devices too, which once they start arriving en mass with various random specifications next year. The Android SDK deals with heterogenous devices in a cleaner fashion, via seperate “resource files” (which looks like the J2ME Polish approach ??), but it still leaves the developer to make sure variations between devices are dealt with. The iPhone, despite having far less handsets out there in the wild compared with J2ME capable phones, has a distinct advantage for developers at the moment … you are essentially only targeting one device (okay, maybe two if you count the original non-3g iPhones, or three or four if you include iPod Touches). That said, no one would be silly enough to believe that future versions of the iPhone will have the same screen geometry and capabilities, so I think the problems have really just been ‘delayed’ for iPhone developers. It will be interesting to see how these problems are dealt with for something like, say, the iPhone Nano.

The Processing language for games

While Processing was designed as a language for coding visualizations, it has pretty much everything you need to make simple games; graphics (bitmap with transparency, vector graphics, even OpenGL 3D), mouse, keyboard and joystick input, and sound (samples, MIDI, basic synthesis, via the minim library, among others). Since it’s actually just a layer built on top of Java, you can also do some more advanced things by incorporating regular Java code, outside the scope of the simplified “Processing” language. Things like collision detection are missing “out of the box”, but rectangular collision detection isn’t tough to whip up yourself. The weakest link is probably the sound support, which seemed a little flaky for me – samples triggered via minim seemed to have some unavoidable lag (others have reported similar issue on the forums). Overall, I’d say its still a fair contender against something like Pygame for quickly mocking up little games. One advantage of Processing over Python programs is that stock-standard Processing IDE can produce executables for Linux, Windows, Mac OSX and a Java applet with about three mouse clicks, no matter which platform you are actually running it on. I searched but didn’t find a decent ‘game framework’ for Processing – someone (maybe me) should write one, since it could do with some convenience classes and functions.

Mobile Processing – what happened to my floats

Mobile Processing is very similar to the core Processing language, but it can export applications as J2ME MIDlets which can run on Java capable mobile phones. I started writing my game in Processing, then ported it over to Mobile Processing. One thing that is missing in Mobile Processing: the float data type. In my simple game, it wasn’t too hard to just change my floats to ints, and with a few tweaks to deal with rounding errors, everything worked okay. But if you need floating point calculations, there are some tricks to deal with arithmetic of fractional values. Mobile Processing is lagging slightly behind the recently released Processing version 1.0, but most of the function name changes are trival (eg, framerate() vs. frameRate() ).

The collision detection issue

A few people have commented that the collision detection in Badass Frog isn’t great. Well, that’s not a bug it’s a feature . No seriously, it started as a bug, but then I realized that it nicely gave the illusion of making the frog only vulnerable if it was run over by the wheels of the car. But, it probably doesn’t match the expectations of the player, and so feels buggy; lesson learned … cool ‘features’ (aka serendipitous bugs) may not be so cool if they don’t adhere to pre-estabilished conventions and just confuse/frustrate the player.

Conclusions

So, the game I’d produced after 48 hours was extremely basic, and probably not worth more that ~ 1 min of anyone’s time. I did deliberately tweak the difficultly so it ramped up quickly … I figured it was better to kill the player before they gave up out of boredom. As is always the case, I could have done a lot more with it (online high scores, the classic “river with logs” instead of just roads, bonuses ?), but instead got caught up in technical issues; playing with the sprite sizes / layout to get a version that could work on many screen sizes, and getting sound to work in the mobile version. The result was that I learnt a lot about the issues involved in developing for heterogenous mobile devices, but didn’t have much of a game after 48 hours. Summary: simple game, but learnt lots. I’m pretty happy with that.