Getting to other Platforms (iOS/HTML5 etc) - TouchAPi

General Discussions
#1

I’ve been asked a few times to describe how I’m getting legends of yore on to different platforms. The important part to me is to keep one java code base for the game. One set of feature development and one set of bugs. If something goes wrong it should go wrong everywhere - and the fix apply everywhere. It’s working out ok in this regard.

So, here’s a quick run down. I have a single simple API which the game (and my other recent projects conform to). It’s quite limited and thats intentional to cut down on the complexity when moving to different platforms. The javadoc for this API is here:

http://www.legendsofyore.com/doc

The API is implemented in a bunch of different technologies as shown below. The use of these compilers and SDKs, and the packaging of the applications is all wrapped up in a set of ant scripts. When I build a version I run a command like:


ant clean applet application android android-paid ios ios-paid gwt flex

And the distributions pop out in the target directory ready for upload to various appstores. Where possible I’ve automated the upload process too.

http://dl.dropbox.com/u/1668516/shots/TouchQuest/touchapi-small.png

Not sure what else to say about the implementations. I’m open to questions of course.

Status

  • Application/Applet/Android/iOS are working and have been released and selling ok ™
  • HTML5 version is up and selling, also available from Kongregate as of yesterday
  • WebOS version is built and I’m just sorting out the finer details of integration with the TouchPad (that HP sent me for free! :))
  • Flash version is in progress but I’m having some reasonably bad rendering issues

Limitations

  • Performance - it’s massively variable across the different platforms and techs. I’m only focussing on turn based or puzzle games, so it doesn’t worry me
  • Limited SDK - You can only use a limited Java SDK without implementing parts of the different platforms. I manage just fine and you can imagine legends of yore isn’t completely simple or small inside
  • Debugging - it’s hard to debug across all the platforms. Once it’s right, you only have to debug on one but getting there can be tricky
  • Platform Features - each platform has different features which are complicated what you support where. I’ve not limited myself but it might have been sensible to cut down the features to a core set
  • Costs - Commercially using the flash conversion stuff costs $99 a year. Android and iOS markets have their costs also.

Technologies

Links

The main game is available in several forms at http://www.legendsofyore.com
The HTML 5 version is live at http://www.legendsofyore.com/js
The in progress Flash version (don’t expect too much yet) is available at http://www.legendsofyore.com/flex

If anyone is interested in any more information, just let me know.

Cheers,

Kev

#2

You picked a project name that sure will be hard to find through google :wink:

Seeing as the Flash/Flex platform is performing significantly slower than the HTML5 version, I can’t help but wonder why you’re putting effort in that platform. I’ve never seen acceptable performance in Flex btw.

#3

It’s only flex atm, flash is coming. It’s all in progress, so I’m not sure what state it’ll be in by the end.

I’m doing it because several large portals (newgrounds and addictinggames) only accept flash. I’d like to be able to harness their audience.

Cheers,

Kev

#4

I’m one of your Twitter followers and I actually just joined to say that I’m really impressed with your dev process. As an indie, covering so many platforms is just damn impressive and I’m sure having such a widespread market is helping your sales considerably. Not to mention the free gadgets you get for testing! Quite a brilliant strategy to say the least.

Anyways, keep up the good work, your tweets always inspire me.

#5

So what comes out of TouchAPI? I mean whereabouts is the interface between that and the platform-specific stuff?

#6

The TouchAPI is just a set of interfaces. Each of the sub-blobs convert to the appropriate platform.

So in the case of Applet/Application a Jar pops out the end after build.
In the case of Android/Android-Paid an appropriate APK pops out.
In the case of iOS an XCode project pops out that needs building (that’s also automated but thats a separate thing)
In the case of HTML/JS/WebOS a zip containing the web page directory structure and all contents comes out
In the case of Flash a set of SWF files and a bunch of Javascript

Does that help at all?

Cheers,

Kev

#7

Hi! Kev :smiley:
good to see some sort of explanation :smiley:

About flash version: why do you have this kind of problems? On my computer at first take a big amount of time to load it and then start to “flash” on screen

#8

Yeah, the flash version isn’t any where near right yet. I’m still working on that piece atm.

It’s much more likely it’s my shabby coding than it is the technology in use.

Cheers,

Kev

#9

This is quite cool. Is your toolchain available for others to use?

#10

It’s a few years since I used Flash, but it’s quite plausibly not just your coding by any means…

#11

Amazing work, I don’t know how you hold down a full time job and develop a successful game on 5 different platforms as a one-man band.

Do you think that in say 1 year you will ditch the platforms that prove to give negligible sales? HTML 5 and flex seem like a double-up. In fact if HTML 5 takes off there’ll be no need to for any other platform I’m guessing?

#12

O__O There will always be a need for Java I hope! :stuck_out_tongue:

#13

What Eli says :smiley:

Have you ever thought about monetizing your tool chain? I think you could sell this to quite a bunch of developers. At least I would pay for it ;D

Cheers,
Tommy

PS: Legends of Yore is great and works fine on my cheap Android!

#14

“Quite cool” - why thank you! :slight_smile:

Problem with HTML5 at the moment (and I suspect for a while) is that the big portals (other than Kong) won’t take it - and they have the mass web game market. If you’re expecting to make some money from your games (no matter how little) you have to play ball - this means flash right now. Maybe in 5 years we won’t see it as a games platform any more but right now I’m just not so sure.

Thats sorta the point for me. To me, Java can be viewed as a few things:

  • A language - it’s a fantastic language
  • An SDK - it’s got an amazing and massive SDK
  • A VM/deployment - it’s got a great VM but a terrible deployment. Unreliable and massive. Thats the sticking point for most
  • Tooling - best tooling by far over any language. Eclipse = godly

So, the only bit I don’t find conducive to games development is deployment strategies. I want to keep using my knowledge of java (which isn’t too bad now). I want to keep utilizing the SDK (though thats limited with this approach). I especially want to keep using the tools.

Java is the win for development :slight_smile:

I’ve been down this route a couple of times. The problem with open sourcing everything and/or selling it on is the support. As noted above I’m a one man band (always have been) trying to produce both games and cross platform libraries. Slick absorbed so much of my time that I stopped writing my own games - at which point, why bother?

So I’d be happy to sell the integration scripts and framework on, but more as an example of how to do everything rather than some generic ongoing tool chain.

In addition you really need to consider whether this sort of things works for you. Limitations for certain platforms limit your types of games you can build successfully. That said, any one of the platforms is quite cool - being to code in Java and deploy for flash is pretty great from a making money point of view straight away :slight_smile:

I’ll be building some other same games as I go along (once I’ve got the next legends update out) so time will tell I guess.

Thanks for the feedback/comments everyone.

Cheers,

Kev

#15

Agreed! Still my favorite dev environment.

I would be fine with that.

I’m aware of the limitations of some platforms. But creating and monetizing flash games with Java is pretty tempting ;D
And having one code base for several platforms (I know that Java promises that for a long time now but we all know it’s not quite true for some of the platforms you already seem to support with TouchAPI) is even more tempting!

Does that mean we have to wait longer? Starting this thread about TouchAPI is just to make us envy you? How cruel! :wink:

#16

Lol, well I wasn’t going to big it up but I got a few requests to explain how it was working and I couldn’t think of a better place than JGO :slight_smile:

As to waiting, well, I don’t really know. Right now I wouldn’t know how much to charge or how to license stuff. It’d be pretty much just a dump of what I have I guess. And how to license etc. I guess I’d just go - donate - get zip - here’s a bunch of stuff. It’d need a sample game though (you’re not having legends ;)).

Cheers,

Kev

#17

Just wanted to chime in and say this has been really useful. I was wondering how you got Java running on iOS.

What did you do about gestures and other features only available on a subset of platforms? Just not use them?

#18

Glad it was useful :slight_smile:

I support some gestures, I map from the gesture response handler in the platform specific code into a control being pressed in the game code. So on iOS I might map pinch to Control.ZOOM - then the game can react to zoom. Then on desktop later I might map scroll wheel on the mouse to the same control so zoom then gets support there too - if you see what I mean. It’s about abstracting what things actually mean I guess.

Cheers,

Kev

#19

Where does the server stuff reside? Or at least the communication with the server? All via HTTP?

Things like login, saving games/highscores and such? I guess basically all the Google App Engine stuff :wink:

And what about the payment interface PurchaseListener()? Is that implemented for Android and iOS only? Using their APIs? How does this work for the applet?

This IS interesting stuff, my brain’s running in circles and I’m still at work ::slight_smile:

#20

It’s all via HTTP yep, originally hosted on Google App Engine - but due to their pricing changes moved over onto PHP on a VPS.

PurchaseListener is only supported for in-app purchase on Android and iOS. Thought I plan to add support for application in-app via paypal web.

Cheers,

Kev