Got another small update for y'all regarding the C++ WebSocket server I posted about earlier.
MSGHero asked how the thing I talked about in that post would help in making games, and, basically, by itself it doesn't do a whole lot (it just implements the WebSocket protocol), which is why I've been hard at work implementing features to make developing networked games very easy.
As of writing this post, I have authenticating with the Newgrounds API working, as explained on the wiki, which allows you to guarantee that a person connecting is logged in and actually is who they are claiming to be. That can be disabled if you don't need users to be authenticated, although any users who play the game will still send their NG info to the server (players not logged in will just be recorded as "Guest" or something to that effect).
In short: the authentication means that when a user connects you will be given their username and userid in a Player object, and possibly some other information pulled from their profile (e.g. if they are a supporter).
I am also working on an event messaging system to simplify communication between the client and server. Given that the server is written in C++, it has all the drawbacks that C++ has (duh). Most notable being that C++ is statically typed whereas JavaScript is not, which can make parsing JSON sent from a JavaScript-based client a little bit tricky. The solution I came up for this is to allow you to define event handlers by a given name, which are tied to a function, and their expected parameters; meaning that you can, for example, define an event called "chat" which expects two parameters: target and message, both of which are strings.
So, basically, a client can send JSON data such as {"type":"chat", "to":"Diki", "message":"You suck"} and the server will receive it, parse out the data, see that it's a "chat" event and that the given parameters match what are expected, and will call the defined function and pass the parsed data. If, for some reason, the client were to send {"type":"chat", "to":42, "message":"butts"} the server would reject the event because the "to" field is expected to be a string, not an integer.
Here is a very basic example:
int print(newgrounds::Player player, newgrounds::Payload data) {
std::cout << data.gets("message") << std::endl;
return 0;
}
int sum_numbers(newgrounds::Player player, newgrounds::Payload data) {
int result = 0;
for (auto i : data.getvi("numbers")) {
result += i;
}
std::cout << "Sum: " << result << std::endl;
return 0;
}
int main() {
newgrounds::events::add("print", print, {"message:string"});
newgrounds::events::add("sum", sum_numbers, {"numbers:vector<int>"});
newgrounds::set_port(5000);
newgrounds::set_secret_key("YOUR_SECRET_KEY");
newgrounds::start_server();
}
Most of that should be self-explanatory, but here's briefly what's happening:
- The secret key is your unique publisher key (I'm not really sure where you go to get this, but I got mine by PMing PsychoGoldish). It's required to authenticate users.
- The stuff in the brackets in the events::add function is the expected parameter names and types. There isn't any limit to how many expected parameters you can define.
- The data.gets() and data.getvi() functions are converting the stored data into what you require. There is no way to get around having to do this because of the nature of C++. Basically, the function names are short for get_string and get_vector_of_ints.
- The return value of the two event functions is used to denote the result, or, in other words, whether there was an error. A value of 0 represents that there was no error, as is the standard in C/C++. The returned value will be sent to the client that sent the payload data, so if there was some problem, the client can be informed.
All of that code I currently have working, but it's very messy and not finished, nor have I done any unit testing, so I won't be posting any source code just yet. I do have the WebSocket server source code on GitHub, as it's pretty much finished (other than some very minor things I plan on changing which won't affect any functionality).
Anyway, that's all for now.
I hope to have this finished, or at least in a usable state, by the end of the month. I'll be designing it such that anyone with a beginner to intermediate understanding of C++ will be able to use it; I'll be hiding all the tricky and mucky asynchronous networking function calls beneath the API, so all you'll see is pure sex.
I'll also be writing some basic code for the client-side so that you won't need to write any boilerplate code to use the server, but I haven't started that yet because it's not pertinent.
Hopefully someone will actually read all that text and/or be interested in using this.