Entities like bots shouldn't have to be synced at all and instead be 100% deterministic, but I guess this is rarely needed, only for games with large amounts of AI.

Heh, this is interesting. Would probably get annoying backpeddling on both player predictions before-sync and the AI moves based on them, though.

IMO it's just better to be lazy and do the syncing.
If the game would be something like 4 vs 64 bots (like let's say left4dead)
Then how often I would sync bots would depend on bot's state (attacking / walking somewhere doing nothing) and dist from the player.
Of course the bot AI would be on the client too but I wouldn't count on it so much.

The deterministic way should be awesome in strategy games.
Let's say you order a peasant to chop wood, so he chops for the whole game - there isn't really nothing to send. (I would still sync him sometime , but like one time per 1s maybe + when his state changes)

From my knowlege most fps games sync everything (that's needed for multiplayer).
For example (im not fully sure about that) Source Engine.

They use diffrent tick rates for everything, so some thing may be out of sync for a sec but it will get sync'd back eventually.

(Im talking about a multiplayer fps with not-so-big map, like tf2 or something like that)
In multiplayer you kinda can have errors because :
-player/entity positions are the most important thing, and they must be sent every tick because they cant be predicted. (Yeah still there is some interpolation between timeframes etc but errors shouldnt be that big)
-the key things are stored in the server so client side error wont break the game
-bullets on the client's side can have error's as they are only a 'representation' and dont mean nothing for the game (as client cannot apply damage to other clients)

IMO if the world is not large (like a whole city / planet) or procedurally generated - float's shouldn't be a problem.

Networking shouldn't be a big thing, even if there would be a slight error it would be interpreted as lag by the player so its OK

I've experienced some weird bugs when creating a constraint system, where force would go to infinity or something like that, but min()/max() is nice (i think it's slow but it was ok for my purposes)

as far as my research goes it's only 3d.

Yes but you can just do a 3D orthographic projection from one side, so it will be 2D.
(You just wont use the depth axis)

So it is possible to :
create 2d model from quads + texture it
create bones for it
animate
render as RGBA png's
make a sprite sheet from it (with some graphic editor or write a script for it)

I think that it depends on device / what are we programming and desired optimization/preformance level.

Actually I don't think that on pc using floats affects the performance much.
It's kinda better to gain performance on some other thing, like Strings or opengl calls or whatever.

I think that the most efficient thing to do for that would be GPU raycasting.

BUT if you want to have dynamics / physics etc. I think that rebuilding the octree could be a problem, and storing voxels in grid^3 eats too much memory.

Or maybe do something like : store static geometry in octree, and dynamic in volumes made from grids. This method would provide low memory usage from static voxels and somewhat fast rendering.

IMO it would be possible (Probably CUDA would be needed)  to make some physics work on GPU, and somehow make GPU create the octree from point clouds. Then it could just pass the octree as 1D texture or something and draw it relatively fast.

I dont think, that point cloud made from spheres is a good idea.
Imo it would be very hard to extract them to mesh at realtime (if they arent on a grid or something).

Maybe the best solution for 'rounded' voxels with physics would be :
Marching cubes algorithm for voxels that are snapped to grid, and if something is in motion - just try to render it normally and try to snap it to grid if possible.

Yeah, I'll probably change game mechanics somehow.

I'll probably lower the number of the bombs + maybe make diffrent types of them.
Oh, also I'll add 'restart level' button or something.

[Requirements :]

So I have published my first game for Android.

It's basically a test of my framework (written in java, based on glsurfaceview) but I think it may be fun.

It is a chain reaction game, so you just need to blow up some things to unlock new levels.



Currently there are 10 levels.
I'll add more , but I am currently living in Skyrim so this will be hard

Requirements :
Android 2.2+ GLES 1.1+ (almost any android phone/tablet)
Type : Free (ads in main menu, but I think they are bugged)
Tested on Galaxy Mini.

There might be some bugs, when you see anything weird - please send me info.

Android Market Link

I think You just need to setup textures without interpolation/mipmapping and create model like normal one.

Okay, whatever i went with Spontaneous Ignition.

Its too small game to bother with details (Basically its just a project to test my engine)

[Spontaneous Ignition]

So I wanted to ask :

Is
Spontaneous Ignition

a good name for an android game about chain reactions?
Its something like :
You create an explosion somewhere on the screen, and the explosion makes other things explode etc...

I am testing everything on 240x320 galaxy mini

In my opinion it depends :
If you are making a game that doesnt need very good cpu/gpu you should consider small resoultions - it gives you bigger market.
And there are (in Poland) like 3 or 4 phones that are 320x240 and are given for 1PLN in subscription in T-mobile. So there are lots of them.

This is how i init my 2d projection :

Code:

ratio = ((float)w)/((float)h);
gl.glOrthof(-1, 1, -1 / ratio, 1 / ratio, -1, 1);

And i have a singleton that stores the screen information.
So I want to have text at top of the screen i just use

Code:

Screen.getInstance().top;

or something like that

If you are going for pixely style :
Just write in opengl, and use GL_NEAREST for min/mag filter.
Then you could setup 2D view by using glOrtho.

You can make a projection that will always be for ex. -1.0 for left side of the screen and +1 for right so everything will scale automatically.

[edit]

A lowpoly soldier model for an android game im working on.
It will be a top down perspective so i dont need to bother with details.

128^2 tex (w/ some tex space left) ~360 triangles.

edit: fix'd broken img

@handCraftedRadio :
Thanks for reply.
GL_POINT_SPRITE is bassically a rectangle, that you can define using 1 vertex, and it is textured with 1 texture. It doesnt support tex coordinates(so it just shows the whole texture), and rotation .
Its generally good if you want to draw lots of not-animated bullets or something like that.

Heres 1024 at ~71fps
http://imgur.com/098lB
(the white rectangle is AABB for occlusion culling or something)

Hi, Im trying to write my own 2D engine for android and I would like to ask some questions :
(this may be a little bit offtopic, sorry)

Are you writing using JNI ?
Are you drawing using opengl ?

How many sprites can you draw?
I am currently working on a fast sprite drawing thing and I got it from
(samsung Galaxy mini)
rendering GL_POINT_SPRITES :
~200 sprites on 10fps to ~5k sprites on ~35 fps
Im working on full rotation/scale/texcoord sprites, and im hoping to get 512 on 30fps.

@wollay
Your idea seems good, it's alot better if you want to have lots of collision checks or fluid dynamics.

I had lots of ideas for cube-voxel rendering , so I thought that i could share them
Dunno if this will be helpful, but maybe someday someone will use it for something.
(I was/am making a voxel, multiplayer shooter, rendered with cubes and partially GL_POINT's)

I experimented with 2d array of octrees (and also with octree of 2d arrays) and both were decent, but it ended by using one big octree.

I did an octree with had a LoD level, so if something was in a long distance - it was rendered out of bigger cubes (or GL_POINTS).

Also good optimization is getting the meshes in near->far (not random) order, so the graphics card can make early z-something thing

I made rendering using displaylists, and it was rendering the map out of 'bigger' chunks.
So bassically let's say that tree has 10 levels, I set the renderLevel to 5 and lodLevel=10
and it would make me display lists with alot of cubes.
If i would set lodLevel to 6 - it would render me maximally 8 big cubes.

Also files were made in that way, they contained some lods (for ex. level 10, 8 , 6)
so I could just simply load a low resolution voxels.

I had the map saved at for ex. level 10 but i was limitting the splitting to 12, so an explosion could make really nice looking (almost worms -style) holes.

I was projecting the octree level that im curently working on to a 3d grid, and then I could optimize them (join the faces etc)

I read alot about optimizations in minecraft - and there is one, thats easy to use, and is suitable for your project :
When you are creating your mesh - split it by the direction 'where the face is looking'.
So you will have 8 meshes instead of 1 and you could render only these that are visible for the player.

Hello, my first post btw.

What are you using for storing voxels ?
3D Array or octree ?
I experimented alot with minecraft-like voxel things, and from my experience if you want to have lots of voxels (i mean like 4x more than in minecraft), then you should store them in an Octree.

So if you would use some clever octree - you could store like 4x more voxels.
It would be harder/slower to make fluid simulations on this, and overall manipulating voxels is slower.
Still - rendering, mem usage is nice.

Basically if a node of an octree is not full - it doesnt waste memory, and when there is 8 cubes near each other - you could save it as one bigger cube.