Yea let me quote myself, but this comment is targeted at libgdx users only:

Since Android Studio offers nothing for libgdx that IntelliJ doesn't - whats the point ? - its just hype you hipsters :D

I would think: 2D game -> 2D arrays. More layers ? ok then a list of 2D Arrays
I think its more intutive that way

faster? well that entirely depends on how you do it / implementation / if that created overhead / more elements you have to iterate over

also server vm is just one dll to copy 

Eh not sure if you mean me, I guess not: http://en.wikipedia.org/wiki/PlayStation_Mobile
"Operating System: Android, Vita"

Very possible of course

Showoff
Well what I'm lacking is network programming experience, especially with games.
For example I would send/poll positions of everything, every frame. Using UDP i guess but still maybe overkill. So I guess I need general high performance networking knowledge -  nothing to do with kryonet
Gotta read a book or something.

When libgdx works perfectly, only then will I even consider looking at it.
And I'm sure that all the cool extra features they showed wull never work with libgdx anyway, because those are customed designed for android sdk stuff

Well I'm sure you know why is that way.
Basically the name Java has forever been tainted, wrongly so, with poor performance
you shouldn't associate your commercial products, especially games with java, because it can only hurt you - since there is this prejudice

Well most people are morons and approach everything in life based on prejudice.

I always called libgdx a "framework" - hey another term =D

well its just terminology for the most part, but in libgdx most of the low level opengl command are all still suable, if you want. I'm not sure your typical engine has that.
on the other hand I'm sure Unreal engine has that... well whatever

Yes absolutely. You can just do your game frame-based.
Time/Delta vs Frame based game loops are, at least in the indie area a holy war...
The frame based approach is simply: Make sure your game runs a rock solid framerate, eg 60fps and dont use delta. Or have too modes 30 and 60.
Many many games are like this, since you dont have to use delta if you are sure that your framerate is constant, which is a good thing anyway.

However it kinda depends what platform you target and what your game is like.
If you are using a platform like say a console, you can easily use frame-based, since it will run the same anywhere.
And it also depends on what is going on in your game... If there are really busy sections and really idle sections you may have to use some delta.

Of our 4 games, 3 use frame-based and one uses some delta by applying a low pass filter over the delta values and stuff... Its really hard to get it right.
But if your game has like a minimum system requirement and you cap the fps,  the game will only run slower on hardware that is simply too slow anyway.

So yeah I'm kinda frame-based.

To me, the problems you encounter with using delta far exceed the benefits in most cases.

You using delta timing.
Getting it right is quite hard. So this is expected when you use delta.

Either learn really about gameloops and delta timesteps, or dont use delta - it depends on what you target

Its a simple 'using delta time equals jitter problem'
I kinda dont like delta time and try to avoid it because of this
Our latest game does a low pass filter over a coupke of collected delta times and so on

My advice: either make sure you have a rock solud framerate,  which is good anyway; or read up on delta timing / time steps in video games

oh it can ? need to read the options again I guess

Edit: Ah yes and I can see that this is default actually... edgepadding

Yo Andre, dont listen to them.
You could do something with a delay and stuff. But let me first introduce to InputAdapter

Now Gdx.input.isKeyPressed tells you if the key is down
The InputAdapter das a keydown and keyup method, which are only invokes once. Once you press and once you let go, respectively.

You write a small class extending InputAdapter or implementing InputProcessor, I would recommend at the end of you game class, so that you have access to game things.

and in you create() method you have to call Gdx.input.setInputProcessor(INSTANCE OF YOUR INPUTADAPTER CLASS)

if you have any follow-up questions, dont hesitate.

However unfortunately the gaming industry is kinda plagued by the fact that nobody wants to spend money on below AAA games.
This phenomenon that you see a game for 2 bucks instead of 1 in the android store or whatever and dont buy it, and then you tip a pizza guy...

mfw we are currently in the greatest depression in human history.

Well like always, you have to know the potential consequences. 

@Oskuro You are some special kind of lady.
Although I fundamentally disagree with you, I wouldn't want to start a political discussion, unlike you.
If you do that in a public forum, all hell break loose.

Also,  not to destroy your dreamworld: but cannot just sell on steam.
Getting on steam is a very hard and long process, and chances are you already have a lot of money by then.

Well I'm going to university and meet people.
You CAN find people online - but working together may be a pain... but for that you can ask anywhere, like reddit for example.


You simple do want to have a team.
If you want to  actually accomplish shit you need more than just yourself.
Especially artists if you cannot do any art.

btw PS Mobile is android... does libgdx stuff work there ?

Developing for the PS Vita & PS Mobile is now completely free: http://arstechnica.com/gaming/2013/05/sony-waives-99-mobile-development-fee-in-play-for-indies/

Things are looking good.

that would be the "potentially do something interesting with the data" part

@offtopic
Bonbon-chan is female too

There is no mentioning of pools here.
doing new ParticleEffect loads texture and json from file each time.
You dont want that.

I guess izs just because most people here make 2D games, because the scope of a 3D game is just so much greater.
If I would consider making a 3D game, I would try out jme.

Because Unity sucks hard.

The point is you can write direct lwjgl code with libgdx as well.
And also you are way out of line saying libgdx is hard to setup. Lwjgl is DEFINITELY harder to set up. For basic desktop programming with libgdx you just have to add 2 jars, that's it.

Its true.

Unless you are very skilled and experienced in both game development and opengl.
And even then it would take longer with lwjgl.
So it's only worth it if you are skilled, know what you can accomplish without libgdx more flexible and you are sure that you need it, and it would be too hard with libgdx.

Also if you happen to have a lot of legacy opengl code lying around...

its only important if you write a 3rd party API to be used by others or develop on android

other than that I never do it, its kinda silly

Btw are there any nice open source examples for something like this ?
Because when writing grids I'm always worried I may not do it as fast as possible.

Good to know, actually