I've had a game idea for quite some time for Android. It's a mix of features from several popular games like Farmville, Castle Clash / Clash of Clans, and others. The main point of view would be 2.5D. Most of the time the screen would look like something from Castle Clash / Clash of Clans. Was also considering 3D but limiting camera movement to something similar to the 2.5D angle, but include rotation.

Through much research and poking my nose in every place I possibly could I've settled on erlang and Redis/Lua for the server with a possibility of including MySQL for snapshotting (have to look more into Redis). I've done the preliminary login server, rate limiter, black list, token generator (for logins), and the most most basic game server. I just call it an echo server, because that's all it does for now.

So I decided to start working on the client end and start experimenting and tying things together.

I've gotten basically no where over the course of many many months (addressing this on-and-off). I considered several engines over that time: Project Anarchy, UE4, Unity and others. I saw libGDX and thought I could make something not bloated and halfway decent. Maybe I just haven't done my reading yet to get a good enough understanding of the framework (a.k.a maybe I need to find other tutorials besides gamesfromscratch). I basically started the basics of my own engine, saw libGDX and thought I'm saved, last night after some fiddling.... I think I'm at square one again.

Kinda comes down to I don't understand what libGDX is doing concurrently. I wanted to modularize the code but libGDX seems monolithic. I stumbled across the Game and Screen classes last night which gamesfromscratch doesn't even touch. Can scene2d scenegraph be used in 3D? Does it frustum cull?

Basically I feel lost.... again. Was hoping for some guidance, a site to get more info (the tutorials I need). Any help really. Thought while I'm in Alaska I could use my spare time to make some headway with this but hasn't happened. I have limited time online while I'm here which doesn't help.

Is libGDX more than enough for me? Just not seeing it at the moment?

Thanks.

Right now I'm using:

Eclipse Juno

Android SDK

Java 1.7

libGDX <<< ???? (Replace?, get better understanding?)

erlang 18

Redis 3.x

Lua 5.x

In my experience, understanding what a tool provides to you, separately from anything you want to make with it, is extremely useful.

That is, knowing what a tool can do and how it behaves (and knowing what it cannot do!) before starting a project gives you a good way to understand whether the tool is going to be of use for the project.

I always keep an eye on people mentioning tools, and their experiences relative to what they tried. Foremost to keep somewhat up to date on what's out there, in case I need something in that direction.

That of course only gives me knowledge of "it exists", and in some cases, with opinions of people that I often agree with, which can be used as a very qualitative indication of its perceived usefulness for the job they tried.

The more detailed knowledge can be gained from its documentation. (People giving me a complicated tool but no documentation get rejected very quickly in my book.)

The next step is to get actual experience. Build some small test-code perhaps a simplified part of the project you're going to do, preferably at a point where you doubt your understanding of how it's going to turn out. It's basically experimentally establishing whether you are correct in understanding how it works.

(All this is just experiments, throw the code away after you're done, mostly.)

Repeat experiments until you are satisfied that your understanding matches with the real capabilities of the tool.

That places you in a position where you can 'see' how the tool is going to fit in a project, and make an informed decision whether a tool is useful, just partly useful, not of any use at all in this project, to downright complete fail, although its author(s) and it community obviously believe otherwise (so you may be wrong :p ).

The whole point in doing small experiments in new tools first, is to speed up understanding. Until you've established the tool is going to be useful, all time you spend on it may be wasted (except for an informed opinion why the tool is not working for you).

If you drag a complete and big project along with these experiments, changing some code, or switching tools is going to be a major effort. At some point, you'll get stuck with some picked solution because switching is too costly.

My advice is thus to drop your big project now, and do some simple experiments (which can of course implement small parts of what your project is about) to establish how a tool works, and whether it is of use. Please keep in mind that this is all experimental code, assume it's going to be thrown away after you're concluded the purpose and usefulness of the tool.

It may be tempting to stick with the experimental code and extend, but since you didn't carefully designed the entire project around it, there is a big risk that after several months, you find a fundamental flaw in the base system. Writing code is cheap, thinking what code you have to write is expensive. (To see, assume whatever you did last week is now gone, and you have to write it again. Since you now know the solution, typing all code is work, but it's not difficult, the main limiting factor is your typing speed rather than your thinking speed.)

Thanks Alberth.

Part of me was hoping for a slightly different answer but the realist in me kicked in.

I've used that approach before (mini experiments) but it was often to test ideas, not tools. There are a lot of new things I learned (and continue to learn) for this project which isn't helping me at this stage lol.

Thanks again. Time to start digging in and researching more with the limited time I have. One thing I told myself was I was going to make some headway while I'm out here. :)