Egoboo Forum

[PurpleSquerkle]

Wasn't this started at some point?
It would be really cool if you can play Egoboo over the Internet / a local network.

[Maxaxle]

Yeah, that's the kind of thing that needs a whole huge server on the internet, like Nexuiz (a 1st-person shooter, needs an incredible graphics card to work well), or else a LOT of private servers-people who donate their computers to the network.
_________________
http://www.freewebs.com/maxaxle88/
Inventor class last updated: July 9, 2008
Download: https://sourceforge.net/projects/maxaxlesegoboos
FREE PIZZA TOMORROW

[bgbirdsey]

The problem with the online play is that Aaron did a bit of a kludge to get it up and running.

The old code may have worked over a fast LAN, but it was a nightmare even on 2 machines on the same ethernet subnet at the university.

I THINK the problems should be relatively easy to solve, and there are are a lot of basic network "engines" that we can use without haing to cone up with a unique solution.

This is probably on the back burner for a while, though. Zefz seems like he wants to work on pulling the modules together into a true game. I want to work on transferring the code over to C++ so it is easier to maintain. Jonathan has generally supplied a lot of useful infrastructure, like the GUI menu system. Maybe someone will come along to be the network guru?

[PurpleSquerkle]

Yeah, but couldn't we make it so you can temporarily set up your own computer as the server?
Because what I'm talking about is just playing with friends that live far away...

[Agent of Dread]

Yeah. But can't you only see the characters on your computer?
_________________
FACEPLANT

[Zefz]

I actually played egoboo on the internet once And over local area network But as bgbirdsey says, we need a networking coder who wants to wrap that part up of the code.. Which should be managable as we now have an SVN up.
_________________
http://egoboo.sourceforge.net

"The pen is mightier than the sword- IF it is sharpened, dipped in poison and thrown really really hard at your target. But seriously, you are better off with a sword."

[Maxaxle]

Wait, hang on! Last time I tried network play with my little brother, around 2.38 or something like that, I only ever got to the "waiting for players" screen where the players are standing in the world and doing nothing-and it must have frozen or something, because it didn't get anywhere from there. I mean, it was Zippy City with 2 G'nomes, when my little brother was only one digit away-the last one. You know, like:
XXX.XXX.X.XX_.
with the blank being that last digit. Stupid thing.

Zfez, you are SO lucky!
_________________
http://www.freewebs.com/maxaxle88/
Inventor class last updated: July 9, 2008
Download: https://sourceforge.net/projects/maxaxlesegoboos
FREE PIZZA TOMORROW

[Jonathan]

Warning long post OMGWTFBBQLOL!!!11!!eleventy-one!!

Aaron's original network code worked like so:

• Zefz and bgbirdsey want to play Egoboo online.
  
• Zefz starts a network game, and picks a module to play on. He tells bgbirdsey what his IP address is.
  
• bgbirdsey puts Zefz's IP address into his config.txt, and starts Egoboo. He joins Zefz's multiplayer game.
  
• Zefz clicks the start button. His computer then sends the module that he picked to bgbirdsey's computer. Every single bit of that module gets sent over the network. Most of the original modules are about 3 MB; a lot of the newer ones are bigger.
  
• Zefz's computer then sends the character Zefz is playing as over to bgbirdsey, which means the character and all of it's inventory items. That's another 300kb or so.
  
• bgbirdsey's computer then sends his characters back over to Zefz. Another 300kb.
  
• Now they can actually play.
  

Assuming both computers are still in sync and responding, which was iffy, the game then works by sending the players' input latches back and forth. It makes no attempt to make sure the monsters are doing the same things on both computers. During my tests, the players would be playing totally different games within half a minute or so.

So there are couple of major obstacles to getting proper, reliable network play in Egoboo:

• We need to avoid having to MBs of information between players computers. 3 MB+ for each player is ridiculous.
  
• The core gameplay logic of the game needs to be reworked to ensure multiplayer games can stay synced
  

There are two ways off the top of my head to avoid sending all that data. You can assume that both players have the correct module already, or you can adopt a global object registry, rather than a per-module object registry.

Assuming both players have the module in question is easier, but it can leave you open to weird bugs and to cheating. (I don't know if I care about that. ) That could be mitigated by some sort of CRC checksum on the module data.

A global object registry is better in a lot of ways. That means that instead of each module having an objects/ directory, you have one objects/ directory for the whole game, and modules link the game objects they need into the game in some other way. This would probably save a lot of space; at a quick count there are 693 object directories in Egoboo 2.4.4, but if you take out the duplicates there are only 330.

Half the space of an Egoboo installation is probably duplicated objects.

Anyway, with a global object system, rather than sending a copy of each object that's in a module (that the receiving computer probably already has 3 or 4 copies of), you only have to send spawn.txt, which will reference objects by name, instead of slot number. The slot numbering system would have to go bye-bye. Even if you still want to send the geometry of the level, you're down to an average of 550kb, which is about an 80% savings in the stuff sent over the network to start a game. If you can trust module data on both sides, you can cut the amount of bandwidth used for the module down to 100 bytes or so.

Making that sort of change would require some fairly invasive changes to the scripting system, and to the way modules are loaded and objects spawned. Once the new code was in place though, updating all the spawn.txt files could be fairly well automated.

The other problem is much harder to fix. The game code in Egoboo assumes it does everything. It has no concept of another computer doing any part of the gameplay updating. The gameplay code would need to be fundamentally changed to allow computers to cooperate in some way. I'm not even going to try and tackle the issues in doing that in a message board post.

So yeah, getting all the way to proper networked play is going to take a lot of work, and it might not be worth it. The effort it would take would go a long way towards starting a new game entirely.

Jonathan

P.S. - The number of objects in the game was determined like so:

[PurpleSquerkle]

Wow, that actually made a lot of sense to me; at first I thought a little thing like networked games would be easy, but now it seems like it'd be nearly impossible and probably not worth it.

But (and my knowledge of programming is severely limited so you may just laugh at this), could you make one computer handle everything using similar principles to, like, a "remote desktop?"
_________________

+ PurpleSquerkle

--My website--
Latest update= 7/15/08; Three new midi loops.

{new Squerkle coming as soon as I stop being lazy}

[Jonathan]

[bgbirdsey]

I think the key will be to factor the code so that the clients are like "dumb graphics terminals" and the server handles all the scripting and database. I've managed to factor the code this way a couple of times, but debugging it is a bit difficult without a couple of computers connected to a router...

SoulFu has tried to split the scripting and object ownership among different machines, so that in one room there may be 15 objects, one of which is controlled by user A, 10 of which by user B, ... I have never seen true peer-to-peer gaming protocol, but that seems like what it would look like.

[Zefz]

[PurpleSquerkle]

Oh, yeah; I've been thinking since the beginning "Why can't all the objects be in one place?"
_________________

+ PurpleSquerkle

--My website--
Latest update= 7/15/08; Three new midi loops.

{new Squerkle coming as soon as I stop being lazy}

[bgbirdsey]

I am working on this code at the moment, and I think Jonathan's comments are very valid. I have a way around those problems, though!!

[quote=Jonathan]Assuming both players have the module in question is easier, but it can leave you open to weird bugs and to cheating. (I don't know if I care about that. :Smile:) That could be mitigated by some sort of CRC checksum on the module data. [/quote]

I already have a 32-bit CRC-type endian-neutral checksum worked out, so that should be able to detect file changes.

[quote=Jonathan]The other problem is much harder to fix. The game code in Egoboo assumes it does everything. It has no concept of another computer doing any part of the gameplay updating. [/quote]

At the moment, I am planning for the scripting engine to run only on the server machine. The client would send delta latches for players only to the server. The server would send delta latches to all clients for ALL OBJECTS (instead of just players) would be sent over the net, with a client/server reconciliation happening about once every 2 seconds?

The transmission of position/velocity data in the reconciliations may have to be filtered so that clients that are far away from a certain object get updated on that object's info at a much lower rate...

[PurpleSquerkle]