116

There's a long history of how we arrived at this common convention, with lots of fascinating challenges along the way, so I'll try to motivate it in stages: 1. Problem: Devices run at different speeds Ever try to play an old DOS game on a modern PC, and it runs unplayably fast - just a blur? A lot of old games had a very naive update loop - they'd collect ...


42

tl;dr don't mix your event loop with your game loop. When you move your mouse, the game receives a load of pygame.MOUSEMOTION events. You don't actually use these events to update your mouse position though, you are getting the current state of the mouse using pygame.mouse.get_pos(). That's inefficient, but it's not the problem. The problem is you are ...


34

It will cause one CPU core to always run on 100%. This usually doesn't cause any harm to the system. CPUs are designed to run on 100% for hours. But on a mobile device it will drain the battery quickly and heat up the device, which will likely cost you about a stars in your store ratings. On a desktop computer this is less of a problem, but it will consume ...


32

"Delta", "d" or "Δ", means "difference" in a mathematical context. Whenever there's a difference difference between two numbers with similar meanings, that difference may be called a "delta", or a "d". Deltas are very common in game development. For example, the difference between a character's X-coordinate one second ago and its X-coordinate now can be ...


27

This is the "time delta." It's how much time has elapsed since the previous update. It's necessary to ensure that animations, physics, and so on are running at the right speed. The code is running once per frame update. However, there's no guarantee that frames are drawn at a constant speed. One frame might take 1/60th of a second and the next might ...


20

Don't actually stop the game loop when pausing the game. Instead, you have to add bool variable, that is changed to true/false depending if game is paused. If game is paused, you only have to stop updating the game, but you can still keep rendering the current frame including getting updates from input. if(gameIsPaused == false) { // run updates } ...


19

Your main problem is likely this: final int skipTicks = 1000 / ticksPerSecond; Dividing an int by an int returns an int (the value is rounded down if needed), so skipTicks evaluates to 16. 1000 / 16 is 62.5 so you get around this many ticks per second. To solve this the easiest solution would be to use a millisecondsPerTick variable (what you are calling ...


16

See the image I provided in my previous answer: If you imagine that node 1 is 'Evade Enemy' and node 2 is 'Chase Enemy', you'll see that even though in the second iteration (when everything is green except for '2' and 'B' is when the second iteration starts), 'Evade Enemy' still gets checked first. Only when 'Evade Enemy' fails, because there are no enemies ...


15

Your GPU can probably render even 100k sprites without issues, but you need to do it smart. Sprites and other geometry must be supplied to a GPU in batches grouped by the same texture, shader and blend mode. Big AAA games are minimizing draw calls issued to the GPU. Draw calls are usually expensive, so many similar drawing operations are grouped together ...


13

I think that you can solve this problem simply by exerting more careful control over your possible code paths. For example, in the case where you're checking if the number of the player's lives has dropped below one, why not check only when the player loses a life, instead of every frame? void subtractPlayerLife() { // Generic life losing stuff, such ...


13

Delete the Thread.sleep() call (assuming you're on a desktop machine and have power to spare!). In general you never sleep in your game loop (except on Android, where there appears to be no other choice). The bad thing about Thread.sleep is it is unpredictable and may cause your game to give up exec time for longer than 16ms, which is the maximum time a ...


12

Like so much of gamedev, the answer to how city sim games accomplish this seemingly-impossible feat is: they probably don't. They're just faking it well. ;) Sims like these will typically operate on a "chunked" level, modelling groups of people, neighbourhoods, traffic corridors, or other city dynamics as a whole, rather than processing AI for every one of ...


11

I agree with Jari Komppa that defining card effects with a powerful scripting language is the way to go. But I believe that the key to maximum flexibility is scriptable event-handling. In order to allow cards to interact with later game events, you could add a scripting API to add "script hooks" to certain events, like the beginnings and endings of game ...


10

I have a damage system is my game and I would really love to stay away from float damage values, both for memory and game design reasons. My first instinct is to question your assumptions. It's extremely unlikely that using floats rather than ints for something like this is going to affect your memory usage in any noticeable way. On most systems, they take ...


10

FixedUpdate can run faster or slower than Update depending on your settings. That'll depend on load (how fast Update is running) and speed you have set for FixedUpdate (found in Edit->Project Settings->Time). Ideally, since Update is run once per frame, this is where you want to capture input. If you need to act on input in the FixedUpdate method (like ...


10

Yes, it does make sense. As you said it will make less load on the system, which is good for thermals, and other applications. However.... Your games logic should NOT depend on the updates per second. Therefore I recommebd you to take a look at deltatime, which will make your game independent of the updates per second. I recommend you to take a look at ...


9

I gave this problem - flexible computerized card game engine - some thought some time ago. First off, a complex card game like Chez Geek or Fluxx (and, I believe, Dominion) would require cards to be scriptable. Basically each card would come with its own bunch of scripts that may change the state of the game in various ways. This would let you give the ...


9

I have not seen an else being used in this instance (the Rastertek tutorial you mentioned does not use an else). My guess would be if that you tried to resize your window the game rendering would freeze proving that the else part is never executed, as the resize message would be constantly sent. A common loop would have this structure. while (true) { ...


9

In a word, synchronization. If you have some data (your world) which you're reading from one thread (the rendering thread), and writing to in another thread (the logic thread), it is possible that your data will be read in an inconsistent state (for example, half the world has been updated, but not the other half). To maintain consistency, you will probably ...


9

Typically, a frame is drawn every time through the game loop. Thus, the FPS tells you how fast the game is looping. That said, more sophisticated rendering architectures often decouple the rendering from the main game loop. In that case, the two are only vaguely related.


8

I usually implement a state-machine similar to this: StateMachine + changeState(State) + getCurrentState() + update() State + enter(StateMachine) + update(StateMachine) + exit() When a state becomes the active state, the StateMachine calls the enter method. The StateMachine continiously calls update on the active state. When the state ...


8

Delta Time is used to make your game speed constant, independently of framerate. If your game starts to get "heavier", it will start to slow down in framerate on less powerful android systems. For example, if you made it to run on 60 FPS, an Android cellphone that can run it at 30FPS will have the game slowed down by 50%! By including the DeltaTime in the ...


8

Read Gaffer's article, Fix your Timestep. Understand how time accumulators work. Implement them. And apply actual time delta to physics and rendering, rather than some assumed constant dt. See if that serves you better. Because in the end, if the time delta is varying wildly on your given platform, there is nothing you can do about that but to simulate ...


8

I think the author made a tiny error: while( GetTickCount() > next_game_tick && loops < MAX_FRAMESKIP) should be while( GetTickCount() < next_game_tick && loops < MAX_FRAMESKIP) That is: as long as it is not yet time to draw our next frame and while we have not skipped as much frames as MAX_FRAMESKIP we should wait. I also ...


Only top voted, non community-wiki answers of a minimum length are eligible