#2D-Game-Engine Devlog #6

Finishing networking

Most of the time on this devlog was spent working on finishing networking. I was mainly fixing the packet system which had some issues due to the way the packet header and packet queue were implemented. But as you can see, now people are able to join the server!

Next, I’m gonna finally finish the ui and then work on the main remaining features, mostly relating to assets and textures in particular.

2D-Game-Engine Devlog #5

Cameras 📷

Added the ability to use different cameras for specific render operations. Cameras can be applied and un-applied using regular render commands, making them very usable.

Render-Layers ⛰️

Added render layers, so objects get rendered before/behind the player. Still has issues with the x coordinate lol.

UI

Added some rudimentary ui elements like labels and buttons. The ui is direct mode so its pretty much just drop in lol. I also added nine-slice scaling so ui elements can be scaled nicely.

Next, I’m gonna implement collisions and some more ui functionality.

2D-Game-Engine Devlog #4

This is another boring internal devlog without flashy things lol. This time I implemented better file paths as well as data saving/loading.

Better Filepaths

Added a function to tectonic underlying library to resolve file paths. This should help with providing file paths. Also improved the memory situation for asset manager data.

Data Saving and Loading

The most exciting part of this devlog is probably the api for loading and saving data that uses a json-like object format. The format supports integers, strings, lists and compound objects (as im writing this im realizing, that i should probably also add support for floats lol).

Yea all in all, not that exciting even tho it took a ridiculous amount of time to get everything to work. Next, I’m gonna work on a small ui abstraction and then probably start polishing the engine to build a simple game with it and ship it.

2D-Engine Devlog #3

Toml Resource Files 💾

I spent most of the last 5 hours getting the c toml library i’ve been using to work in my engine. This involved extending the library to support printing toml files, so they can be generated in code ^_^ This is particularly useful for replacing corrupt files and auto-generating files like settings and keybinds…

Recursive parsing for nested toml tables 🔁

Since seperating keys in toml with dots means creating a table (this feature is awesome and annoying at the same time 😭 ), i had to find a way to parse nested tables. I did this using recursion and have used it in both the language file loader and the keybinds loader so far!

I also had to figure out a way to parse tables that are part of a nested table for some cases. I did that with a check that looks ahead at the next table’s values and ensures that they are also tables.

More asset loading 🖼️

Finally got around to implementing more of the Asset Loader. It now supports shaders (which were a bit tricky due to consisting of fragment and vertex shaders). I also added loading for sounds 🎶

Devlog #2 - Implementing more core systems

Finished packet sending and receiving

This should hopefully be the last piece of packet infrastructure required for the engine. It was mainly about encoding and decoding the packets properly, managing the sub processes and handling the shared resources.

Implemented text rendering

Next, I implemented the render command for drawing text to the screen. Like all rendering actions, the text drawing is stored as a command in an array that keeps the order and then applied at the end of the current game loop iteration. It supports custom font sizes and colors, but I still have to add support for custom fonts in the future.

Implemented keyboard and mouse input and keymaps

After text rendering i added events for keyboard and mouse input. This only handles the keys/mouse buttons being pressed and released. For checking if the key or button is held down, one can simply use a function.

On top of that i also added keymaps that allow for easy keybinds with default keys, selecting keys or mouse buttons for an action, reseting and saving to a toml file.

Started working on a Language Manager

While adding names to the keymap, I realised that a proper engine should also supply a system for easily translating text. So I started adding a very basic translation manager that allows you to set a default locale and then load language files, change the current language…

However both the translation manager and the keymap can not be saved to a config/resource file at the moment. That’s why I am probably gonna have to extend the toml library I used in a previous project to support all those things. Alr, see you next time :3

Devlog #1 - Multithreading shenanigans

Reworking the packets

Since the initial system for network packets was quite unintuitive and not very portable due to relying heavily on macros, I decided to try and simplify this system.
I started by moving packet decoding to the main thread. This means that the packet receiver thread now pushes the raw bytebuf to the packet (data) queue and the main thread decodes then packet right before the user handles it. This way, we can avoid enforcing thread safety for decode context data.

Improving thread handling

Next up, I rewrote the client thread system to be state-driven, just like the server. That way i can easily handle connecting to a server, disconnecting and stopping the client.

Also had to fix a bug where the thread handler wouldn’t pass the engine as an argument to the thread.

Next up

Tomorrow im gonna implement more of the actual packet encoding/decoding/handling, so i can actually make my example game playable

Oh btw, i made this little player dude for my example game lol. I should probably implement input, so that he can move around and isn’t just stuck in one place.

Initial Devlog - Setting up basic infrastructure

I started this project off, by writing a lot of the api and basic stuff like a backend system and implementation in raylib along with some basic assets and events.

The premise

I wanted to create an engine that is extremely simple to use and that allows you to create multiplayer games in a systems language like C without you having to touch stuff like threads and socket libraries.

Since its supposed to be a full on game engine, it should also be able to handle things like assets, events and rendering cleanly, out of the box.

The networking approach

While making the game multiplayer is optional, it is recommended to implement the game with separate client and server processes, to cleanly handle game logic and support future multiplayer.

The client and server process use separate engine data but do share a backend (In the future, the backend might be subject to splitting or at least ifdef guarding so you dont have to compile libraries like raylib on the server).

The main game logic, depending on your implementation can be shared obviously. Communication between sides happens using packets. When creating a packet one can either automatically serialize the packet struct by describing its layout or provide custom functions for encoding and decoding the data.

Implementing the game

The actual game logic is mostly up to the user, whether you use an ECS, a more traditional entity approach or something completely different does not matter. To interact between the described processes, the user has to implement handling for packets in their game loop on both the server and the client.

Next up

Im probably gonna start working on actually being able to start and connect to servers. This will probably also involve major changes to my sockets library. After that I want to focus on more game engine related things like assets and texture tiling, music, sound and a bunch more.