Using the AD multiplayer system for a different, very similar game

[martinwguy]

Hi!
When I was about 15 I wrote a video game Wrap Trap on a Research Machines 380Z.
Though it is almost exactly a 2D version of the Light Cycles game in the film Tron,
it was written before the film came out.
Now, I'd like to reimplement it in SDL2 but want it to use the armagetronad
multiplayer game engine to be able to play it with people over the network.

Are there any docs on talking to the armagetronad game server?
Does anyone know where in the code is the top of the bit that lets
the game engine talk to the multiplayer game server?

In the meantime I'll implement it curses with two players on one keyboard.

Thanks!

M

[aP|Nelg]

This is quite tricky. This game is quite a bit more complicated than it first appears in a local game. Are you trying to make a server or a client, or both? Making a client that connects to Armagetron servers is quite bit easier than making a server that Armagetron clients can connect to. And are you trying to imitate the physics of Armagetron in any way? If you are not copying Armagetron physics, then it probably wouldn't be worth trying to make it compatible with this game as it will not be playable if the server and client are not following very similar rules.

Either way, a good starting point for understanding the core of how to connect to an Armagetron server is tools-php-client-trunk-work on Launchpad. This has most of the basics. I used that to work on another project that was essentially a client acting as a chat-room, but there is also some stuff in there for receiving and syncing stuff essential to receiving game-play elements. This application doesn't actually need those, but at least being able to receive gGame syncs and notifying the server that we are in the same state is nice for other players as the server no longer is waiting for us to become ready. WIthout that, it will hold up the start of every round. And, if you want to be a real client, the server will not send game-play objects like cycles and zones without it.

There are other projects related to this game I could talk about and share if you really want to proceed down this road, but what I've already mentioned should hopefully already be a good starting point for compatible net-code.

[Z-Man]

If you really, really want to, the network subsystem in the game is a library you can use, along with the tools library. There should even still be demo code in there, in src/network/l2_demo.cpp and l3_demo.cpp. There is some documentation in doc/net.
BUT YOU REALLY SHOULD NOT. The code and the C++ standard it was developed against are over 20 years old. Other network libraries are easier to use, more flexible, and probably perform better. This one, for example: http://enet.bespin.org/, it handles the hard bits, sending and receiving data on multiple channels, and leaves it to you how you fill and parse the message packets.

[Lucifer]

I wrote a basic game network library in python. I used it for my cluster for awhile, but I stopped working on it when I realized I really needed it in C++, because python was just too slow (although the newer python is probably fine, since it's properly implemented threads, or so I hear).

It's not real difficult to write the basic backbone. You just need some queues for incoming/outgoing messages. You parse out the header so you know what kind of message it is and stick it in a queue for the main program loop to read when it gets to it. You can write it multithreaded (preferred) and have the network polling/sending in its own thread, or you can go old school and give it a function/method to call during the main program loop.

You'd implement some basic message handling here, like pings and stuff to maintain the connection. Your login/logout handling would be there, too, although if you want a more complex authentication system, you'd have more issues to solve.

You can use google's pmessages or whatever it's called to do the parsing/packing for messages, and it's really sweet, but it's not necessary. I used callbacks in message objects and created an attribute system so that 99% of messages could be packed and parsed by the library itself, no need to write custom packers/parsers, but the callback system allowed for that.

I still have it somewhere, but it is all in python.

[delinquent]

Python is never fine. Python is what people use when they need a quick and dirty solution.

Unfortunately Python is also all up in most linux distributions, improperly namespaced, and improperly isolated, meaning that people have to create special environments just to use it, or risk borking their OS. It's a shocking state of affairs, perhaps even more so than the size and resource hunger of Plasma.

It's why I'm (slowly) rewriting Rinzler in dotnet. It's not a huge performance improvement, but it *is* properly namespaced and isolated, and won't break an operating system.

I really gotta learn some more languages. I should be writing it in Ruby or Rust or something, but I haven't the brainpower to put to it at the moment.

[Monkey]

I'm a bit late to the party but heyho.

You didn't state what language you used to write your game initially. It would be both nice and helpful to know. (I'm guessing BASIC, ASM or, less likely, C?).

You say you want to rewrite it in SDL2 but you should know that, 4 days ago, SDL3 was just released as stable, WOOHOO!
So, use SDL3, not SDL2, it's way better! Also, for the rewrite, C > C++ (Im guessing if you can program with curses you know C).

Also, I'm just checking that you know about SDL_net v3, which is capable of doing basic things with UDP datagrams:
https://github.com/libsdl-org/SDL_net/b ... /SDL_net.h

As Z-Man correctly states, don't use code from this game, it's old and, erm, not always ideal to use, I will say.

But yeah, either use the library that Z-Man recommended or check out what other fast-paced open source games use.

Just out of interest, what system/platform/OS are you on nowadays?