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