Return to Answer

My game is working fine for now, but there's no real way to test with 50 players until people actually start playing.

There is. Just write a bot client for stress-testing your gameserver. While it is hard to write a convincing bot which behaves exactly like a real player would behave, it is usually not that difficult to write one which just logs in, joins a game and performs some simple automated actions to generate some server load. The bot should be simple and lightweight, so you can easily run a lot of instances of it (i.e. no graphic output). Run 50 instances of your bot on your local workstation and have them connect to the server.

_{By the way, you might notice that such a bot can be used to automate a lot of other tedious testing tasks. You could even go so far and implement a whole automatic integration test suit by having some bots play preprogrammed matches and check automatically if it still turns out the way it is supposed to.}

Checking every object in the game against every other object in the game is an algorithm with a time complexity of O(n²). That means the execution time raises quadratically with the number of objects in the game.

  When you notice that the amount of collision checks creates notable performance degradation, look into ways to reduce the number of objects you need to compare every object with. One useful method is to divide the game map into sections, keep track of which section contains which objects and only check collisions between objects in the same or in neighboring sections. Another is to store all your game objects in a spacial tree like an octree or 3-d tree which allows you to quickly iterate all objects in a given area.

But keep in mind that while spacial datastructures speed up collision checks, they slow down movement because you need to update these structures whenever something moved. That means they work best for objects which move rarely or never.

My game is working fine for now, but there's no real way to test with 50 players until people actually start playing.

There is. Just write a bot client for stress-testing your gameserver. While it is hard to write a convincing bot which behaves exactly like a real player would behave, it is usually not that difficult to write one which just logs in, joins a game and performs some simple automated actions to generate some server load. The bot should be simple and lightweight, so you can easily run a lot of instances of it (i.e. no graphic output). Run 50 instances of your bot on your local workstation and have them connect to the server.

_{By the way, you might notice that such a bot can be used to automate a lot of other tedious testing tasks. You could even go so far and implement a whole automatic integration test suit by having some bots play preprogrammed matches and check automatically if it still turns out the way it is supposed to.}

Checking every object in the game against every other object in the game is an algorithm with a time complexity of O(n²). That means the execution time raises quadratically with the number of objects in the game. When you notice that the amount of collision checks creates notable performance degradation, look into ways to reduce the number of objects you need to compare every object with. 

One useful method is to divide the game map into sections, keep track of which section contains which objects and only check collisions between objects in the same or in neighboring sections. 

Another is to store all your game objects in a spacial tree like an octree or 3-d tree which allows you to quickly iterate all objects in a given area.

But keep in mind that while spacial datastructures speed up collision checks, they slow down movement because you need to update these structures whenever something moved. That means they work best for objects which move rarely or never. A section-based approach (sometimes referred to as "spatial hashing") does not have that much overhead for moving objects, because all you need to do when an object moves from one section into another is remove it from the old section and add it to the new one. So you could also try a hybrid approach. Use trees for checking collisions between game objects and walls and use sections for checking collisions between game objects and other game objects.

My game is working fine for now, but there's no real way to test with 50 players until people actually start playing.

There is. Just write a bot client for stress-testing your gameserver. While it is hard to write a convincing bot which behaves exactly like a real player would behave, it is usually not that difficult to write one which just logs in, joins a game and performs some simple automated actions to generate some server load. The bot should be simple and lightweight, so you can easily run a lot of instances of it (i.e. no graphic output). Run 50 instances of your bot on your local workstation and have them connect to the server.

_{By the way, you might notice that such a bot can be used to automate a lot of other tedious testing tasks. You could even go so far and implement a whole automatic integration test suit by having some bots play preprogrammed matches and check automatically if it still turns out the way it is supposed to.}

When you notice that the amount of collision checks creates notable performance degradation, look into more efficient ways to pre-check. One useful method is to divide the game map into sections, keep track of which section contains which objects and only check collisions between objects in the same or in neighboring sections. Another is to store all your game objects in a spacial datastructure like an octree or 3-d tree which allows you to quickly iterate all objects in a given area. But keep in mind that while spacial datastructures speed up collision checks, they slow down movement because you need to update these structures whenever something moved.

My game is working fine for now, but there's no real way to test with 50 players until people actually start playing.

There is. Just write a bot client for stress-testing your gameserver. While it is hard to write a convincing bot which behaves exactly like a real player would behave, it is usually not that difficult to write one which just logs in, joins a game and performs some simple automated actions to generate some server load. The bot should be simple and lightweight, so you can easily run a lot of instances of it (i.e. no graphic output). Run 50 instances of your bot on your local workstation and have them connect to the server.

_{By the way, you might notice that such a bot can be used to automate a lot of other tedious testing tasks. You could even go so far and implement a whole automatic integration test suit by having some bots play preprogrammed matches and check automatically if it still turns out the way it is supposed to.}

Checking every object in the game against every other object in the game is an algorithm with a time complexity of O(n²). That means the execution time raises quadratically with the number of objects in the game.

When you notice that the amount of collision checks creates notable performance degradation, look into ways to reduce the number of objects you need to compare every object with. One useful method is to divide the game map into sections, keep track of which section contains which objects and only check collisions between objects in the same or in neighboring sections. Another is to store all your game objects in a spacial tree like an octree or 3-d tree which allows you to quickly iterate all objects in a given area. 

But keep in mind that while spacial datastructures speed up collision checks, they slow down movement because you need to update these structures whenever something moved. That means they work best for objects which move rarely or never.

My game is working fine for now, but there's no real way to test with 50 players until people actually start playing.

There is. Just write a bot client for stress-testing your gameserver. While it is hard to write a convincing bot which behaves exactly like a real player would behave, it is usually not that difficult to write one which just performs some automated actions to generate some server load. The bot should be simple and lightweight, so you can easily run a lot of instances of it (i.e. no graphic output). Run 50 instances of your bot on your local workstation and have them connect to the server.

When you notice that the amount of collision checks creates notable performance degradation, look into more efficient ways to pre-check. One useful method is to divide the game map into sections and only check collisions between objects in the same or in neighboring sections. Another is to store all your game objects in a spacial datastructure like an octree or 3-d tree which allows you to quickly iterate all objects in a given area. But keep in mind that while spacial datastructures speed up collision checks, they slow down movement because you need to update these structures whenever something moved.

By the way, you might notice that such a bot comes in handy for a lot of other kinds of test automation.

My game is working fine for now, but there's no real way to test with 50 players until people actually start playing.

There is. Just write a bot client for stress-testing your gameserver. While it is hard to write a convincing bot which behaves exactly like a real player would behave, it is usually not that difficult to write one which just logs in, joins a game and performs some simple automated actions to generate some server load. The bot should be simple and lightweight, so you can easily run a lot of instances of it (i.e. no graphic output). Run 50 instances of your bot on your local workstation and have them connect to the server.

_{By the way, you might notice that such a bot can be used to automate a lot of other tedious testing tasks. You could even go so far and implement a whole automatic integration test suit by having some bots play preprogrammed matches and check automatically if it still turns out the way it is supposed to.}

When you notice that the amount of collision checks creates notable performance degradation, look into more efficient ways to pre-check. One useful method is to divide the game map into sections, keep track of which section contains which objects and only check collisions between objects in the same or in neighboring sections. Another is to store all your game objects in a spacial datastructure like an octree or 3-d tree which allows you to quickly iterate all objects in a given area. But keep in mind that while spacial datastructures speed up collision checks, they slow down movement because you need to update these structures whenever something moved.