undefined | Better HN

0 pointsMichaelEGR14y ago0 comments

@SomeCallMeTim >I submit it would be better for everyone if there were a single cross-platform engine that everyone used.

>What would have been better is a library that abstracts away the fact that Android is its own unique OS, period. When I write code, I don't want it to be Android code, or iOS code, or WebOS code, or Windows [Mobile] code, or Linux code. ---

There are options out there. I'm one of those 3rd parties soon releasing a comprehensive middleware solution for app dev including a lot of game dev oriented effort that provides a clean abstraction layer via a component architecture that uses a large majority of advanced Java language features under the hood without sacrificing performance.

Keep a watch out for TyphonRT; drop me an email via the contact address and I'll be glad to discuss more and make sure you get early access. I'm aiming to get it out ASAP and before I give an all day game dev workshop at AnDevCon II in November. I suppose one thing that makes TyphonRT unique is that it's a tool, framework, and future platform (PaaS). At the heart of things you can pick and choose individual blocks of functionality (tool), or utilize the runtime framework (framework), and soon there will be optional PaaS features aiding Android and cross-platform dev in the coming year after launch.

Another Java based cross-platform effort which is similar in purpose though significantly different at the architecture level is libgdx. For C/C++ check out Battery Tech and the Proton SDK for similar cross-platform efforts (both of these with even more device coverage).

TyphonRT provides that layer of sugar you seek without losing performance and creating full cross-platform execution for OpenGL apps without changing a line of code for J2SE -> Android. TyphonRT is not limited to OpenGL though and can utilize any graphics API potentially allowing a hybrid UI, but the rest of an app still being cross-platform.

Having worked intensely with Android since v1.0 and the G1 hit my hands in Oct '08 I have more than a few stories on the difficulty of low level development / games, etc. across different OS and major device hardware generations. I've experienced first hand a good deal of general engineering blunders and have found and reported a few major ones myself (you know when big G fixes a bug immediately upon being reported you found a good one; the 3.0 & 3.1 / NIO immutable endian swap issue comes to mind!).

Middleware will mature and soon provide a lot that the Android SDK lacks for certain app development areas. In many ways the Android SDK while novel in several areas is still being developed from an old engineering model, but that is seemingly unavoidable for a large organization such as Google. There are of course additional inherent problems with tying the SDK to firmware, but such is life.

I do agree with your last point though that generally the SDK in addition to the particular ecosystem quirks that have occurred over time isn't exactly indicative of satisfying developers.

0 comments

SomeCallMeTim14y ago

Thanks, but I guess I didn't get across how much I still hate Java. ;) I feel it has 95% of the problems of C++, without the advantages (predictable speed, mostly). I'm sure your platform will be useful for anyone porting J2SE code to Android, but that's not me. And it doesn't look like you're supporting iPhone? That's a huge chunk of the market still.

I know that middleware providers will step in to fill in the gaps, but it's just annoying to be non-native on ALL platforms. And there are already a lot of options.

http://www.batterypoweredgames.com/batterytech is one that I know that's low level, for instance -- it gives you events, OpenGL and sound on Windows, Mac, iPhone, and Android. It's pretty bare-bones, though, as far as I know.

There are also stacks that allow you to write in JavaScript [1][2], 3d engines [3][4][5], and one that I just found out about one that sounds really awesome, though I haven't used it yet called Moai [6]. Moai is Lua-based, open source, supports iPhone and Android, and has a Lua-based cloud server component, so you can write in the same language for your game and for the server side in multiplayer games.

If I haven't been clear, I think Lua IS an awesome language, especially now that LuaJIT 2.0 works on Android (and at least partly on iPhone), and so I'm strongly considering using Moai for my next game.

I actually already use Lua on the server side, though I'm using a different stack than Moai (they're on Mongrel2/Tir, and I'm using Nginx with lua-nginx).

[1] http://www.sencha.com/ [2] http://www.phonegap.com/ [3] http://www.stonetrip.com/ [4] http://unity3d.com/ [5] http://irrlicht.sourceforge.net/forum/viewtopic.php?t=37235 [6] http://getmoai.com/

MichaelEGROP14y ago

>Thanks, but I guess I didn't get across how much I still hate Java. ;)

Can't solve that.. ;) ;)

>I feel it has 95% of the problems of C++, without the advantages (predictable speed, mostly).

I suppose you'd have to get a little more particular in the 95% of problems angle. I have been working with Java for quite some time and TyphonRT contains necessary workarounds or API extensions enabling predictable speed. For instance TyphonRT being a Java based component architecture is highly dependent on iteration over collections of components. The custom collections API in TyphonRT has recycled and resetable iterators overcoming the "iterator problem" of the standard collections API. There is a bit more of other things done too to provide predictable runtime performance. A lot of that involves staying as memory efficient as possible and not triggering GC. Of course when things get too hairy yeah native code is used. One has to do that for physics engines (Box2D / Bullet) especially on Android. I'm really loving JavaCPP which is a relatively new effort for managing native bindings (http://code.google.com/p/javacpp/).

>I'm sure your platform will be useful for anyone porting J2SE code to Android, but that's not me.

If you are most familiar with C/C++ certainly by all means go with that and the NDK and use BatteryTech, Proton SDK, or something like that to provide the core cross-platform architecture support.

>And it doesn't look like you're supporting iPhone?

Not yet, but just like Unity which you mention cross-compilation is not out of the question. Like libgdx once the main framework is mostly finalized I'll be looking at say an Angle backed for the desktop and / or other options for expanding device and environment support. The primary goal is to create a leading edge Java framework / platform first. The platform / PaaS aspects also are a priority in the short term among many other things like strong Scala support / integration over say iPhone support. A thing to keep in kind too is that TyphonRT is not just aimed at game dev, but is applicable for all dev efforts including enterprise.

So yes, if you need cross-platform support go native or use a canned 3D engine like Unity if it matches the type of game you are trying to make.

>I know that middleware providers will step in to fill in the gaps, but it's just annoying to be non-native on ALL platforms.

Hrm? C / C++ is available on the majority of platforms... ?

>http://www.batterypoweredgames.com/batterytech is one that I know that's low level, for instance -- it gives you events, OpenGL and sound on Windows, Mac, iPhone, and Android. It's pretty bare-bones, though, as far as I know.

Yes it's not a complete game engine nor is Moai which you mention you have your eye on presently. BatteryTech, libgdx, and TyphonRT provide the core architecture to abstract the common requirements (input, audio, etc.) for real time apps & games. TyphonRT also has higher level optional components for game dev including a fully featured component oriented entity system (libgdx / BatteryTech, etc. don't). This class of tech is meant for folks that can build their own engines and perhaps their own creative games rather than trying to force canned engines to do things they are not great at doing. As mentioned though there are optional components with my efforts to further assist game dev efforts beyond core architecture abstractions.

Regardless of what you choose though I hope you make some cool games for Android! :)

SomeCallMeTim14y ago

>>I feel it has 95% of the problems of C++, without the advantages (predictable speed, mostly).

>I suppose you'd have to get a little more particular in the 95% of problems angle.

Hmm...getting very much off topic here, so I want to keep this brief, but roughly speaking I'm talking about the problems of the language being very verbose and missing a lot of useful features: no duck typing (C++ at least has templates, which have their own drawbacks -- Java generics need to be Object-derived), no coroutines, and no first-class functions are three examples that come to mind. Just look at the size of programs in the "Language Benchmark Game" -- Lua's entries are tiny compared to Java. Call me lazy. ;)

In addition, in Java you HAVE to force everything into an object paradigm, whether it makes sense or not. Lua can act object-oriented if you want it to, but you can also use it in other ways that simply make more sense to the problem at hand.

>Yes it's not a complete game engine nor is Moai which you mention you have your eye on presently.

No implied criticism there. As you mention BatteryTech is also low-level. There's a place for that.

For what it's worth, Moai does come with things like physics; not sure how they bind things together, but I would have guessed that they have a very basic engine with game objects. Could be wrong.

JavaCPP looks interesting, though I'm instead just minimizing my use of Java so I can have a Windows and iPhone version trivially.

>>I know that middleware providers will step in to fill in the gaps, but it's just annoying to be non-native on ALL platforms.

>Hrm? C / C++ is available on the majority of platforms... ?

Yes, but it's the API for getting events, putting up native dialogs, etc. that will be non-native everywhere. On Android more so than usual.

And actually...C/C++ isn't currently supported on Windows Mobile, at least in the public SDK, for what it's worth. Though C/C++ are supported on pretty much every platform where the company behind it isn't being stupid, yes.

No implied criticism toward your project in general, by the way. It's just not my thing, since I'm not a Java person. It does sound like you've solved a lot of the problems that people often have with Java, though, which is great.

>Regardless of what you choose though I hope you make some cool games for Android! :)

Thanks. :)

1 more reply

j / k navigate · click thread line to collapse