Electron Runner - Android Game

Hi you all,
Sorry for not coming back to you all earlier but I was away for the weekend.

@machspeeds that error you see is a known error to me. It has to do with the Ads network I use.

Sometimes when exiting the game the ads API is not properly shut down and it holds on to the android java process, or something like that and then the next time you start up the application it throws that error. I do not know why exactly it happens in jME but that ads is the cause.

Try to open up your task manager in android and clear the phones memory.

It should do the trick.

Please let me know if it works.

I think the biggest problem that makes the game so shaky is the particles I use which causes so many objects at a time in the scene.
I think I need your help on this t0neg0d, I will ask you soon some questions about your emitter system.

First I must run some test on my side disabling the particles to see if that makes a difference.

If I may ask @t0neg0d,

How did you achive this and do you think it is possible with the jME 3D emitters?

Not to push my own stuff on someone, but if you use the 2D emitter and the directional influence from the gui library, you could use a single emitter to produce all of the trail effects. It was one of the things I did to increase performance in that Galaga type game. All enemy weapons are a shared emitter.

You may be able to accomplish the same this with JME’s emitter… not sure.

@ndebruyn said: I think the biggest problem that makes the game so shaky is the particles I use which causes so many objects at a time in the scene. I think I need your help on this t0neg0d, I will ask you soon some questions about your emitter system.

First I must run some test on my side disabling the particles to see if that makes a difference.

@ndebruyn said: If I may ask @t0neg0d,

How did you achive this and do you think it is possible with the jME 3D emitters?

When you say “so many objects” do you mean that you are currently treating each particle as an object, ie: Geometry? If so then, yes, even JME’s particle emitter would be a pretty large improvement.

No not that.
Let me explain how my electrons work:

  1. Each electron consist of a collision sphere.
  2. Each electron contains a jME particle emitter.
  3. Then the background is a jME Grid which is dynamically generated as explained before in this forum.

If I enable stats it looks like each particle in the scene is a separate object.

I do not know if that should be like that or not.
They are in world space. This might be the reason.

Each “electron” will be an object in your above description but a single electron’s particles should only be one object… ParticleEmitter is just a Geometry and a Geometry can only have one Mesh… so one object.

If you are seeing something different then it is something else.

That is what I also thought.
I will investigate more and see what could cause the amount of object on the screen.
It is currently something between 80 - 150 which is way too many for Android.

@ndebruyn said: If I may ask @t0neg0d,

How did you achive this and do you think it is possible with the jME 3D emitters?

Sorry… been a bit busy. What @pspeed said. Just make sure the emitter is using world coords.

EDIT: Ooops… better description…

  1. Don’t encapsulte the emitter
  2. Set the emitter to use world coords.
  3. Set the particle emitters location to the electron that is being updated (world traslation).
  4. Emit a number of particles… or next particle or whatever JME’s emitter allows for (I think it was just updated for emitting a number of particles).
  5. Rinse and Repeat for each electron.

I currently do that.
I make use of jme’s physics lib.

I don’t know if there is a problem on android with regards to the physics update loop…

I have a question? Do you make use of physics in your Bugs game?

@ndebruyn

Your solution worked. Just killed all my tasks. Thanks!

@ndebruyn said: I currently do that. I make use of jme's physics lib.

I don’t know if there is a problem on android with regards to the physics update loop…

I have a question? Do you make use of physics in your Bugs game?

What is it that you are using physics for? Seems like it might be overkill in this case.

@ndebruyn said: I currently do that. I make use of jme's physics lib.

I don’t know if there is a problem on android with regards to the physics update loop…

I have a question? Do you make use of physics in your Bugs game?

No, I just do some simple in-bounds checks. I agree with @pspeed that 3D physics in a (basically) 2D game is a bit overkill and the game would likely run 1000x smoother just by ditching it.

How do you determine your collisions then? As far as I know the nornal jme bounds collisions is not working so good and we were told to rather avoid it for android.

@ndebruyn said: How do you determine your collisions then? As far as I know the nornal jme bounds collisions is not working so good and we were told to rather avoid it for android.

Given that your objects are just little spheres… you can just take the distance between them and see if they are below some threshold. It’s the fastest type of collision check there is.

Edit: you don’t even need to sqrt() if your threshold is already squared.

@ndebruyn said: Man, I will never ever ever stop! This is my passion and I love making games even though they aren't the best in the world I will keep on trying to increase my skills.

And maybe one day you never know this might just be my main source of income.

And also, thank you for this brilliant and amazing engine. And thank you for not Giving Up on it!

=D

Yay finally it is in android was waiting for this game to use it in android :smiley: . It is working smoothly in my one. By the way love your attitude so quoted it, me and my buddy also think like that :slight_smile: .

K Out!

My biggest obstacle with this approach is, what will be the fastest way to check collision between different electrons, not just the player.

I could do the distance check but then I will have to loop through all electrons on each game loop to see if a collision occured, well actually more than just one loop.

It will be a loop for each electron on each game loop update. And that is BAD.

I could make use of the Rays in jME and shoot 4 different rays from the center of each electron and check for collisions in that way.

that might be a better approach.

Also, I have to concept of obstacles in the game. These obstacles are more than just spheres, how would I do that then with distance,

Any suggestions or help would be highly appreciated.

@ndebruyn said: My biggest obstacle with this approach is, what will be the fastest way to check collision between different electrons, not just the player.

I could do the distance check but then I will have to loop through all electrons on each game loop to see if a collision occured, well actually more than just one loop.

It will be a loop for each electron on each game loop update. And that is BAD.

I could make use of the Rays in jME and shoot 4 different rays from the center of each electron and check for collisions in that way.

that might be a better approach.

Also, I have to concept of obstacles in the game. These obstacles are more than just spheres, how would I do that then with distance,

Any suggestions or help would be highly appreciated.

What would you be shooting the rays against? I can’t see how it would be anything other than “all of the other electrons”. A ray check is WAY more expensive than a non-sqrt’ed distance check.

Here is the pseudo code to check all objects against one another in the brute force way. Bonus points if you put them in an array.

[java]
Spatial someObjects
float thresholdSquared = …
for( int i = 0; i < someObjects.length; i++ ) {
Spatial s1 = someObjects[i];
Vector3f loc1 = s1.getWorldTranslation();
for( int j = i + 1; j < someObjects.length; j++ ) {
Spatial s2 = someObjects[j];
float distSq = s2.getWorldTranslation().distanceSquared(loc1);
if( distSq < threshold ) {
// These two spatials collide
}
}
}
[/java]

There is no magic… something is going to be doing a loop like that somewhere. Whether it’s inside bullet or whether you are hiding it in a collideWith(Ray) [which is actually much much worse even]. It might as well be as fast and efficient as possible… and really, that one will take a fraction of the time of all of the loops JME is already doing every frame.

Edit: sphere to bounding box (assuming the obstacles are bounding boxes or something) is not much harder than the above. Essentially, two dot products instead of a direct distance check.

How many electrons do you have? What happens when they hit each other versus the player? How many obstacles will you have?

The bottom line, for what appears to be a pretty low number of objects, Bullet is probably not doing anything magic for you.

@kamran

Wow, cool man. Glad I am not the only once that feels like that about this engine!

Well then it is very good news for me.
Thanks for this, I will look into it right away.

Will it make a difference if I add the logic of the inner loop in a controller that is attached to an electron or not really?

I feel with a controller it is a little bit cleaner, but then It will have to make use of a small amount of more memory for each controller.

Any input?

@ndebruyn said: Well then it is very good news for me. Thanks for this, I will look into it right away.

Will it make a difference if I add the logic of the inner loop in a controller that is attached to an electron or not really?

I feel with a controller it is a little bit cleaner, but then It will have to make use of a small amount of more memory for each controller.

Any input?

It’s probably ok. Just remember, both s1 and s2 are colliding so you will want to call both.

The only thing about controls is that if you don’t need them for anything else then they sit there holding space and performing updates for no reason. Probably negligible, though.