Hi, and welcome to the first progress report for NeREIDS.
As of now, this blog is just a couple of days old. A couple of days during which I had to learn what blogging was about, and trying to set up my CMS. But I’ve been coding parts of the foundations for NeREIDS for much longer than this. Here is a recap of what I coded up to the date this blog was created, for you to catch up.
Most of the stuff I have coded now is just a skeleton for a game. Not even an engine yet.
There’s obviously a lot of work to do. The question is : what to do next ?
One popular (as in, often cited) development philosophy is :
If I want to abide to this rule, I obviously do not want to continue building up tools (half of which I’m not even sure I’m gonna need) and get right to the heart of it.
Rule 1 – From now on, tooling is only allowed as part of the development of interactivity, gameplay, and new features.
I want my first interactive piece of in-game situation to be a character, controlled by the player, evolving around some piece of outdoor environment. Rendering such outdoor environment seems tempting as a goal for the next milestone. But with NeREIDS, I need to break from my habit of starting a game project by displaying some mesh for the terrain first. It translates to “stop trying to make a rendering engine, and this time, try making a game”.
I’ve stripped the client from all the various code I had while testing the GUI components, and reverted its starting state to simply displaying a placeholder background image.
So, what is the next logical step towards seeing something nice and hopefully interactive ?
Well, the answer lays right in the synopsis for NeREIDS : It is meant to be designed as multiplayer, from the ground up.
Rule 2 – every in-game entity on which the client operates needs to be spawned from the server.
Oh, that does not mean the client should be a totally dumb input and rendering terminal. It may very well be able to run similar code than the server – and even perform pretty complicated tricks – to compensate for latency, for one. But the client cannot decide to spawn a character if the server did not tell him to, and the character control mechanisms will keep in sync with the server authority, right from the start.
I need to code some networking stuff. The good side is, this code is already planned for, right in the Network library.
A few years ago, I stumbled upon that blog from Glenn Fiedler about physics and networking, and I have found myself returning to it regularly ever since. It covers all of the basics of setting up a UDP connection for the purpose of a game (As well as other really interesting topics for programmers. I’m sure I’ll have to cite one of his articles again at some point in the future).
I will stick to UDP, and the basic purpose of the FLNetwork library will be to handle those network connections on both sides, as well as to provide a consistent and error-proof way of sending and receiving data through those connections. This means we also need to find a nice serialization technique.
Obviously I also need to come up with some code for a server process, and I want to have it spawned automatically by the client, just like NeREIDS will do in standalone mode.
So, up to coding, and I’ll be showing you the results next week.