Robin

I think you're confused as to what the 'listening' part of your code is doing. Lidgren is already multi-threaded under the hood. It handles all of the messy read head, piecing together, buffering etc. and leaves you with a cute little collection of packets to process at your leisure! You do not have to do anything to allow this to happen. What you're doing in your loop is polling the packet collection. You're asking lidgren if it has any new fully-formed packets for you to process. You do not have to do a polling loop. This is just the de facto method due to most games already having a main loop. If you do not already have a main loop, it might not be for you. Instead, you'd want something that compliments the winforms-style event loop instead. You can see the different methods of consuming incoming packets in lidgren in their developer's wiki. https://github.com/lidgren/lidgren-network-gen3/wiki/Receiving-Messages If you do not understand when you should use threading you should not be trying to use threading. It is an advanced concept that is absolutely not required for the majority of projects, especially something like a game.

This is incorrect. If you can't process more than 30 players, the problem is absolutely in your code.

Try not to get too caught up in encapsulation exercises in game development. Strict object hierarchies are always going to end up causing problems. Why should all entities have stats? Or vitals? Why should entities that have vitals have stats? Instead, you want a system where you can build entities through composition. Entity-Component-System is a pretty good example of this. Entities are your game objects - they have no real state by themselves until you start adding... Components are your 'data'. They define the state of the entity. These can be processed by... Systems are where the majority of your game logic go. These register interest in entities based on their component composition and pull/push data between them. In your specific example, anything that inherited from 'Entity' would be forced to have a bunch of stuff that might not be required. Worse yet, you'd start having to have all kinds of identifiers to dictate behaviour, or what systems that entity should be processed by. Here's what your code could look like in the context of an ECS: class CombatStats : Component { public int strength; public int endurance; public int dexterity; } class CombatVitals : Component { public int health; public int mana; } class CombatScene : Scene { // create a player entity var player = createEntity(); player.addComponent(new CombatStats()); player.addComponent(new CombatVitals()); // create an attackable object var something = createEntity(); something.addComponent(new CombatVitals()); // create a system that registers attacks addSystem(new CombatSystem()).registerInterest(typeof(CombatVitals)); } class CombatSystem : System { void process(Entity entity) { // get the stats of the entity attacking us combatStats = entity.attackedBy.getComponent<CombatStats>(); // do damage to our vitals combatVitals = entity.getComponent<CombatVitals>(); combatVitals.health -= combatStats.strength; // check if we've died if (combatVitals.health < 0) entity.destroy(); } } With no strict link between vitals and stats, you can re-use them in other ways. By using systems which register interest in entities based on their composition, you can easily register/deregister entity functionality by simply not adding systems to a scene, or by having more specific composition matching patterns. For example, we've created an entity that has no stats but can be destroyed because it has health. Likewise, we could easily just not create the combat system and disable combat on that scene/map. There are the de facto standard in game development now, so if you're starting off a new project I'd suggest you read up on it a bit. I haven't looked back since using this type of architecture. Further reading: Understanding component-entity systems Entity-Systems Wiki Introduction to entity systems Refactoring Game Entities with Components Component Based Engine Design