I am creating an android game where enemies are generated randomly and there can be multiple at once.
Is it better to create the enemies at a random time from a timer (so 5s, then 4s, then 6s... etc), or through the game loop (count to 50, create enemy, count to 64, create enemy).
If the phone the person used was slow at rendering the game loop, the timer could create too many enemies, but if it used the game loop, they would not get enemies very quickly. There appear to be pro's and con's for each.
Also, which is better for saving processing power so it can render images faster?
Thanks in advance
Tom
ALSO, if I used a timer for each "group" of enemies, there would be 3 timers running.
I recommend a combination: The engine should be driven by "ticks" that in itself don't represent a specific duration. All engine decisions should be done based on time calculations independent of the ticks (e.g. System.currentTimeMillis subtractions). This way when there is high load on the machine you get lower frames per second but the distance of movements is not influenced. When there is lower load you get smoother graphics and movements. You should check for FPS and if they get to high you should even set the thread to sleep or you can generate more enemies. If it gets too low you can lower graphic details or prevent generation of new enemies to adapt to the situation. So I wouldn't start timers but store times for events that you precalculate to occur in the future and check in the game loop if it is time for them to happen (not with exact comparision, of course, but eventtime < now).
Related
I am creating a voxel game in Java. Currently, I am using perlin noise to generate data for 3d chunks (16x16x16 short arrays) which are contained in a HashMap. This all works correctly. When the player moves, I want to render the chunks near the player (right now, 5 chunks in any direction). If a chunk does not exist, it should generate it.
The problem is that it takes about half a second to generate a chunk so when the player moves out of the generated area, the game loop freezes for a couple seconds while it generates the necessary chunks and then resumes.
I am using lwjgl for OpenGL and my game loop looks something like this:
while (!Display.isCloseRequested()){
update(); //my update method
render(); //my render method
Display.update(); //refresh the screen
Display.sync(60); //sync to 60 fps
}
I have tried, unsuccessfully, to use a second thread to generate data while updating and rendering but I could not figure out how to do it without freezing the game loop. I think there should be a way to queue chunks to generate in a second thread and then run that thread in short bursts but I have little to no experience with multithreading in Java so any help with that would be appreciated.
If the player can see the five chunks around him, you can maybe generate the chunks six rows away before he enters one direction. This way you have done the work early enough and you can display the chunks directly.
This task of generating the chunks you can do in a separate thread. It doesn't have to be called in the game-loop. You have to invoke the generater-thread before entering the game-loop.
I'd have a background thread that's notified when the player moves, then pregenerates chunks adjacent to the where the player moved. It's backed by a priority queue so that backlogs of never-visited cells aren't at the top of the queue, and old queue entries are removed once they're a certain distance from the player.
The key to leveraging threading is that you're generating the chunks before the player moves there, and taking down time in movements to generate chunks, and possibly unneeded chunks.
And the big caveat: if you offload all generation to that thread, you're going to need to use Futures so you always get back a generated chunk.
Okay, I solved my problem using only one thread. I created a TaskManager which was responsible for holding an arraylist of tasks to be done. So every time I needed to generate a chunk, I would pass a task object that contained information to actually perform the task. Then, every update, I would call TaskManager.next() which would perform the next task.
Now, instead of generating 49 new chunks in one update which froze the framerate, it generates one chunk per update until they are all generated.
To give some background information, I'm currently working on a Java coded pinball game. I'm keeping it in an MVC design model. It has a fairly realistic physics system that allows it to work collisions, gravity, friction etc. The system runs on a 20 FPS system right now.
The problem I'm having is that the physics loop that checks for collisions in the system works by running a method that using the current velocity of the ball calculates the time until the next collision. The most effective way for this to work would obviously be to keep running the check to account for the movement of the ball between checks to get it as accurate as possible, and if the time until collision is less than the time until the next check, then carry out the collision.
However, right now the system I am working with can only run the loop 20 times per second, which does not provide as accurate results as I would like, particularly during times of high acceleration, such as at ball launch.
The timer loop that I use is in the controller section of the MVC, and places a call to the physics section, located within the model. I can pass in the time remaining at the time the method is called in the controller, which the physics system can use, however I don't know how to run the loop multiple times while still tracking the remaining time before the next screen refresh?
Ideally I would like to run this at least 10 times per screen refresh. If anybody needs any more information please just ask.
Thanks for any help.
So the actual problem is that you do not know when the the collision will happen and when the next frame update is?
Shouldnt these be seperate running tasks? One thread that manages the collision detection and one that does the updating? each thread can run on its own interval (Timer.addTask(...)) and they should propebly be synchronized so colission/location updates are not performed when the render thread is executed.
Hope this answers your question.
Regards, Rob.
I'm making a Java game and I'm stuck on how to do timing easily. I know there's the delta time thing, but that would mean that I have to insert that delta variable in almost every movement/update function?
I was wondering if I can just time the main While loop of the game so it runs/loops every 50 miliseconds, rather then as fast as it can.
Changes in position are functions of time, so it makes sense to have to pass the time delta into most functions that update game state. It's the natural thing to do; I wouldn't be apprehensive of doing so.
While it is possible to insert delays every frame (and you almost certainly want to do so, as there's no point in having a game run at 1000 fps), it is usually detrimental to have your update logic assume that each frame will have taken a preset amount of time. Doing so results in choppiness when one frame happens to take longer than others.
To give your game a certain framerate, the general approach for each frame is as follows:
Record the current time as startTime.
Do the state updates.
Redraw.
Record the current time as endTime.
Sleep for (1 / framerate) - (endTime - startTime)
So i'm writing an app for android where you play a game similar to Dutch Blitz. Its a pretty simple game, and I have it basically finished, I'm mostly looking for advice for how to handle my AI opponents, right now they win the game in about 2 seconds, I was wondering what i should do to get them to "pause" mid loop or how to slow them down some how so that the user has a chance to actually win.
I just don't want my way to slow them down dependent on the processor speed of the phone used...
I'm not familiar with the game Dutch Blitz, but this logic should apply. You can create your turn functionality triggered by a Count Down Timer. That function repeated (think of this as a turn) will eventually equate to a win condition. Causing your AI to prevale eventually, but not right away. You can then set the rate of how often a turn happens, thus controlling the rate at which your AI will win. Also this makes it easy to set difficulty levels by increasing the time it takes your AI to complete a turn.
Your game may work with different rules, but some kind of interval per turn would probably be the simple way to control the speed of your AI.
I need random ticks for a game I'm making. Is there a way I could do that? I don't want it based on the tick rate of my game (average 60 ticks per second) because I need random movement for a character. Maybe I could use some of Notch's code?
Run a javax.swing.Timer at a fixed rate; in the listener, use a random variable to decide if something happens, e.g. nextBoolean() for 50% probability, nextInt(3) for 33%, etc. There's a related example here.
You have two main choices;
You can store a random value, and decrement it (reduce by one) every tick. when it reaches zero; perform your desired action, and assign a new random number to the variable. rinse and repeat.
This effectively gives you a random psudo-tick, entirely within the contraints of the existing timing mechanism.
Disregard the tickrate; randomised actions do not require randomised intervals, only randomised chance.
Basically, each tick you roll a chance of deciding on a new action, if the chance succeeds you choose a new action for the entity.
Its common to modify the chance based on how long they have been doing their current action; so that the longer an entity has been, say, 'sitting down', the more likely they will be to switch to something else.
You probably will also want to look up material on state-machines,
as its a common way of implementing simple AIs for game characters (which seems to be what you are doing).