OpenAstra: the open source space game

... And i should have known better, but i somehow got tricked from all this new shiny modern C++ stuff and lost sight of the good old ways.

Turn out JSON is a good idea, but only at validation and file interface level. After some benchmarking it looks like serializing to JSON then messagepack a single star system cost some 40ms, which is... Embarrassing. And probably also expected, damn me.

I choose to keep the messagepack format, which is actually quite effective, but leave out the json middleman.

Mind you, JSON is still used to load game rules and to save to disk the game, as this is perfect for human readability and validation, but direct message pack conversion is now used to exchange live data between server and client over the network interface.

This should be much more effective, using arrays instead of maps to avoid also sending strings around. Dataitem indexes and category indexes will be used instead, so both byte count and transmission speed will be greatly optimized.

Another advantage is that, by using message pack, on the client you can actually convert to native Godot structures as before.

Whatever, i prefer C++ to Godot, i am more familiar and anyway backend development feels just more interesting.

Well, it seems i was wrong in using a std::map<std::string, DataItem> to store dataitems. A quick valgrind profiling proved that 90% of the server load happens within the std library manipulating string objects. Go figure.

I should have predicted that, but somehow all this new C++17 stuff lead me to believe differently.

So i am now moving to a std::vector approach and a numeric index instead of strings.

So now you will need to convert the dataitem name to index, store the index for future reference, and then use the index for a super fast direct access trough the std::vector.

I am reshaping the GUI in the buttons part. I was kind of blocked, until i started working with the idea of refactoring the kind of monolithic HMI scene.

This boom, opened my mind and it really feels the way to go. I have removed the toolbox from the hmi scene and created a toolbox scene, then created a textured button scene to manage commands & capabilities from the StarsystemObject, and created yet another texture button scene to manage the same but from Module object.

It make more sense now, and seems the right way to go. Next i recognized that i can simplify the toolbox scene a lot and let the textured buttons scenes manage the user clicks on the buttons with the associated categories, modules and objects.

Next, i need to spend some time on it and code further, to understand if and how to properly manage commands. I am starting to think that they will also need dedicated scenes.

Marvels of Godot, i guess...

The GUI has a small area that when you select a StarsystemObject is populated with the actions that the player can do on the object.

Currently, it mostly support the move command, but i am studying how to make it more modular and display all the modules of the object, with their respective commands.

It needs to be focused on commands more than "actions" which is a concept currently not part of the game. With a custom panel that can be populated by the command/module/capability itself.

Now all rules are JSON validated.

I added ValiJson library and created JSON schemas for all the rules. Granted it's not perfect and probably missing some checks, but it's important and i have already caught a few existing errors.

Modularized buttons and actions, now further development of the client should be faster.

Need to find out what to work on after this...

The game is a client-server game, where the server side is actually running all the game mechanics and the client side provides the player to interact with the game, this choice aims at preventing cheating from players.

The server (backend) is written in C++, specifically C++17, and it's basically a Linux executable (could be ported to Windows or Mac easily i guess).

The client (frontend) is a Godot application that aims a providing easily multi-platform support. At this time i have tested it on Linux and Android.

Client and server talks to each other by binary optimized JSON messages, this allows for easier development of new clients and fast, efficient data exchange at the same time.

OpenAstra is a space game I am creating. The basic idea stems from years of playing Hades Star, then Dark Nebula, and realizing that such an effort of game should be Open Source and self-hostable.

No, Open Astra absolutely is not a clone of Hades/Dark Nebula, mechanics are different and so the overall experience. But it is open source (as both in libre and free) and is born from me having some free time.

The game is in early stages of planning and development. After some six months of me playing around with new techs (new for me), I am getting to the point where there might be something to share and try to create some interest.

I have no intention of monetizing this in any way. I believe that your hobby should not be your job and that doing things for fun needs to take the monetization away.

Maybe in the future there might be opportunity for donations, to cover costs, but at this time there is no cost to cover, so.

I will post here updates on development and hopefully also discussions in a future, when more than just myself will be involved.

There is also a website, see URL on top, but at this time do not expect much there. I have also created OpenAstra on Codeberg, but currently the source code is only on my (public) Forjeio instance. I will move to codeberg in some bear future when I will have a reasonably solid starting point