When making a multiplayer game with 1000 people playing simultaneosly, should I use a thread for each player or is a single thread which does context switching fast enough?

when creating a thread for each player do jvm memory increases for same piece of code.

or single thread is enough for 1000 players ( avoid synchronization overhead in jvm).

also what non blocking threads with nio in java , are they better than blocking http threading model

Fixed the title to a more understandable one for ya :wink:

You should use threads where you need them and architect in such a way to avoid hard synchronization (lock-free) where possible.

See existing libraries for examples.

can u give me some links
for
hard synchronization (lock free)

and by architect ,do u mean thread pooling and thread caching (for large players)

https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/package-frame.html

I mean to design your game in such a way (using an ES, etc.) so that there is basically no locking and you can apply threads wherever they are needed.

Else we don’t have enough information because type of game, etc. is very important to this discussion.

“I have to carry 1000 items up a hill… should I use a bicycle or an airplane?” Depends on a lot.

Think of cpu cores as vans. Think of threads as people. Think of jobs as parcels.

Person 0 is the manager. The Game Logic thread. Thread zero.
I can have 50 parcels/threads going out today but only 4 vans. The manager always wants one van. He runs the show.

The manager can deliver most if not all on his own. When he cant, you need to start delegating your team. Never let the manager get over worked, that’s the key, and be careful with employing 500 team members with only 3 vans to use. Better to employ two or three to deliver all in an orderly and efficient fashion. Your manager is earning his pay. And not forgetting that others can’t modify other parcels without permission, etc… and so on.

I mean… that’s about as simple as I can explain it. I hope that helps you understand the complexities of multithreading.

If the dust hasn’t settled too much, I think each thread wants 1mb on the heap or some crap. It gets technical after my little story :stuck_out_tongue:

2 Likes

Much like the others here I’ll reiterate what they’ve said and give you some examples as to how the game could change things.

You really need to decide on what sort of game you’re making. That’ll define a lot of how you’ll handle users.

For instance.
First Person Shooter: All players interacting and firing in a single map all at once. Most likely you’ll be doing 1 thread per user in this case since they’re all doing things at the same time. But you’ll need to decide how to coordinate information between all of them since 1 character won’t just know where the other character is.

Turn based game (Civilization for instance): Although having a game of Civilization that included thousands of players would require amazingly patient players you’d probably do this in a single thread. Since you’re only handling 1 players moves at a time.

The above WILDLY simplifies what is involved but at least you can start to see where things can and will get complex.

I think an FPS is even less likely to be one thread per user because there will be a single physics thread (at least per zone) handling the physics.

Architecture matters a lot… more often than not, threads run in a different direction that a thread-newb thinks they will. ie: rather than giving one thread to each user, you give one thread to each distinct process… like in an ES, one thread per system. Networking gets two, physics gets one per zone, AI gets one, etc… or you pool them in that way.

Making sure some position updates gets where it’s supposed to go doesn’t necessarily require a thread on its own.

4 Likes

Definitely the airplane. In any case, no exceptions.

1 Like

Well, the “hill” is Mt. Everest in this case so I suspect there will be some logistics issues.

Well an Antonov can fit 1000 of most things and can go up to 10km high so the only question is where to get 1000 high altitude parachutes.

1 Like

It’s only a pack of plastic spoons.

I’d split the pack and make every plane carry one, so i can do this in 1/1000 time.

/multithreading

http://bit.ly/2OIksUl

5 Likes

Heheh… what a perfect example of what I was talking about re: threads going in the wrong direction. I like it.

I love it. :joy:

Psch. Just need 1 large Trebuchet to deliver those packages. Back to single threaded processing via medieval weaponry.

1 Like

can someone tell, what goes inside the thread stack, by default they use
320kb on windows.

This may sound a bit weird but you’re asking the wrong questions to get to the end result that you want.

From what I can gather you’re trying to make an MMO of some sorts. This is not a small undertaking by any stretch of the imagination but I wish you good luck and I look forward to seeing what you make! The memory stuff you bring up is something to be concerned with once you get to that point…

However…

You’re not at that point yet.

When it comes to making really big projects (or any really) it’s usually better to tackle the core features of what it is you’re making first… And make it efficient second.

If I were to order your project it’d go something like this.

  1. Make a super basic version of your game playable
  2. Make your game playable by a small group of people simultaneously
  3. Polish your game so it’d be something people would DEFINITELY want to burn hours and hours at
  4. Build a community
  5. Source a place to host this (Your home is not going to have a big enough internet connection for that sort of scale)
  6. Make your game playable by the thousands.

Notice that the questions you’ve asked though address points 5 and 6 more than anything. You should really start working on #1 more than anything else.

2 Likes

Is making community is the only way to test ur project for thousand players

No, you can mock players. Not like insult or anything. But build bots and stuff.

1 Like