New answers tagged

0

You usually have some kind of "main loop" in your game that runs continuosly. Depending on wether your game is multithreaded or not, this "main loop" looks different. In a single threaded environment, your main loop usually looks like this time = current time while game is running deltaTime = (current time) - time // custom logic // e.g. ...


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 ...


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 ...


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 ...


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 ...


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 ...


76

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 ...


1

It depends on how your software architecture looks. When you have a clear separation between user input, ai input, game mechanics and graphic engine, then you should be able to simply switch out the ai input with a second user input. But when you have tight coupling between the AI code and the other components of your game, then it might be quite a lot of ...


0

It's a lot harder than you think (Judging by your words), plus being able to create a game doesn't mean you are able to handle multiplayer gameplay. I don't know about specific engines, some might help you with online gameplay, but talking just about code: You need a server (or servers) (Even if the game is based on 1v1 gameplay, you need a place to store ...



Top 50 recent answers are included