I want to create a game like Temple Run and I also read the source code of CubeField.java. But I can not create obstacle just appear at the road (only three way player can run, and I want the obstacle just appear at the way that player will run and not too dense).
We would need to see more of your code to know where the problem is exactly.
However, If I had to take a guess based on the console output in your screenshot, it probably has to do with the code you’re using for your Timer, seeing as the output value being printed out for your timer is not a float.
The correct way to make a timer with JME is to accumulate the tpf float value in the update loop every frame. Then that value can be referenced to find out how much time has passed since you began accumulating the value.
private int barrierTimer = 0;
public void upate(float tpf){
barrierTimer += tpf;
if(barrierTimer > 0.5f){
//code to place your barriers here every 0.5 seconds
//reset timer
barrierTimer = 0;
}
}
I like to subtract the period length itself from the accumulated time, rather than resetting to zero. I guess it feels better to start the next timer loop iteration with that little portion of last frame’s tpf that was over the period length, instead of discarding it.
that way, if barrierTimer is equal to 0.55f this frame, you begin next frame with 0.05f in the accumulated value (on the way back up to 0.5f).
if(barrierTimer > 0.5f){
//code to place your barriers here every 0.5 seconds
//rollover timer
barrierTimer -= 0.5f;
}
It’s likely only a small difference in individual periodic timer loops, but in the back of my head I still think of the discarded leftover time as ominously accumulating somewhere.
For very large tpfs (like what happens when you come back from a pause from lost focus), this code will run the barrierTimer block every frame until it catches up.
…which may or may not be desirable, but something to consider.
Personally, I completely avoid JME’s tpf and keep my own (in double)… but the concept is sound either way.
