Aternumis Devlog — #0001
Aternumis Devlog — #0001
I'm essentially writing these in real-time, so you're seeing my thought process with some mild edits for brevity.
I’ve been toying around with this game idea for a little while now, so I figured it’s high time to start putting it into action. Currently, there are a few things I know I want for this game.
First: it should be an online game of some sort. I’m thinking: a central server (or cluster of servers for load balancing) that the game clients connect to. Essentially an MMO, just without the ‘Massively’ portion. Let’s be real here, I don’t have the resources to manage a ‘massively’ scale. If the game gets enough traction to warrant it, then I can afford to address that then.
Secondly: I’ve always enjoyed RPGs of the fantasy flavor, so I’d like for the theme to fit. Some sort of a high fantasy, magic elements, a sprinkle of darkness perhaps. I haven’t quite hammered this one down yet, just going with the flow here.
Third: real-money trading is allowed. There’s only one game that comes to mind that does this at its core. Let’s face it: gold farming and bots are always going to be a thing in every online game, so I might as well embrace it by design. Players will have some level of ownership over their items/gold/etc, and are free to buy/sell with other players if they so choose.
Fourth: absolutely NO pay-to-win bullshit. No cash shop. Well, I might have one for cosmetics or something, but I’m not sure yet. I’ll let the players decide if that’s what they want. Knowing the gaming community at large, I’m confident it’ll either only be cosmetics or won’t exist at all — in either situation, that’s fine. If “functional gear” wins, then just know that the poll was hijacked by EA.
There’s a certain level of ease that comes with using game engines such as Unity, Unreal, or Godot. They handle basically all of the heavy lifting for you out-of-the-box. Physics, audio, rendering, input, etc. Sure, you can customize everything you need, tweak each individual engine aspect just right, but at a minimum you really only need to build your level and write your game logic.
Let’s evaluate each of the three engines.
Unity. Undoubtedly the most popular game engine, and understandably so. It runs fairly well, there’s a MASSIVE community behind it with plenty of documentation, the asset marketplace is effectively endless, and C# is a relatively beginner-friendly language. But wait, uh oh. Sure, they walked back their decision, but I’m very much against any level of corporate greed like that. On principle alone, Unity’s out.
Okay, let’s check out Unreal. No immediate controversy that I can see, so that’s good. They support C++, which is even better since that’s my preferred language for this project. But good lord it takes forever to load anything and it makes my computer scream like a stuck pig. There’s also one other huge issue: while Unreal is a game engine, it seems its strengths are more tailored toward being a graphics engine. Because of this, the build size for even an empty project is… large. That simply will not do. I need as much efficiency as I can get, Aternumis needs to be able to run on a potato.
Help me, Godot, you’re my only hope. Open source, small editor footprint, small build footprint, no major controversies to speak of.. so far so good. There’s one major issue though, and that is its reliance on its proprietary language GDScript. I’d rather avoid pigeon-holing myself by learning a proprietary game engine language, and would much rather stick to something like C++. Apparently Godot offers C++ support, but the setup for it is convoluted to say the least, and still has heavy ties into GDScript.
Looks like Aternumis has died before it’s even begun.
I’m not sure why. Maybe it’s because I hate myself. Maybe it’s because I enjoy a challenge. Maybe it’s because I’m stubborn. Maybe it’s Maybelline.
But I figure if none of the other engines fit my needs, then what better way to learn C++ than to just build my own engine. “You’re aiming too high! Start with a smaller project!” Shut up, I’ve heard it all before.
Listen. I’m a competent enough developer already. C++ isn’t my first language, so I’m already familiar with programming patterns and such. Everybody says to start small with your first project, and understandably so, but truth is this isn’t my first project. It’s just my first major project with C++. There’s gonna be a lot of tutorials and documentation and stack overflow to sift through, because I will inevitably get stuck a LOT. But each “feature” of this project will be a project in and of itself. Instead of taking the approach of “I’m building an online RPG”, I’m instead saying “okay, I need to get a very basic server set up”, followed by “right, let’s connect to it with a simple client in the console”, and then “okay let’s render a window instead of the console”. Each subsequent task is an entire project. I know what my end goal is, I just need to map it out and focus on achieving each individual microscopic step.
First, we’ll setup a database. There’s no point in running an online game if we have no way to save player data in a modular format. For this, I’ve opted to use Supabase since I’m most familiar with it and they have realtime functionality. On top of this, I figure I could find a way to leverage their edge functions to take some of the load off my server.
The initial database setup was surprisingly straightforward. All I’d need is pqxx and I’m flying. It’s important that we connect the server to the DB in a non-transactional way, since we’re going to need to constantly read/write/update it. As a quick proof of success, I’ve outputed the information from the players table into the console.
We’re also using sockets in order to obtain the local machine’s IP address. I’ll have to modify this in the future when I start testing on remote servers, but this is good enough to allow me to test connections on my home network between different machines. Here’s the initial stage of the server’s main loop.
At this point, we need to keep the server alive, hence the infinite while loop. From there, we have a call that’s looking for new_socket, which is just a connection to the server. If a connection’s detected, a connection socket’s assigned, and then we open up a new thread to handle client interactions.
However, there’s a MAJOR flaw with this that I’ll have to address rather soon in the server’s development. Threading does not scale very well, and doing it this way is a very very very wrong approach. Performance will be maxed out before a dozen clients, not exactly ideal for an online game. I’ll need to figure out a way to thread the work itself, not the client. But for now, this approach will suffice.
Anywho, once a client’s connected, we’ll send a welcome message from the server — this way I can easily see on the client that we have indeed connected and information is being passed both ways.
The code for the client is far simpler than the one for the server, and is roughly half the size. All we really need to do is just connect to the server, which is easily done.
As you can see, the client has launched in the console and has successfully connected to the server and received the server’s welcome message. You may have noticed a difference between the two welcome messages in the output and the prior code. This is because the code screenshot was taken after some modifications (I’m playing catch up here on this devlog, this is all old work so bear with me here).
Anyway, here’s a screenshot from the server output, showing that the client has connected.
We’re in business.