[SomeCallMeTim]

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/

[MichaelEGR]

>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! :)

[SomeCallMeTim]

>>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. :)

[MichaelEGR]

>Hmm...getting very much off topic here, so I want to keep this brief ... the problems of the language being very verbose and missing a lot of useful features

Yes, let's not belabor things, but I do want to point out that Scala essentially covers all of the points you raised. It supports duck typing (type safe too!), coroutines, first-class functions, and is more syntactically elegant. Scala even supports a particular mechanism to "sort of" support primitives w/ generics with the @Specialized annotation. So yes, I'm turning to Scala to provide additional language features and it's especially cool keeping type-safe aspects and being able to do joint compilation, so this works well for desktop / J2SE & Android integration. Of course Scala on top of the finely tuned TyphonRT / Java COP API and such is nice; more concise code for sure; this in addition to having access to all of the Java and/or Android SDK and 3rd party libraries. On the Java tip too regarding generics / Object situation TyphonRT has primitive collections available as well which is the main use case.

> 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.

I'd argue it's not a silver bullet as a primary language to write an entire game / engine in w/ more discussion continuing along those lines; there seems to be flexibility gained and lost. As a scripting engine that's one thing, but not a catch all for everything.

The important part here though and hopefully this ties back in a little with the OP and your concerns is that there are options available to take the edge off of mobile dev Android or otherwise and things should radically change in that regard in the next couple of years.

@seclorum is certainly correct that cross-platform mobile dev with OpenGL/ES is not out reach at all and once the C/C++ or Java decision is made depending on dev flexibility one can be creating rich content games not limited by a particular mobile OS concern.

Ultimately you want to pick the tool you are most comfortable and proficient with as in regard to indie game dev there are many other fish to fry let alone the hit based nature of the current app stores.

>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.

From what I read Moai supports Box2D. You know who else supports Box2D; everyone... BatteryTech, libgdx, TyphonRT, the list goes on, etc. etc. ;) It does sound like there is a basic game object API in Moai, but it only is geared towards 2D presently.

I know Robert of BatteryTech is doing a whole lot of Lua integration and work with BatteryTech, so do take a 2nd look and drop him an email perhaps.

>JavaCPP looks interesting

Indeed.. It's the 1st JNI / native marshaling assistance API that I like that takes the pain away of hand rolling JNI code. :)

>Yes, but it's the API for getting events

This is abstracted with most middleware mentioned. In fact input control is the largest category of core architecture components in TyphonRT (almost 10%).

>putting up native dialogs, etc. that will be non-native everywhere.

Why would you do this if you are creating an OpenGL/ES cross-platform game? Use a GL based GUI that will be cross-platform!

>It's just not my thing, since I'm not a Java person.

Fair enough hence why I'll stop posting on the thread! :) Though I did want mention some responses on the off the top general criticisms at the front of this reply. JVM languages will breathe some life into the Java sphere of things. This in concert with well developed middleware will make a lot of things that are hard now much easier soon enough.

It gets better.. ;P

[SomeCallMeTim]

OK, just going to answer a few points, to try to wrap this up. :)

>I'd argue it's not a silver bullet as a primary language to write an entire game / engine in w/ more discussion continuing along those lines; there seems to be flexibility gained and lost. As a scripting engine that's one thing, but not a catch all for everything.

I write a lot of the core "engine" in C++ for speed and lack of garbage creation. The game I've got on the Android market right now has about 3149 lines of C++ code specific to the game (not counting 7400 lines of auto-generated Lua bindings), but 10k lines of Lua code. Most of the game code is in Lua; is that scripting?

The engine itself has about 10k lines of C++ code, and very little Lua. I want the engine to be as fast as possible, so it's hard for me to imagine doing it in a language that isn't C or C++.

>>>putting up native dialogs, etc. that will be non-native everywhere. >Why would you do this if you are creating an OpenGL/ES cross-platform game? Use a GL based GUI that will be cross-platform!

Geting UI right is really, really hard. For the primary game UI, and dialogs with buttons, sure, all of it happens in GL.

But if I want a list dialog, or a grid view, or a WebKit view, I'm not going to want to do my own halfway implementation -- I'm going to want a dialog with a native feel. There's no game anywhere that I've used that really gets anything as simple as a keyboard entry field completely right, if it doesn't use the native UI; there are some things better left to the UI experts.

A good friend of mine is a big Scala fan, but I haven't really explored it as an option.

The thing that kills Scala for me (without knowing anything else about it) is that most platforms I write for don't already have a guaranteed JVM -- iPhone and Windows being big ones. I mean, sure you almost always have SOME JVM on Windows, but I'd likely want to be shipping a specific JVM.

And that means adding multiple megabytes onto my package size. You've got 20Mb on iPhone if you want to be able to download over the air. Adding 5Mb to support a language...isn't an option.

LuaJIT takes up about 50k. With all its libraries. And performs on par with Scala. Which is a huge win for me. How much overhead does Scala add to an app on Android? I bet it's more than that, even with the guaranteed JVM (well, DVM) preinstalled.

[MichaelEGR]

> OK, just going to answer a few points, to try to wrap this up. :)

And for the wrap up wrap up ;P

> I write a lot of the core "engine" in C++ for speed and lack of garbage creation.

Most definitely. That was all I was getting at is that the core engine should be as fast as possible.

What game on Android Market BTW? Would be glad to check it out and support yah! :)

> Geting UI right is really, really hard... But if I want a list dialog, or a grid view...

Indeed.. UI is hard though I'd say list dialogs and grid view is still GL possible without too much difficulty given various tool kits. Yes a WebKit view is difficult to pull off cross-platform presently. There are options like Awesomium though I've yet to see it used on a mobile platform, however I'm sure something will come up soon.

Yes.. a keyboard entry field depending w/ a GL UI in conjunction with say popping up the default native UI keyboard for touch only devices is something that would need to be fine tuned.

I plan to tackle general GL UI matters at a future point to offer a nicely integrated set of optional components. You are right though it's generally difficult.

For aspects in TyphonRT that require local / native peers the main application container is loaded declaratively with a cross-platform interface component backed by the proper native implementation, so from the devs perspective they can just request the common interface and the platform specific aspects are active behind the scene.

>... most platforms I write for don't already have a guaranteed JVM

Yes, for a desktop release it might be pertinent to distribute a private stripped down JVM. For mobile.. Well.. It's not easily feasible or likely allowed if I recall in the TOS to have a JVM on the iPhone. Cross-compilation is the likely way to go if / when TyphonRT supports iOS.

>How much overhead does Scala add to an app on Android?

Yeah you got me there.. ;) If one uses the Scala standard library that jar file is ~8MB. Whether that can be split up and paired down I'm not sure yet. I'm close to starting on Scala integration (mind you this is optional w/ TyphonRT).

There are also platform aspects of TyphonRT that will reduce overhead for multiple apps installed, but this gets into a bit more conversation here than necessary; essentially though side-loading shared components installed by other apps thus minimizing each app requiring a large download.

So yeah, some work and experimentation ahead. I'll definitely be working on a minimum profile (if possible) for Scala integration.