Since no one is actually talking about the code, I have some questions. Forgive me if some of them are naive; I haven't worked in C++ much.
1. Why is there no scripting engine? The point of a scripting engine is to decouple the actual scripts (language, framework, API) from the core code, and avoid a recompilation. What benefits did you see in removing it? As a follow up, you only have around 30 npc scripts; were there more when a scripting engine existed for Titan? If so how would you add the vast number of scripts that were present then or are present in Odin sources? Do you have any plans to write a language converter or transpiler?
2. I took a brief look into the code and didn't see many smart pointers - is there any reason why it's not consistent? You mentioned that you focused on performance and memory efficiency. Have you done any load testing and/or used tools like valgrind to expose memory leaks through high coverage scenarios? How can you support your claims? A consistent theme across MapleStory development is a lack of load testing tools to objectively analyze performance. Most people equate performance to memory consumption on startup, which is a highly flawed metric, and it seems like you've done the same without offering more detail.
3. I noticed the architecture/structure is actually very similar to post-RMI-removal Odin, but there are some peculiarities in where data is held. Why do you load all guilds and player names? Why are fame timestamps kept in the World server? How come online players are kept in the world, instead of in each channel? How do you efficiently send a message to only players in a certain channel?
4. I have not seen any synchronization in key parts of the code, like in packet sending and throughout Map. Am I mistaken here? If not, have you actually tested the implications of async writes per-client? I haven't worked with asio in a while, but do you have a write queue with a strand to handle this? What is the highest number of players you've had in the same map? If that number is 1-2, I expect to see a multitude of concurrency problems and unexpected behavior as that number scales.
5. I noticed in your drop expiry code you have a single task that runs every 8 (or 180) seconds that clears drops and respawns monsters. Unless I'm misunderstanding something, this does not have expected behavior, where each individual drop lasts for 180 seconds. Consider the case where the expiry task ran, and 5 seconds later, an item was dropped. In the next run, it would be there for 175 seconds and would not be removed, which means it actually stays on the map for 355 seconds instead of 180. Since the same Mob objects are used throughout the life of a Map, this will have race conditions because the code does not seem to be threadsafe, and still wouldn't simulate variable numbers of spawns from spawn points like in GMS.
6. I haven't dug into your wz loading code, but what benefits are there to load directly from the .wz files rather than another format (sql, xml)? Does the wz format have faster than O(N) lookups? What about the nx format, does that have faster than O(N) lookups? Have you explored it as a potential solution?
7. It is very unclear to me why all the packet handling code is in Player, even for login packets, even though the Player class seems to represent a logged-in Character object (with stats, guilds, etc). Is there any reason why you removed the "Client" abstraction and have this kind of implementation?
8. The PacketCreator usage seems a little disappointing; surely there is a better way to send packets than doing "PacketCreator packet26; ... PacketCreator packet37; ..." ?
Edit:
9. It also seems that there is no spawn delay for items dropped from monsters. Is this correct? The delay for dropped items need to match the duration of the monster's death animation. Is this anywhere in the source?
Thanks for your time!