Interesting. I downloaded it and looked at it. It would appear that, at this point, Verge Online bears little relation to Verge2 or Verge3. Am I right in that? My impression is that it's a framework for online gaming but has not gotten to the point that it will do much or any interoperating w/ verge itself. It's interesting stuff and something that I hope could be continued!

Here's some more info:

The packet system was TCP based, but it assumed Nagle's algorithm would be turned off (normally, TCP automatically holds packets until you attempt to send a few in order to speed up overall effeciency, which is why a lot of twitch based games, like Quake, use UDP. For what we were attempting to do, the speed of TCP -Nagle w/ the advantages of TCP made it the better choice)

Each packet holds some basic info. Eventually an encryption system was going to be put in place, so it'd be easy to add one in, and you'd probably want to do that if you were ever going to use this with anyone besides your friends.

The packeting system was losely based on the Qauke system. There are four types of packets: System, Object, Event, and Text.

System packets were for things like connecting, authenticating, disconnecting, and pings (keepalives).

Object packets control the movement of objects (such as your avatar). This was kept separate from the event system so it could be optimized accordingly.

Event packets were for things like casting spells, or basically anything besides movement. We intended to include a very simple movementcode-type scripting language in it, so somewhat complex scenes of events could occur with just a couple of packets being sent, with no prior knowledge on the client end.

Text packets were for text communicating and announcements. Again kept separate from event packets so they could be optimized accordingly.

It would also grab text commands from the client and possibly interpret them as commands (svr_cmds.c)

Each map ran on it's own server instance, but the database (meant to be replicating) was aware of all the other maps, and could forward you to the correct server, so theoretically, the "starting" server that every client connects do didn't even need to be hosting any actual gameplay, it would just act as a directing service.

Each server instance had a separate thread to handle the gameplay world which was pulse based; it would process whatever it needed for the current pulse, and then sleep until it was time to process the next pulse. The possibility of missed pulses is taken into account.

Another thread would handle incoming connections, and another thread would handle all the actual client connections. I kept this as one thread instead of multiple threads because it saves system resources, and I've always been an FD_SET kind of guy.

All persistent data was held in the mysql database, but there wasn't much beyond maps and servers, and users and their "costumes."

The basic framework for npcs was barely built, but they don't have any sort of AI or do anything. It would be very simple to add in the wandering code from V3 to get them to start to do something, the system handles NPCs and game players alike.

Otherwise, there was an auto-updating engine which was the actual "vo.exe" on the client end, that would connect to the auto-update server. The auto-update server accepted simple text commands, and it compessed each file individually. The client could check each file by a datestamp and then determine if it needed to update each file, to keep the updating time to a minimum.

The config file parsing was done via lexx and yacc. Check out config.l and config_parser.y. They can look strange if you've never worked with them before, but it's essentially regexps with some extra rulesets. Overall very simple, but great at handling lots and lots of scenarios with minimum concern for all the "gotchas"

woo! mysql!

i'll download it later... i am actually thinking about developing an online cross platform isometric engine...

I might also look into this. I don't know if anything will come of my poking around, but I have some ideas.

Cheers. :)

--Arek