Can you please help me answer the following questions?
How do people usually implement a timed event in games?
Example: You reach some point in time and something happens like a new wave of enemies appears or something similar.
What is the best way to make sprite animations?
Example: Explosions in an android game.
1) Every time round your game loop you will want to record the elapsed time (or delta time.) This means you could keep track of the time past since the game start and the time it took to execute one iteration of your loop (the latter is good for time based movement.)
2) Depends really, I'm assuming this is 2D so I personally use sprite maps (google it) and then after x seconds I will change the image that is being rendered to the next on in the animation sequence. Animation sequences normally consist of "frames" and after x seconds have passed then move to the next frame
1 - Each frame/cycle of your game, record the time, then get the difference between the previous cycle's and the current cycle's time. This is how much time has elapsed since the last frame/cycle. Objects can then have timers that subtract the elapsed time each cycle, and do things when their timers are <= 0.
2 - My preference for game development is flixel, which does a lot of the dirty work for you. If you want to use pixel images instead of vector graphics, you should take a look at flixel. It has a framework that makes working with images and spritesheet animations a breeze. At the very least you can figure out how flixel handles them and write your own methods based on what you learned. If you want vector graphics, however, you'll need some other solution.
Related
I need to generate objects for my little character to jump over. I have the artwork for these obsticles and my character can jump and I have a scrolling background.
How can I spawn my artwork for my obsticles on my x axis with spacing inbetween them?
Can anyone provide me with some sample code or atleast try and point me in the right direction?
Many Thanks,
James
Yes. You can. You want to use some sort of loop that generates them:
2 options you can use:
local function frameHandler()
if should_I_make_object() then
createObstacle()
end
end
Runtime:addEventListener("enterFrame", frameHandler)
this approach will create new objects according to frame rate. IE, lets
you create objects every 100 frames lets say. This will make levels play the
same (have the same number of obstacles) on different devices that have varied frame-rate
Option 2:
local function createObstacle()
--your_create_obstacle_code()
if game_is_still_playing() then
timer.performWithDelay(object_spawn_delay, createObstacle)
end
end
This option will create a new object every object_spawn_delay milliseconds.
This is easy to code, and is a nice solution when you need things to happen on
a time-dependent interval. But you do need code to decide if the game is still playing.
Also, be aware that if the game ends, there might still be a lingering callback to
createObstacle() that can create nasty bugs. Make sure to do proper cleanup when
the level / game ends and be aware this callback may be an issue.
So I am coing an android game and have managed to make a ball roll over the screen in the direction you tilt your phone. However I would like to make the ball roll faster the more you tilt your screen.
But what is the best way to implement this? Taking bigger steps is obv not good, it makes collisions hard to calculate. I want to move more steps per second instead.
So lets say you have a tiled board and you implement speed as tiles/millisecond. But that is problematic also speed will not be continous. You'd perhaps move 1 step every 10th time in a loop instead of every time in the loop. So you would move, then be still, then move, etc instead of continously moving. But maybe that is as good as it gets?
So this problem applies generally for any kind if computer graphics I guess. How do you implement this the best way? I'm specifically interested in what applies to Android.
The natural way of implementing speed and position problems is to have position calculated with the speed that way :
position = speed * dt
with dt constant, adapted for your implementation.
So basically the natural way is to increase the step. You say it's obviously bad for collision detection but with a limited speed and a small dt I don't really see why.
Android's API 15 Animation class contain this:
public boolean getTransformation(long currentTime, Transformation outTransformation) {
... code ...
}
The method calculate the delta time and send it to an Interpolator which in turn based on the time the Animation has run, returns a value which in turn is applied to the Transformation.
When I build my own custom Views I use the post(Runnable) method and then call my logic update, invalidate and then post(Runnable) again if some condition is not met. The logic call takes 1 ms, the overriden onDraw(Canvas) also takes 1 ms. What is bugging me is the invalidate() call which often make my delta time go up to values above 40 (40 ms is 25 frames per second) and it is not advisable to get values higher than that. Using delta time to calculate where to draw the next frame often stutters and is not possible. I have to not use delta time and rely on how fast the phone can update the view individually, making it go faster and slower on different phones which is not a good idea.
SurfaceViews are something I cannot work with because their structure are not in cohesion with other Views (mostly Z depth problems).
Now to my question, how did Android solve the Animations? They do not stutter and they use delta time. Somewhere they must have some magic but I cannot seem to find where. Any help is very much appreciated.
So in my game my View gets drawn an inconsistent rates. Which in turn makes it glitchy. Ive been running into alot of problems with the invalidate(); meathod. Any simple ideas- Everywhere i look I get thrown up on by tons of intense code.
You haven't provided us with much information, specifically code.
A few things you could do are:
Set the initial frame rate to the lowest value you observe your application runs at, i.e., if currently set to 1/60, but the frame rate continuously dips to 1/30, set to 1/30 etc.
Rework your drawing calls to be more efficient.
Try to combine multiple transformations into a single transformation by multiplying matrices, i.e. if you need to scale, translate, and rotate, multiply those three matrices together and apply that single transformation to the vertices instead of applying three separate transformations.
Try not to iterate through entire lists/arrays if unnecessary.
Attempt to use the lowest level / most primitive structure possible for anything you have to process in the loop to avoid the overhead of unboxing.
[edit on 2012-08-27]
helpful link for fixing you timestep: http://gafferongames.com/game-physics/fix-your-timestep/
It sounds like your game loop doesn't take into account the actual time that has passed between iterations.
The problem is the assumption that there is a fixed amount of time between loop iterations. But this time can be variable depending on the number of objects in the scene, other processes on the computer, or even the computer itself.
This is a common, somewhat subtle, mistake in game programming, but it can easily be remedied. The trick is to store the time at the end of each draw loop and then take the difference of the last update with the current time at the start. Then you should scale all animations and game changes based on the actual elapsed time.
I've wrote more about this on my blog a while back here: http://laststop.spaceislimited.org/2008/05/17/programming-a-pong-clone-in-c-and-opengl-part-i/
Part II specifically covers this issue:
http://laststop.spaceislimited.org/2008/06/02/programming-pong-in-c-and-opengl-part-ii/
It would be really cool to benchmark how many times per second an animation actually gets drawn to the screen in an android app. Is there a way to do it?
ie. I can set an animation to run over a 250ms period, but I want to benchmark how smooth it is objectively.
If you have a game loop running, you can calculate the framerate as follows:
FrameRate= 1000/LoopTime
Where LoopTime is the time it takes to execute an Update call and Draw call.