Not an issue, another question: Maze War protocol?

[marciot]

Josh,

Just curious if you had come across documentation or source code to Maze War. One of my side projects is a modern remake of Maze War in VR and I've toyed with the idea of having players step into a game between actual emulated Altos. I think it would be fun to have human players stepping into a game from the 70s and getting blown to bits by floating eyeballs.

So, yeah, any info on the protocol would be very much appreciated. I could try to reverse engineer it from packet captures, but any time not spent doing that would go towards me bringing my Tron-like vision to life :)

-Marcio

[marciot]

So it looks like Maze Wars transmits the state information packed inside the six byte payload of a pup packet of type 120. The information is packed in bit fields which are not at all aligned with bytes, and there are a bunch of bits which are zero that don't seem to change as the player moves around.

MazeWar PUP payload (six bytes):

ppp__yyy y__xxxxx ________ ______ff ________ ________
87654321 87654321 87654321 87654321 87654321 87654321

ppp = Player ID yyyy = Vertical coordinate 0-16 xxxx = Horizonal coordinate 0-31 ff = Facing direction

Perhaps the scores are packed in the zero bits? I don't know how to shoot someone yet, so I can't cause my score to increment.

[livingcomputermuseum]

Apologies for neglecting this thread. Yes, I've done some reverse-engineering of the MazeWar protocol (for version 3.4, at least -- not sure how it differs from 2.0 which is on the AllGames pack.)

For reference, you fire with the middle mouse button (you won't see a projectile).

I can send you my notes/code (it's ugly since I was just hacking around) on Monday.

• Josh

---

From: Marcio T. [notifications@github.com] Sent: Saturday, October 01, 2016 5:52 PM To: livingcomputermuseum/ContrAlto Subject: Re: [livingcomputermuseum/ContrAlto] Not an issue, another question: Maze War protocol? (#4)

So it looks like Maze Wars transmits the state information packed inside the six byte payload of a pup packet of type 120. The information is packed in bit fields which are not at all aligned with bytes, and there are a bunch of bits which are zero that don't seem to change as the player moves around.

MazeWar PUP payload (six bytes):

pppyyy yxxxxx ____ __ff ____ ____ 87654321 87654321 87654321 87654321 87654321 87654321

ppp = Player ID yyyy = Vertical coordinate 0-31 ff = Facing direction

Perhaps the scores are packed in the zero bits? I don't know how to shoot someone yet, so I can't cause my score to increment.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/livingcomputermuseum/ContrAlto/issues/4#issuecomment-250946911, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ATnJh1NlbWV-YswymE0bhr_8pN5Fnw18ks5qvwBGgaJpZM4KDjob.

[marciot]

Sure. I'd love to see what you have by way of protocol. I've just begun trying to make sense of it myself.

So where would I find mazewar version 3.4? The allgames disk pack tends to crash frequently with a disk full error (even after I tried deleting some files). I would try another if I had the option. Once I learn how to do so, I would really like to make a new disk pack with just maze war and make it boot directly into the game. But at the moment I have no idea how to create, format, or make disk packs bootable.

[marciot]

BTW, if you are interested, here is my Maze War remake just to give you an idea of where I'd like to go with this:

http://www.marciot.com/mazewar-vr/

This should work under Chrome. Hold down the mouse button to walk. There's no networking component yet, but when I add one, it would be cool if it were compatible with a version running on an emulated Alto.

[livingcomputermuseum]

Looks cool! One thing to note is that the original MazeWar had no visible projectiles -- you fired at an opponent and if they were in your line of sight, they were hit (nearly instantaneously).

Send me an e-mail at joshd@livingcomputermuseum.org and I'll send you my code and notes for the MazeWar protocol.

[marciot]

I sent you an e-mail on Monday. Did you ever get it? I think it was sent from "mlt4356-github@yahoo.com"

-- Marcio

[livingcomputermuseum]

Yes, apologies -- I've been out sick but I'll be able to take care of it tomorrow.

---

From: Marcio T. [notifications@github.com] Sent: Wednesday, October 05, 2016 9:28 AM To: livingcomputermuseum/ContrAlto Cc: Josh Dersch; Comment Subject: Re: [livingcomputermuseum/ContrAlto] Not an issue, another question: Maze War protocol? (#4)

I sent you an e-mail on Monday. Did you ever get it? I think it was sent from "mlt4356-github@yahoo.commailto:mlt4356-github@yahoo.com"

-- Marcio

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/livingcomputermuseum/ContrAlto/issues/4#issuecomment-251726245, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ATnJhy-K_lmhy0vwHpEMpJPOJtDAaEQlks5qw9AWgaJpZM4KDjob.

[marciot]

No rush. Hope you feel better soon.

[marciot]

It looks like Maze War version 2.0 broadcasts a really long packet of PUP type 100B. The payload is 242 bytes and it contains two recognizable strings: the first is "MAZEbob", which corresponds to the name I typed (bob); then later on in the payload it has "BootMesa.Scratch". Does this latter string mean anything to you?

This is part of the initialization/discovery packets. I can see from your program that you were only really looking at messages that would let you display a game in progress, and not necessarily trying to join as a participant, so I'm guessing you may not know, but I figured I'd ask.

Thanks,

-- Marcio

[livingcomputermuseum]

My guess regarding the “BootMesa.Scratch” is that it’s just uninitialized memory sent as part of the packet (i.e. the meaningful part of the packet is before that portion, and that’s just padding…).

So the bad news about MazeWar 3.4 is that I can only get it to run when netbooting it; copying the file (MazeWar.boot) to a disk pack and loading it using “bootfrom” does not work for reasons I don’t understand. I have an IFS server prototype that I’ve been using to netboot the emulator, and while it works with ContrAlto it probably won’t work with your Javascript port without some modification. The code isn’t yet to the point where I’m ready to release it, but I’m hoping to get it hammered out before the end of the year…

• Josh

From: Marcio T. [mailto:notifications@github.com] Sent: Thursday, October 6, 2016 7:51 PM To: livingcomputermuseum/ContrAlto ContrAlto@noreply.github.com Cc: Josh Dersch JoshD@LivingComputerMuseum.org; Comment comment@noreply.github.com Subject: Re: [livingcomputermuseum/ContrAlto] Not an issue, another question: Maze War protocol? (#4)

It looks like Maze War version 2.0 broadcasts a really long packet of PUP type 100B. The payload is 242 bytes and it contains two recognizable strings: the first is "MAZEbob", which corresponds to the name I typed (bob); then later on in the payload it has "BootMesa.Scratch". Does this latter string mean anything to you?

This is part of the initialization/discovery packets. I can see from your program that you were only really looking at messages that would let you display a game in progress, and not necessarily trying to join as a participant, so I'm guessing you may not know, but I figured I'd ask.

Thanks,

-- Marcio

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/livingcomputermuseum/ContrAlto/issues/4#issuecomment-252141400, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ATnJh9yuzUyTin10t4P2vYT82drSgipDks5qxbOSgaJpZM4KDjob.

[marciot]

Thanks for the hint on uninitialized memory. I hadn't thought of that and it was leading me down a wild goose chase. I know what the mysterious 242 bytes are: it is a player list.

It consists of four zero bytes (not sure what these are), followed by eight records of thirty bytes each, corresponding to one of the eight possible players in a game. Packed into the the thirty bytes are the location, direction, score and names of each player. Initially the memory is uninitialized, but as players join the game, the records get initialized one at a time.

As far I can tell, it seems like one machine is responsible for keeping the player list. I believe this is the "duke". As new clients come online, they send broadcast which causes machines which are dukes to reply with a player list. The client then chooses a game to join and sends a request to get added to the list; the duke accepts by replying with an updated player list.

So, this is the basic initiation protocol. I'm still working out the exact format in which the data is packed, but I think I'm pretty close to being able to write my own client.

[marciot]

Oh. It looks like the long packet I described above is a RatStatus in MazeWar 3.5. What's strange about MazeWar 2.0 is that it seems to use different pup types numbers than MazeWar 3.5 uses for the same packet. Perhaps they did this to allow multiple versions to run on the same network without interference, but it sure is annoying that I'm having to do a lot of extra work to decode packets before realizing they are already documented under a different id.

[marciot]

Closing this ticket as I got it all worked out to my satisfaction. My VR Maze War game can now connect to a legacy game running on ContraltoJS and vice-versa. The plan now is to wrap it up into a cool demo.