Hot answers tagged

75

Now how does the game handle those 30 Projectile and 70 units by handling them on 100 different threads No, never do that. Never create a new thread per resource, this doesn't scale in networking, neither does it in updating entities. (Anyone remember the times when you had one thread for reading per socket in java?) 1 thread that moves all of ...


37

Rule number one of multithreading is: Don't use it unless you need to parallelize on multiple CPU cores for performance or responsiveness. A requirement "x and y should happen simultaneously from the users point of view" is not yet sufficient reason to use multithreading. Why? Multithreading is hard. You have no control over when each thread gets executed ...


26

The other answers have handled the threading and power of modern computers. To address the bigger question though, what you are trying to do here is avoid "n squared" situations. For example if you have 1000 projectiles and 1000 enemies the naive solution is to just check them all against each other. This means you end up with p*e = 1,000*1,000 = 1,000,000 ...


16

Do not create threads per resource/object but per section of your program logic. For example: Thread to update units and projectiles - logic thread Thread for rendering the screen - GUI thread Thread for network (eg. multiplayer) - IO thread The advantage of this is that your GUI (eg. buttons) does not necessarily get stuck if your logic is slow. User ...


10

Why are you giving the player loot in the first place? It's a reward stimulus for the player. Games need a constant stream of reward stimulus (or at least the anticipation of a reward) to keep the player motivated to continue playing. The impact of a reward is not just determined by the mechanical effect (player now has 10 more gold to spend) but also by ...


4

Even Space Invaders managed dozens of interacting objects. Whereas decoding one frame of HD H264 video involves hundreds of millions of arithmetic operations. You have a lot of processing power available. That said, you can still make it slow if you waste it. The problem is not so much the number of objects as the number of collision tests performed; the ...


3

I am going to disagree with some of the other answers here. Separate logic threads are not only a good idea, but hugely beneficial to processing speed - if your logic is easily separable. Your question is a good example of logic that is probably separable if you can add some additional logic on top of it. For example, you could run several hit detection ...


2

I think the other answers miss an important part of the question by focusing too much on the threading part of the question. A computer doesn't handle all objects in a game at once at all. It handles them in sequence. A computer game progresses in discrete time-steps. Depending on the game and the speed of the PC, these steps are usually either 30 or 60 ...


1

There is a 2% chance that quality will be legendary yet when printed 20 times every time it is run at least 1 item in almost every test run is legendary. Your algorithm generates a "legendary" rarity whenever a random number in the range 0..1 rolls above 0.97. That's a 3% chance or a chance of one in 33. It's not a 2% chance because random() generates ...


1

In some games, mainly in fps, it can create a bit more of a thrill. Ex. if you are behind cover and out of ammo and you see a gun. Maybe you can reach it or you have to sprint across the open to grab it. Making it manual adds a little more skill and requires a bit more attention to be played by the player. Another reason is that a lot of games (like ...



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