The Faucet Networking extension aims to provide a sane low-level networking API for multiplayer games. You could probably summarize it as "a better 39dll". Not in the sense that it can do more (not at first anyway,) but in the sense that it's easier to use and easier to learn.
[Rebound is] my first foray into online programming. I am making the game in Game Maker using the Faucet Networking Extension by the guys that made Gang Garrison. It has been wonderful to use and has been really fun. -- Sean A.
What's cool about it?
- Easy to learn and use
- Completely nonblocking
- IPv6 support
- Detailed documentation of all functions
- Support for little-endian as well as big-endian byte order
- Very permissive license
The extension now supports TCP and UDP in the latest version.
If you need a feature for your project that this extension doesn't provide, feel free to ask and I'll try to figure out the most sensible way to make it possible. Keep in mind though that the focus of this extension is on low-level networking, so please do not ask for things like functions for HTTP or IRC.
Most recent release
You can download the most recent release here (V1.4.2, released on 2012-11-14).
The most recent source code is always available in the repository at Github.
You might find more up-to-date information at the ganggarrison.com forum thread
Did this extension help you and you want to give something in return? If yes, you can Flattr me.
TheCrazyGameMaker has created a screencast that walks you through creating a small TCP networking game with Faucet Net.
The main download also comes with two example programs, and a help file which explains every function of the extension in detail.
What's wrong with 39dll?
(Alternative title: A combined 39dll rant and short history of Faucet Networking)
For many years, 39dll has been the most popular networking library for Game Maker by quite a comfortable margin, and it has enabled many projects to implement their networking code. However, that does not mean it is a good library. It isn't. Maybe 39dll became popular because it was the only real option for a while, but that is not true anymore today. Using a more modern library like Faucet Networking will spare you some unnecessary headaches. But you don't have to take my word for that:
I don't know what Faucenet is (my guess, a new and much better networking lib) but I definitely recommend using it over [39dll], which I wrote when I literally just started programming in c++ />.
I'm always surprised to see that it is still popular, as it is very poorly coded.
So what is the actual problem with 39dll, and why did I start writing Faucet Networking? To better appreciate the motivation behind this project, you should know that I have used 39dll in Gang Garrison 2 for a long time, and finally grew tired of the hoops I had to jump through to perform the most basic tasks. In many cases, a task would seem easy at first, but then in some corner cases the easy solution would make my game freeze or misbehave, so I had to add code to deal with those corner cases. Suddenly, the solution wasn't so easy anymore, and I had spent hours on tracking down unexpected networking problems that could have been spent on inproving the gameplay.
A simple example is sending some bytes of data from a game server to a client, over an existing TCP connection. You will (and should!) probably expect that this is easy to do in any networking library. Naturally, you want all the bytes to eventually arrive at the client (unless the connection breaks). But you don't want to wait until the data is sent - Your game server needs to run (e.g.) 30 steps per second, and there is no way to tell how long the sending will take. Usually it is immediate, but it can take seconds in some cases, and you don't want your server to freeze for that long (or at all).
However, to do this properly with 39dll, you need to manually store the data that can't be sent immediately, and try resending it every step. You also need to handle specific return codes of 39dll functions which are completely undocumented, so you basically need to read the 39dll source code and cross-reference with the Winsock reference. All this adds up to a rather large block of GML code you have to write.
Faucet Networking on the other hand just accepts all your bytes without blocking and sends them in the background, so your GML code can do more interesting things. If you want details on this example, read on here - I didn't want to clobber the first post with too many details.
Receiving data has a similar problem. In the usual case where you know exactly how many bytes you need next, you have to take precautions for the case that some data is available, but not as much as you asked for.
Gang Garrison had a couple of scripts to provide a more convenient way of doing common tasks, but not every problem could be hidden this way, and some things - like the ever more important IPv6 support - obviously can't be done in GML alone. So I decided to take a deeper look under the hood of 39dll and add some tweaks. That was the initial plan at least. Working through the 39dll source code though, I realized there were more problems than just a clunky interface. 39dll has bugs. It leaks memory every time you delete a buffer or socket. It has hidden limits: if you try to read more than 20000 characters with readchars, there's an internal buffer overflow. It relies on undefined compiler behaviour: if you recompile it with gcc, simply calling writebyte(1000, buffer) will crash your game.
I realized that instead of trying to fix the problems, it would be more profitable to develop something new, starting with the question what a game programmer actually needs, based on my own experience with the development of Gang Garrison 2. The focus was to make the API as easy to use as possible, even if that meant the library would be more complicated to develop. I tried designing the API functions in a way that made them intuitive, and robust against errors and wrong usage.
When I had developed the extension far enough that it was able to replace 39dll for Gang Garrison, I did exactly that, and it was satisfying to see how much it simplified the code of the game in some places. However, I found that it still required too much work to do some common tasks, so I went back to the drawing board and revised several decisions to iron out the creases.
The result is a library that is easy to learn and use, and that gets common tasks done with a minimum of code and effort. I hope you will find it useful.
Edited by Medo42, 16 February 2013 - 04:57 PM.