Currently Im working on the monster system (hide/unhide/spawn/respawn) etc and I would like to know how the pro do this?

Currently I have so much code that I dont even know what I did nor do I have an overview anymore. And of course it is not working correctly.

Now I was wondering how the pro do this?

A game with 5000+ monsters per map.. A player log in but of course he should only load the monsters which are in a certain radius.

While running the server will check if near the characters are monsters -> true = unhide and false = do nothing.

And a second check for if monsters are too far -> true = unhide and false = do nothing.

Of course there is 1 big list with all the monster data and 1 list per player which contain the data which monsters are shown and which not.

But now what about the monsters which are dead? A third timer for them ? If the death time from a monster finished then he will respawn and everyone in the monster radius will get an input into his list that the monster is there?

If anyone could tell me "step-by-step" how the monster system should work? Like

- Player log in and only unhide the monster in his area.

-Timer to check players current position and unhide monsters if there are some in his area..

The more I work on this the more my brain starts to think different and I make everything more complex than it actually is...

Silfro, I hate to be the bearer of bad news, but considering this is your 3rd topic within a short period about creating an MMORPG, I think you've bitten off more than you can chew. I would scale back your game to either and open world RPG, or a small scale online game, like an Online FPS. This way you could focus on getting down either the RPG/Open World elements down or the online components down.

If you are stubborn here is the answer to your question:

Client Side (C#):

public void OnProximityListUpdate(BaseEvent evt)
	{
		var addedUsers = (List<User>) evt.Params["addedUsers"];
		var removedUsers = (List<User>) evt.Params["removedUsers"];
		
		// Handle all new Users
		foreach (User user in addedUsers)
		{
			SpawnRemotePlayer
			(
				(SFSUser) user, 
				user.GetVariable("model").GetIntValue(), 
				user.GetVariable("mat").GetIntValue(), 
				new Vector3(user.AOIEntryPoint.FloatX, user.AOIEntryPoint.FloatY, user.AOIEntryPoint.FloatZ),
				Quaternion.Euler(0, (float) user.GetVariable("rot").GetDoubleValue() , 0)
			);		
		}
		
		// Handle removed users
		foreach (User user in removedUsers)
		{
			RemoveRemotePlayer((SFSUser) user);
		}
	}

It shouldn't be too hard to replicate something similar in C++. On the server side, you want to be sending new updates to all clients with a list of NPC/User within a client's proximity.


That said, I truly believe it'll be more beneficial for you to work on a smaller project, otherwise you are gonna keep getting bogged done and eventually quit in frustration, because MMORPGs are perhaps the hardest thing to program and usually require a minimum of 20 or more programmers/designers/artists/writers.

Actually I already have client-side everything ready and I got the source from the client. Currently Im just building the server-side for this. I got all packets and everything I need.

I only need to write the functions like spawn monsters/items/damage etc

In Java I create a 2D arraylist as the map, and than only render what is around the player

I do not know how complex your game is, but here is some code that shows how I did the rendering offsets.

The rendering is done else were in another class - this method just builds what will be later rendered.

( Warning: Not The Best Written Code In The World )

public void outputMap(Player p){ // Build 'player areaa' to be rendered elsewhere
		
		String [] temp = new String[2];
		output = "|";
		int poX1 = p.getPlayerX() - offsetX; // Define rendering area around player
		int poY1 = p.getPlayerY() - offsetY;
		int poX2 = p.getPlayerX() + offsetX;
		int poY2 = p.getPlayerY() + offsetY;
		objects = new ArrayList<String>(); // Create dumps
		xlist = new ArrayList<Integer>();
		ylist = new ArrayList<Integer>();
		clist = new ArrayList<Color>();
		if (poX1 < 0){poX1 = 0;} // If player is near an edge ... 
		if (poY1 < 0){poY1 = 0;}
		if (poX2 > mapX){poX2 = mapX;}
		if (poY2 > mapY){poY2 = mapY;}
		
		for (cordX = poX1 ; cordX < poX2; cordX ++){     // Build arraylist that will be rendered later
			for (cordY = poY1; cordY < poY2 ; cordY ++){
				if (p.getPlayerX() == cordX && p.getPlayerY() == cordY ){
					objects.add(p.getPlayerSprite() ) ;
					xlist.add( ((cordX - p.getPlayerX() ) + offsetX ) * tile_size  ); // Offsets
					ylist.add( ((cordY - p.getPlayerY() ) + offsetY ) * tile_size );
					clist.add(Color.BLACK );
					
				}
			
				else{
					if (iomap[cordX][cordY] != null){ //iomap is one of the main map files for objects
						temp = iomap[cordX][cordY].getStates(); // Find out all the states the item has
						objects.add(temp[iomap[cordX][cordY].getCurrentState()]) ; // Dump the map object states
						xlist.add( ((cordX - p.getPlayerX() ) + offsetX ) * tile_size  ); // Offsets
						ylist.add( ((cordY - p.getPlayerY() ) + offsetY ) * tile_size );
						clist.add(iomap[cordX][cordY].getColor() ); // Mic info add
						
					}
				}
			}
		}
		scr.run(); // Start 2D rendering process 
 }

But now what about the monsters which are dead? A third timer for them ? If the death time from a monster finished then he will respawn and everyone in the monster radius will get an input into his list that the monster is there?

Dead monsters don't exist. There's no reason to spend any time processing dead monsters, to keep them in lists, or otherwise do stuff with them. It's dead. Passed on. No more. Ceased to be. It is an ex-monster.

You can have a separate list of _spawners_ that are stored on the server, but the client never ever for any reason needs to be told about spawners, their location, states, etc. They're a server-only detail. The spawner can track whatever state it needs for timers, knowing what state it's in, whether the monsters it spawned are alive or not, etc. When the spawner elects to spawn a new monster, it spawns it.

When a new networked object is created, it checks if it is within the AOI/radius of any players and if so subscribes the player to the object. When an object is destroyed/dies, remove it from any players' subscription lists. That's it.

You also really want some kind of spatial data structure for this. There's no reason to even _compare_ the distance of a monster and a player that are far away. A proper data structure will let you only even consider nearby objects when doing AOI tests.

Dead monsters don't exist. There's no reason to spend any time processing dead monsters, to keep them in lists, or otherwise do stuff with them. It's dead. Passed on. No more. Ceased to be. It is an ex-monster.

It could be semantics, but a dead monster should still be accounted for a certain time, to loot it's body, and to show it dead on the ground. After a certain time, it will be removed, and it's death would have triggered another monster's spawn timer.

So, what you're calling an "ex-monster" could, in some frameworks, still be a monster, just in the dead state. While I might make a new "deadmonster" entity, that might not be everyone's solution.

Actually I already have client-side everything ready and I got the source from the client. Currently Im just building the server-side for this. I got all packets and everything I need.

I only need to write the functions like spawn monsters/items/damage etc

That seems quite backwards to me. For a multiplayer game, the server should be the core of the system. It's the brains and heart. It does all the heavy lifting. The client really should be little more than a window into what's happening on the server. So... how exactly do you install windows into a house that hasn't been built yet?

Dead monsters don't exist. There's no reason to spend any time processing dead monsters, to keep them in lists, or otherwise do stuff with them. It's dead. Passed on. No more. Ceased to be. It is an ex-monster.

It could be semantics, but a dead monster should still be accounted for a certain time, to loot it's body, and to show it dead on the ground. After a certain time, it will be removed, and it's death would have triggered another monster's spawn timer.

So, what you're calling an "ex-monster" could, in some frameworks, still be a monster, just in the dead state. While I might make a new "deadmonster" entity, that might not be everyone's solution.

I would argue that this is non-ideal design. There's so many differences between a living monster and a monster corpse that they really should be separate objects. Especially in a component-based engine. There's data and run-time state a living monster needs that a dead one doesn't (like AI) and likewise state and data a corpse needs that a living module doesn't. The physics states are different, graphics may be different depending on the graphics style, and the events the object must listen to are different. Some designs call for extremely radically different setups, too, like per-player loot in some games.

Ultimately, while a single monster object with two states works, and I do recommend going for the simplest design that works, I've never found having one object with two radically different states to be all that simple.