[FaNToM]

does any of u guys know what is currently the best way to make a turn-based LAN game on MZX? ive tried it with the fwrite and fread commands over a shared documents folder, which worked, but would only be (at best) good for turn based games. would love to make a RTS for LAN on mzx. anyone know much on this topic?

[T-Bone]

This has been a on-going topic since the dawn of time and you will most likely get heckled for bringing it up again. But since it is brought back .......

This is something I've also been trying to work on for many years. I made an attempt using the save.mzx feature and then sending to player 3 via messenger. But of coarse this too would only be for good a turn-based game.

I have not played around enough with the fwrite command to see if its possible to write to it from two sources. If this can't be discussed on DMZX I may provide another location strickly for it.

Hopefully you dont get burnt alive for making this post

[FaNToM]

thanks t-bone6 i didnt know it was such a discussed topic!

anyway thanks. maybe someday i could make a Battlefield 1942 for mzx!! that'd be cool.

[T-Bone]

Cool indeed....

[Dr Lancer-X]

If Windows had named pipes, that would be a lot faster than temp files

unfortunately it doesn't, so the shared file route is the best you can expect to achieve.

[FaNToM]

thanks guys, yeah shared docs will probly be the only good way for this. oh and t-bone awesome screenshot! game in progress?

[T-Bone]

I wonder if anyone's actually successfully managed to get two sources to read and write from each other this way. Once i get my systems all hooked up I may try this to see if its possible.

EDIT:
That's actually a screen shot from "Blood in Berlin" a project put on hold

This post has been edited by T-bone6: 09 January 2007 - 02:25 AM

[CHEZZY]

I made a small lan engine that wasn't turnbased, but it was veeeeeery slow, and all you could do was move around.
I was also going to make a megazeux game called "lobby" where you can chat over lan. I got halfway then realised the default input string boxes were interrupting cycles and messages weren't getting through.
So far, all my experiences with lan in mzx have been futile, I think the only way to make lan succesfully in mzx is to add lan support in later mzx versions.

edit: I just realised I have four gems. Yay.

This post has been edited by CHEZZY: 09 January 2007 - 06:47 AM

[T-Bone]

The fact that you've managed to established a connect is amazing to me. Too bad its slow though. Do you still have that engine kicking around?

[CHEZZY]

No, but I got most of my ideas from a megazeux ds engine someone posted here on this site. It used fwrite/fread to send messages between two megazeuxes on one computer, all I did was put it in my shareddocs so it would work over two computers. With enough digging you could find that engine.

[Game master pro]

Koji did it once, it wasn't over lan, but if you opened up 2 different copies of mzx and loaded different files it went "Connection received". Great game that was.

[T-Bone]

I actually recall that.

[Koji]

you guys, sharing one file... is easy, you just have to think alittle about it... two instances cannot have the same file open for reading/writing at once.

SO

you have each instance of mzx continually try to open and read the content of the file into memory (a string read is the fastest) and then close the file so it's available for the next instance.

This way it's practically every [number of players] cycles you get updated content

[CHEZZY]

Yeah koji, I used that engine but I just put it in the shared docs along with a copy of mzx.

[T-Bone]

Is there any direct download for this?

[hob nado]

Sadly, the path of least resistance here is probably just to fork MZX with whatever kind of network capabilities you want it to have. Exo will take your firstborn children if you fork MZX, though.

[ajs]

This has been discussed time and again. You can't "just" add sockets support to MZX, to allow people to send and receive bytes. That's partly useful, and with all the file routines now, you could probably do some clever things with it.. but..

How networking in MZX would be best implemented wasn't just as a bit of robotic or a few magic counters. It should handle verification of worlds, authentication, perhaps some sort of sandbox API, auto-synchronization of players. Obviously for this to work you'd have to add multi-player support to MZX, or some funky robotic hacks. It's a lot more work than at first you might think.

Plus, it would be nuts if every game had to implement its own GUI for handling network connections, disconnects, chat, etc. That stuff should be done properly, inside MZX.

--ajs.

[hob nado]

Yeah, I was just thinking along the lines of a wrapper for a TCP or UDP socket, letting somebody push data around an int or a string at a time. Wasn't that pretty much all that was being considered in this thread, with the prior talk about doing basically the same thing with a shared file? I wasn't really thinking of the higher-level stuff like you mentioned, which, granted, you could do much more with. But who wants to implement any of that? =) I don't think MZX, at least as it is, really gets along with the idea of network play.

[Elig]

ajs, on Jan 10 2007, 03:42 PM, said:

This has been discussed time and again. You can't "just" add sockets support to MZX, to allow people to send and receive bytes. That's partly useful, and with all the file routines now, you could probably do some clever things with it.. but..

How networking in MZX would be best implemented wasn't just as a bit of robotic or a few magic counters. It should handle verification of worlds, authentication, perhaps some sort of sandbox API, auto-synchronization of players. Obviously for this to work you'd have to add multi-player support to MZX, or some funky robotic hacks. It's a lot more work than at first you might think.

Plus, it would be nuts if every game had to implement its own GUI for handling network connections, disconnects, chat, etc. That stuff should be done properly, inside MZX.

--ajs.

For the record, Cube doesnt even have networking code as complex as you're suggesting (Doesnt authenticate, doesnt verify worlds, doesnt auto synchronize, etc.), and it works fine.

Not that I support networking being added to MZX, I DONT. That's a bad idea that's been brought up over and over..

If you want to do LAN based stuff, a shared folder is definately the best option. If you want to do internet stuff, write a program in C that periodically reads a file and sends/recieves data from a server. Have MZX write to that file as needed. Infact, I think there are already a few free programs which can do basically that.

[ajs]

Elig, on Jan 10 2007, 10:19 PM, said:

For the record, Cube doesnt even have networking code as complex as you're suggesting (Doesnt authenticate, doesnt verify worlds, doesnt auto synchronize, etc.), and it works fine.

It authenticates, in that each player is an entity and has a name.

It probably does verify the map you're trying to join exists on your PC and that you are trying to play on the same map :-)

It will provide synchronization in the sense of a "world view". It will have data structures for distinguishing world objects that are in fact human players. It will have functionality that automatically keeps all the contributing players in sync with each other, compensating for lag, disconnection, etc. A Cube level designer doesn't have to worry about such things.

Imagine writing a Quake3 mod and having to handle the location of projectiles in every map or mod you wrote. It would be insanely wasteful and non-trivial, and that's exactly what reading and writing a socket in a MZX game would require. Every game would have to home brew its own implementation, and that's _really_ bad.

--ajs.

[CHEZZY]

I think I understand, if a player on the other computer shoots a bullet, you have to read exactly where the bullet is on your computer and relay it's effect on you back. And you have to do this with every bullet, or event, that will effect the players, over a slow connection. And then it wouldn't work because the event would have already occured but if you dodged the bullet and it already happened on the other computer... I don't know when the messages would stop. I don't even know what I'm talking about.

[Frobozz]

You're pretty accurate Chezzy. Except that you'd have to resort to using all robots or find a way to freeze the level. Not hard considering I think there is a freeze spell (Alexis sure did like her spells didn't she).

If the connection were DSL it probably wouldn't be so bad. But if it were dialup, you'd have to have each robot check if its data were transmitted or not and all sorts of headache stuff. Especially if you had to use counters.

[hob nado]

This is why you probably just wouldn't do these things in MegaZeux. Forget about 'em. I think if any network support were wedged into MZX, it wouldn't be best used to synchronize board states in an action game, but for something considerably lighter like relaying RPG actions back and forth, or card game events, or whatnot - game engines where time is not of the essence and there aren't a lot of objects flying around.

[T-Bone]

There's a game I've been working on for a while that uses a multiplayer feature. Its kind of like Heroes of Might and Magic, so its turned based. If mzx internet play is possible i guess it would be best for these types of turn based games whereas you not always checking for constant actions on both ends. More like check all of player 1's actions and then when his turn is done, check for all of player 2's actions.

[CHEZZY]

I think there is a way to write commands out as files instead of just fwrite. This would be far easier as the robot would just have to open the list of commands the other computer wrote instead of interpreting fwrites.

[Terryn]

Yeah, there's a way.

MZX Help File said:

SET "file.txt" to "SAVE_ROBOT"
SET "file.txt" to "LOAD_ROBOT"
SET "file.txt" to "SAVE_ROBOTn"
SET "file.txt" to "LOAD_ROBOTn"

These commands can save Robotic code to text files and import text files into a Robot. The first forms use the current Robot, while the second forms use the Robot with the given Robot ID n.

[Elig]

ajs, on Jan 10 2007, 11:46 PM, said:

Elig, on Jan 10 2007, 10:19 PM, said:

For the record, Cube doesnt even have networking code as complex as you're suggesting (Doesnt authenticate, doesnt verify worlds, doesnt auto synchronize, etc.), and it works fine.

It authenticates, in that each player is an entity and has a name.

It probably does verify the map you're trying to join exists on your PC and that you are trying to play on the same map :-)

It will provide synchronization in the sense of a "world view". It will have data structures for distinguishing world objects that are in fact human players. It will have functionality that automatically keeps all the contributing players in sync with each other, compensating for lag, disconnection, etc. A Cube level designer doesn't have to worry about such things.

Imagine writing a Quake3 mod and having to handle the location of projectiles in every map or mod you wrote. It would be insanely wasteful and non-trivial, and that's exactly what reading and writing a socket in a MZX game would require. Every game would have to home brew its own implementation, and that's _really_ bad.

--ajs.

First, and somewhat unrelated to the topic of this thread, Cube is very minimalist.

Cube doesnt verify that you have the map on your computer (If it cant find the map, it'll play on the map you're on instead), nor does it attempt to verify that the map is the same map (Which it may not be either through modification or through what I mentioned before. A "bug" the developers openly admit to). Cube doesnt have any mechanism for compensating for lag/latency. This means every time you're updated, you're seeing something that's a certain latency old. Cube doesnt attempt to compensate for this at all. Cube's server is nothing more than a multicaster, it doesnt handle player positions, collision detection, or player health. It barely even handles connects/disconnects. Like I say, it's a multicaster. It was designed this way intentionally, so that the networking code would be as small and simple as possible, and so that the server could run on virtually anything.

Anyway...

However, you have a point that in MZX networking, you'd definately need MZX to handle the data structures, you'd probably need a GUI for connection (Because I doubt every single game would want to create their own), you'd likely need to handle connections and disconnects internally, this means you'd have to have some messy interface for spawning multiple player or some such... The interface to the connection GUI would also be messy.

You'd pretty much have to either have every game creating their own buggy home brew networking support, or, you'd have to completely redesign MZX from the ground up. Both of which are stupid. And even if you had every game with their own buggy home brew networking, there'd still be a lot of behind the scenes work. You'd still have to keep track of recieved and outgoing information in MZX, which is no small project. Further, you may break some platform compatability, you'd also undoubtably introduce new bugs... There is absolutely no way to add it to MZX cleanly. I've never liked the idea.

[ajs]

Quote

Cube doesnt verify that you have the map on your computer (If it cant find the map, it'll play on the map you're on instead), nor does it attempt to verify that the map is the same map (Which it may not be either through modification or through what I mentioned before. A "bug" the developers openly admit to). Cube doesnt have any mechanism for compensating for lag/latency. This means every time you're updated, you're seeing something that's a certain latency old. Cube doesnt attempt to compensate for this at all. Cube's server is nothing more than a multicaster, it doesnt handle player positions, collision detection, or player health. It barely even handles connects/disconnects. Like I say, it's a multicaster. It was designed this way intentionally, so that the networking code would be as small and simple as possible, and so that the server could run on virtually anything.

Yeah, so cube is quite broken. Small and simple should not equal "badly designed", which it clearly is from this description. I don't think MegaZeux should ever model this design.

Quote

You'd still have to keep track of recieved and outgoing information in MZX, which is no small project. Further, you may break some platform compatability, you'd also undoubtably introduce new bugs... There is absolutely no way to add it to MZX cleanly. I've never liked the idea.

It's absolutely no small project. However it is doable. What I'm trying to discourage here are people hacking sockets into MegaZeux (which even the most novice programmer could do in a couple of hours). It needs to be properly thought out and a real infrastructure provided. That's why it probably won't happen.

And I totally agree with you, I don't really like the idea in a 2.x version of MZX.

--ajs.

[Elig]

ajs, on Jan 12 2007, 01:55 AM, said:

Yeah, so cube is quite broken. Small and simple should not equal "badly designed", which it clearly is from this description. I don't think MegaZeux should ever model this design.

Quote

You'd still have to keep track of recieved and outgoing information in MZX, which is no small project. Further, you may break some platform compatability, you'd also undoubtably introduce new bugs... There is absolutely no way to add it to MZX cleanly. I've never liked the idea.

It's absolutely no small project. However it is doable. What I'm trying to discourage here are people hacking sockets into MegaZeux (which even the most novice programmer could do in a couple of hours). It needs to be properly thought out and a real infrastructure provided. That's why it probably won't happen.

And I totally agree with you, I don't really like the idea in a 2.x version of MZX.

--ajs.

First of all, I think it's apparent you understand very little about modern networking code, so I am surprised you so readily offer judgments. Do your research before commenting.

Secondly, I agree with everything else you have to say

[ajs]

Elig, on Jan 12 2007, 02:37 PM, said:

ajs, on Jan 12 2007, 01:55 AM, said:

Yeah, so cube is quite broken. Small and simple should not equal "badly designed", which it clearly is from this description. I don't think MegaZeux should ever model this design.

Quote

You'd still have to keep track of recieved and outgoing information in MZX, which is no small project. Further, you may break some platform compatability, you'd also undoubtably introduce new bugs... There is absolutely no way to add it to MZX cleanly. I've never liked the idea.

It's absolutely no small project. However it is doable. What I'm trying to discourage here are people hacking sockets into MegaZeux (which even the most novice programmer could do in a couple of hours). It needs to be properly thought out and a real infrastructure provided. That's why it probably won't happen.

And I totally agree with you, I don't really like the idea in a 2.x version of MZX.

--ajs.

First of all, I think it's apparent you understand very little about modern networking code, so I am surprised you so readily offer judgments. Do your research before commenting.

It might surprise you to find that I've actually WRITTEN a network stack for more than one application! I also spent many years reading and writing Quake3 mods and hacked directly on the Quake3 sources, so I know _precisely_ why Cube's networking (from your description, which is probably entirely wrong anyway) is an example of a _bad_ network layer.

Thanks for flame baiting anyway. Nothing like unsubstantiated claims to start my afternoon.

--ajs.