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.

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.