Tkblackbelt's Dev Log

[tkblackbelt]

Hi Guys,

I've started working on another Conquer Online server (patch 4276) to improve my Elixir programming skills. I will be updating this thread as I make progress. My main goal of this exercise is for learning, so this server may never go live. However I would like to get it to the point of going public so I can do some benchmarks and stress testing.

Tech Stack
-------------
- Elixir (Programming lang)
- Erlang (Programming lang)
- MySql
- Ecto (ORM)

Tasks done
--------------
- Authentication Server
- Script to convert MySql schemas to Ecto Models
- Login to game server


One of the cool things about Erlang/Elixir is it's built in support for handling binary data. For example the code below shows the decode function which uses pattern matching to know which decode function to call, and uses the binary syntax to parse the values. Looks beautiful to me!




The Auth Server is setup using a bunch of processes operating concurrently. These processes are setup using a supervision hierarchy. If a child process crashes the supervisor re-starts it!



Anyways, I'm starting the initial game connector application. Still deciding how I want to structure it.

That's all for now,
Chuck

[Hacker.]

Name change idea P4Ns Dev Log

[turk55]

I don't know if you have seen it or not but you have 'requst'in your model

[tkblackbelt]

Originally Posted by turk55

I don't know if you have seen it or not but you have 'requst'in your model

Haha I noticed&fixed that right after posting the image.

[tkblackbelt]

Update.

Finished the initial connector_server setup and map_server. I'm now able to login using an existing character, or create a new one. I'm really impressed with Elixir as I've written way less code than I was expecting for the features I've implemented. Please poke holes in any of my design choices below. I'm open to any constructive criticism.



Below is the current structure of the project. I have split the server into multiple application components.

Common: Common code that can be re-used between projects (Packets, Helpers, Encryption, etc)

game_server/connection_server: Application for handling client connections and state. Multiple connection_server's can be spun on different physical servers if needed

map_server: manages maps under a supervision hierarchy. The server spins up a single process to handle each map. When the server starts it queries the map table to know which maps to host. It then registers itself as a global process to allow map processes on different physical server to communicate! When the server boots up I have a setup script that interconnects all available servers.

The cool thing is I can treat each map process as if it were a local one. I simple call GenServer.whereis {:global, :"1000" } and it will return the PID of the process for me to communicate with it.

I'm also deciding how I want to split the maps into sectors (so messages/packets are only sent to objects that care/are in view of). I was thinking about having processes under each map to handle each of its sectors.

npc_server: This application will be used to host all NPC's





This image below gives a overview of how I'm designing the server. Essentially you can host everything on a single server or split the applications into the different servers to enable further scalability. Obviously a CO private server will never need this kind of scale, but I'm doing this as a learning exercise

Components:
- One or more connection servers (Handle Client Connections & state)
- A database server
- One or more world servers which can host one or more maps.


See you guys next update

[tkblackbelt]

Small update. I have gotten the Map Server working. The world supervisor spawns a global map supervisor for each map stored in the database. Since the map is global it can be accessed from all connected nodes in the cluster. The map supervisor then reads in it's respective DMAP file, and determines how to split up the map into sectors. The dmap bytes are then spliced and passed into it's related sector process. The sectors are responsible for managing the state & view of a small chunk of the map.

if a sector crashes the supervisor simply restarts it. I'm storing map state in an ets table (in memory) so if a sector restarts it simply pulls it's previous state (mobs, items on ground, etc) and continues as normal. The clients won't notice any blips.

When the client connects he sends a message to the map asking what sector I he's on. The map responds with the sector and then the client subscribes to that sectors events. In the event of a client changing sectors the sector forwards a message to all nearby sectors asking if the client now belongs to them. The new sector then re-subscribes the client the that sector for it to handle the events.

The cool thing about splitting out the connection and map server is that I can literally make live code changes to the map while the connection server manages the client connection. When I bring the map server back up the client simply starts sending messages again. Cool!

My next steps are to start publishing jump, chat, etc events to other connected clients.

[spaghettiCoder]

By splitting map in sectors you reduce time that server have to spend in make mob events and such?

[tkblackbelt]

Originally Posted by spaghettiCoder

By splitting map in sectors you reduce time that server have to spend in make mob events and such?

Exactly. If a client jumps then that event only needs to be broadcasted to whatever is in that sector (mobs, player, etc). This drastically reduces the amount of internal messages being sent between actors(elixir/erlang processes) as the client process isnt receiving messages it wont be forwarding to the client anyway

I will have to play around with it because if two clients are technically in different sectors but still in view of each other, ill have to publish the event to both sectors. Ill probably add some publish code that checks if a client is at the edge of a sector and forwards the packets to the sector beside it. I think that will work.

[pro4never]

Originally Posted by tkblackbelt

Exactly. If a client jumps then that event only needs to be broadcasted to whatever is in that sector (mobs, player, etc). This drastically reduces the amount of internal messages being sent between actors(elixir/erlang processes) as the client process isnt receiving messages it wont be forwarding to the client anyway

I will have to play around with it because if two clients are technically in different sectors but still in view of each other, ill have to publish the event to both sectors. Ill probably add some publish code that checks if a client is at the edge of a sector and forwards the packets to the sector beside it. I think that will work.

You are best querying sectors that intersect with the viewable rectangle of the clients screen. Assuming 18x18 is your sector size same as view range then your entire map poses relatively few iterations to query relevant sectors. If you're using a full spatial partitioning setup that scales with object count then it's even less (although your new bottleneck becomes moving between sectors and expanding/collapsing them)


@edit: not suggesting you iterate every sector was just meaning to remind you may need multiple sectors (if you're in a corner you need to return 4 sectors total and then query those for objects within 18x18 of your actual object)

[tkblackbelt]

Client to client jumping & movement complete. At the moment the sector size is just set to 18 x 18 and when the map_server creates the sector processes it passes which sectors are next to it.

[tkblackbelt]

Hi,

Wondering if you guys can give me some advice. I have an issue where the client is disappearing if I move one client away from the original spawn point and then move the other over to where he moved. The clients then start sending the General Packet subtype 162 (Entity spawn) to which I'm replying with the entity spawn packet of that client. This still does not cause the player to show on the screen.

My code is working as follows.

1. player comes into the render distance -> entity spawn packets are exchanged
2. player leaves another clients screen -> General Entity Removal packet is sent to both for client removal
3. I move one player further down the map
4. I move the other player down the map and into view of the other player
5. Both players don't render and send 162 general packets.

HEre's a video of the problem



Thanks

[Spirited]

That's not how you handle Conquer Online's screen system. If you're going off of other public sources, they're going to screw you over. Look at Phoenix for the correct implementation. You should never have to send the removal packet unless they actually disappear from the screen (and not walk or jump out of screen). Same with monsters and what not - it just creates huge amounts of unnecessary server stress.

[tkblackbelt]

Originally Posted by Spirited

That's not how you handle Conquer Online's screen system. If you're going off of other public sources, they're going to screw you over. Look at Phoenix for the correct implementation. You should never have to send the removal packet unless they actually disappear from the screen (and not walk or jump out of screen). Same with monsters and what not - it just creates huge amounts of unnecessary server stress.

Yeah, I'm going off another public source for packet structs & some logic. I will take a look at Phoenix. Thanks for pointing that out, its way simpler not having to handle removals!

[Spirited]

Originally Posted by tkblackbelt

Yeah, I'm going off another public source for packet structs & some logic. I will take a look at Phoenix. Thanks for pointing that out, its way simpler not having to handle removals!

Had to bring up my old signature, but I found where I talked about the screen system in the past -> .

[tkblackbelt]

Originally Posted by Spirited

Had to bring up my old signature, but I found where I talked about the screen system in the past -> .

Thanks for that! I just realized what I did wrong, I missed sending the jump packet back to the originating client so it thought that it was still in it's original position. Can't believe I didn't notice that