Posted on February 04, 2017 at 14:19
Look at this thing:
See, I managed to write a working chat application! Woohoo! It did require a lot of work, mostly because I wasn't familiar with fancy concepts such as "multithreading" or "networking". Sure, I had had experiments with both these things, but I never succeeded to get these things working properly. Until now.
The server-side uses node.js. Reason(s): 1) Handling multiple sockets and receiving and sending data and such in C++ turned out to be a bit too difficult to me, so I decided to make my life easier and write only the client in C++. 2) I'm pretty sure it's easier to find good (virtual private) server that allows me to run node-js scripts than a server that allows me to build a C++ application and run it without too much hassle.
The client side is written in C++, like stated above, and it uses Sfml for networking and SDL for graphical interface.
I'm going to turn this chat application into a game one day. Maybe not a full game, but a game where you can move rectangles and see other people's rectangles moving. That means I have to add support for UDP sockets (the chat uses TCP). Sure, I could handle real-time game events data using TCP sockets if I found a good way to hide the latency, but... I rather not. Most games use both UDP+TCP/IP, so of course I want to be like "most games".
Since I'm using node.js in server-side and C++ in client-side, it means I have to write the game logic twice in two different languages. I'd better keep things simple, then.
The most important thing I learned while making this ultracomplex network application was multithreading: it's powerful and very, very useful technology, but also requires you to know what you are doing, or soon you'll find yourself blocking the whole program by misusing mutexes.
Nothing else this time,
try to stay alive until the next update (then you can die).