kevglass
|
 |
«
Posted
2011-10-30 18:36:53 » |
|
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/docThe 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: 1
| 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. 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 (tm)
- 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.
TechnologiesLinksThe main game is available in several forms at http://www.legendsofyore.comThe HTML 5 version is live at http://www.legendsofyore.com/jsThe in progress Flash version (don't expect too much yet) is available at http://www.legendsofyore.com/flexIf anyone is interested in any more information, just let me know. Cheers, Kev |
|
|
|
|
Riven
|
|
«
Reply #1 - Posted
2011-10-31 02:12:34 » |
|
You picked a project name that sure will be hard to find through google  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. |
|
|
|
|
kevglass
|
|
«
Reply #2 - Posted
2011-10-31 07:42:16 » |
|
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
|
|
|
|
Games published by our own members! Check 'em out!
|
|
|
Stevo86
|
|
«
Reply #3 - Posted
2011-10-31 14:22:21 » |
|
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.
|
|
|
|
|
|
Breakfast
|
|
«
Reply #4 - Posted
2011-10-31 16:09:21 » |
|
So what comes out of TouchAPI? I mean whereabouts is the interface between that and the platform-specific stuff?
|
|
|
|
|
|
kevglass
|
|
«
Reply #5 - Posted
2011-10-31 16:12:18 » |
|
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
|
|
|
|
|
Gornova
|
|
«
Reply #6 - Posted
2011-10-31 16:15:36 » |
|
Hi! Kev  good to see some sort of explanation 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 |
|
|
|
|
kevglass
|
|
«
Reply #7 - Posted
2011-10-31 16:17:22 » |
|
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
|
|
|
|
|
Eli Delventhal
|
|
«
Reply #8 - Posted
2011-11-01 00:38:55 » |
|
This is quite cool. Is your toolchain available for others to use?
|
|
|
|
|
Breakfast
|
|
«
Reply #9 - Posted
2011-11-01 01:13:07 » |
|
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.
It's a few years since I used Flash, but it's quite plausibly not just your coding by any means... |
|
|
|
|
Games published by our own members! Check 'em out!
|
|
|
CommanderKeith
|
|
«
Reply #10 - Posted
2011-11-01 02:49:40 » |
|
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?
|
|
|
|
|
ra4king
|
|
«
Reply #11 - Posted
2011-11-01 04:58:18 » |
|
O__O There will always be a need for Java I hope!  |
|
|
|
|
thaaks
|
|
«
Reply #12 - Posted
2011-11-01 11:11:31 » |
|
This is quite cool. Is your toolchain available for others to use?
What Eli says 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  Cheers, Tommy PS: Legends of Yore is great and works fine on my cheap Android! |
|
|
|
|
kevglass
|
|
«
Reply #13 - Posted
2011-11-01 11:45:36 » |
|
This is quite cool. Is your toolchain available for others to use?
"Quite cool" - why thank you! 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?
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. O__O There will always be a need for Java I hope
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 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
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 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 |
|
|
|
|
thaaks
|
|
«
Reply #14 - Posted
2011-11-01 12:24:14 » |
|
Java is the win for development Agreed! Still my favorite dev environment. 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.
I would be fine with that. 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 I'm aware of the limitations of some platforms. But creating and monetizing flash games with Java is pretty tempting 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! 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.
Does that mean we have to wait longer? Starting this thread about TouchAPI is just to make us envy you? How cruel! |
|
|
|
|
kevglass
|
|
«
Reply #15 - Posted
2011-11-01 12:29:02 » |
|
Does that mean we have to wait longer? Starting this thread about TouchAPI is just to make us envy you? How cruel!
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 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 |
|
|
|
|
loom_weaver
|
|
«
Reply #16 - Posted
2011-11-01 13:43:39 » |
|
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?
|
|
|
|
|
|
kevglass
|
|
«
Reply #17 - Posted
2011-11-01 14:20:42 » |
|
Glad it was useful 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 |
|
|
|
|
thaaks
|
|
«
Reply #18 - Posted
2011-11-01 16:22:38 » |
|
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 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  |
|
|
|
|
kevglass
|
|
«
Reply #19 - Posted
2011-11-01 18:16:25 » |
|
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
|
|
|
|
|
kevglass
|
|
«
Reply #20 - Posted
2011-11-04 11:31:31 » |
|
For those still interested, I got the flash version working: http://www.legendsofyore.com/flex/It's got performance issues and the standard set of flash issues (doesn't run well on OSX). I'm working with the GWT4Flash to improve things but it's definitely a possible pipeline Cheers, Kev |
|
|
|
|
thaaks
|
|
«
Reply #21 - Posted
2011-11-04 13:41:57 » |
|
Cool progress! Definitely too slow right now (even on Windows) but I'll bet you'll work that out |
|
|
|
|
kevglass
|
|
«
Reply #22 - Posted
2011-11-04 13:44:30 » |
|
Chrome seems to give the best results by the way, it's at least a consistent lag between clicking and response then.
Cheers,
Kev
|
|
|
|
|
thaaks
|
|
«
Reply #23 - Posted
2011-11-04 14:09:12 » |
|
Confirmed. Firefox is much slower than Chrome, at least on my machine here. Chrome can be considered "nearly playable" |
|
|
|
|
thaaks
|
|
«
Reply #24 - Posted
2011-11-04 15:23:48 » |
|
I have a question regarding different screen/device resolutions. What is the best approach to deal with them for TouchAPi?
I assume you have some scaling mechanism builtin. But is it smarter to code and create graphics for a higher resolution (say IPad) and scale down on Android or old IPhone OR is it better to create the game for a low resolution and let TouchAPi scale up?
Can an app using TouchAPi have different resolutions on different devices (like 1024 x 768 on desktop app and something like 480 x 320 on Android or IPhone 3)?
|
|
|
|
|
Cero
|
|
«
Reply #25 - Posted
2011-11-04 15:25:13 » |
|
seems fast enough on Opera - only the lick lag, but its like 800ms
playable
not that fast of a game anyway =P
|
|
|
|
|
kevglass
|
|
«
Reply #26 - Posted
2011-11-06 11:57:51 » |
|
Had a look at another way of converting from Java to AS3. This one converts the Java source to AS3 source: http://dl.dropbox.com/u/1668516/flash/index.htmlThere's a tool called Java2AS3 which get you about halfway. Then I use JAD to decompile compiled java to remove some of the more annoying incompatibilities between Java and Flash. Finally some resources embedded scripts and some minor token replaces to get to AS3 - which I come with the open source AS3 compile and bing Unfortunately, it relies on having some conventions in your java source (can't use method overloading for instance) so you'd really need to know you were targetting flash from the start or have a bit of rework to do on your code base (hence this isn't going to work for legends in the short term). Still, nice to know there's another alternative. Plus side is of course that the code performs as well as any flash application and that the packaging looks exactly like a flash game, i.e. a single SWF. I expect to be using it for a few mini games in the future. Cheers, Kev |
|
|
|
|
kevglass
|
|
«
Reply #27 - Posted
2011-11-07 15:56:04 » |
|
Just added some minor performance improvements.
Cheers,
Kev
|
|
|
|
|
|
|
kevglass
|
|
«
Reply #29 - Posted
2011-11-17 15:09:09 » |
|
I've done a bit more work using the Java2AS3 stuff and made stuff work a bit better. Here's a comparison page between Java Applet / HTML5+JS and Flash: http://www.cokeandcode.com/fruitypops/Be warned, running a bunch of different techs in the same page like that can have some annoying side effects. However, it tries to show the differences in performance, stability and start up time. One java code base for all deployments. Android, iPhone, WebOS and Desktop outputs would work fine. Cheers, Kev |
|
|
|
|
