Caesar Engine

I haven't really advanced a lot, but I have made a few good improvements to the vec2 class, which will surely be sooooo useful nad not at all something that is just microoptimizing so I can get some hours in :3

Well, I have finally decided to add something that I should have probably added before, but that nonetheless is still gonna be useful even with my late implementation: Knowing the length of the path. We will need this later to ensure we travel fairly, and that it is not only based on the area of the provinces, which is a bit more skewed. Besides that, it has been pretty simple to implement, if a bit brain wrecking because I forgot to reset the value when regenerating the line hehe :3 Anyways, that should be that new feature implemented, yay :D

I optimized the code a little tiny itty-bitty more, and added the modulo operator to the hadny-dandy vec2 class. Why? Did I need it for something? Not at all! I just thought it would be fun to implement it in case I actually have to use it in the future! :D (Was not wrong, by the way, it was really fun uwu)

And once again microoptimizing stuff that didn't need to be optimized... To be honest, if nothing else, this all is gonna make this engine 100x more efficient than any alternative because no one has spent this much time of their life into optimizing wether you have clicked on a province or not... Yay... :'3

Welp, once again I have improved code in a very minor and non destructive manner because of lack of motivation, yippieeeee. Anyways, yeah, just improved quad generation and text atlas reading, not too much. I will try to come up with the next feature to add for next devlog... Maybe :3

Welp, I have continued optimizing... Sorry, I guess I have an addiction hehe :3 I've been really slow on development but I'm going through a rough patch and I really cannot stomach more than barely enough to get these devlogs to get the stickers, to be honest, so yeah... I promise I'll make more when I'm better, hopefully sooner than later <3

Welp, I have very slightly improved some more things around. Yes, I know I should have been implementing more features but ohhhh well :3

You are probably unable to tell by this point that I spent the last hour just improving the error handler class and some miscellaneous things about debug mode right? Right? I hope I am not that predictable, right???

Ok, so, this is a big one, but, surprisingly, the only thing I have done here is fix stuff around. I have made the Window class better and the Error Handler now has much better logic and implementation. Apart from that, I also marginally improved the scrolling callback code, so that is nice. Now, time to go back to the eternal grind...

Welp, i did it. After mindlessly reorganizing code, optimizing even the smallest details, and just basically making time, for lack of better words, I got to twenty five hours. With that, my good friends, I'm shipping this shit and maybe picking it back up next month. Thanks for joining me in this journey. Love y'all! <3

Been hard at work cleaning up some code... Literally nothing more, to be completely honest I am almost done with this for a while, I just want a half hour more...

Welp, I've done a few more upgrades to the backbone of the engine. The most notable is the improvement of the performance of the Catmull-Rom utility function, as well as a few upgrades to the vec2 class as a whole, that should allow for better and more efficient usage of their resources and utilities. With that, I really wanna get at least another hour of development in this project before shipping, but I don't really know if I am ready yet to take on one of the big features, or if I will utterly fail trying to do so... I will see what I can do, at least :D

Very small devlog, but I just managed to fix my issues with the line :D I also removed the connection cache because it was really, really buggy, and it wasn't worth the hassle to fix for a thing that wasn't really gonna actually save that many resources in practice, sooooo... Yeah :3

Welp, I've greatly optimized the lines, and fixed some weird bugs around them. I've also decided to give them tips to indicate direction, though they are still quite buggy and require a lot of refinement still, but they are slowly but surely getting there...

Welp, we now have some pretty smooth lines, that are pretty efficient to calculate and draw too! :D Now, I still have to refine them a little bit before I can call them properly finished, but this is truly a great achievement and I can't complain at all about them. Let's see where I can get them >:3

I FINALLY DID IT!!! I GOT LINES TO WORK!!! My wrists hurt, and my head is wobbly, but i finally got the debug lines to work. Turns out it was a mixture of the VAO dying along the way, bad regeneration, points being translated to normal device coordinates incorrectly... A whole fucking mess... Luckily, I managed to fix it just for a really ugly line display feature!!! :D

Don't worry, though, soon we'll have something prettier, trust me >:3

After fighting for my life with this wicked code, I finally got the line rendering to not break anything and work properly. At least, so I think, because it's just a literal line for now, so I'll have to see about turning it into a genuine thing I can see, with some thickness and all. Let's see how that goes...

So, I've found a few little bugs around with the Line class... I think most of them are solved now but now I've gotta do the hard part and actually render the pathfinding line... Let's see how it goes...

OK, so, I've started working on a pretty bare bones Line class, that for now just renders straight lines between points. The idea is for it to serve as a debug visualizer for pathfinding, and eventually be what displays the routes troops are going to follow. It's really small as of right now, and basically just a wrapper for some very basic OpenGL rendering. I still have to make a dedicated shader for this class, as well as actually implementing its usage, but we'll go about that in the next devlog, since this one has already gotten its fair time...

Welp, I improved the debug method to let me first select one province and then select a second one to go to. Thing is, whilst doing this, I noticed that, under some conditions, the pathfinding was doing something weird. Lo and behold, I realized I had forgotten to add the area sorting, so it was just choosing the fastest path basically at random. So that's now fixed. :D

Welp, I finally fixed it :D Now the pathfinding algorithm TRULY works, thanks to the magic of the Breadth First Search (BFS) algorithm, implemented to minimize traversed TOTAL area, instead of my (very) slightly flawed Dijkstra's algorithm implementation. The efficiency should be around the same, though, at least, I've been led to believe so... Anyways, with this, we go a step further towards our goal of having soldiers walk from one province to another, let's see how that goes! :D

OK, so my pathfinding algorithm has a few faults, namely that it sometimes takes a longer path due to not evaluating a big province and instead choosing many small ones over it. I will have to fix that as soon as possible, since otherwise, we will get very weird pathfinding, not gonna lie. I only discovered this after implementing a path cache, though, which should hopefully remove overhead in common movements, without causing too much trouble for other cases. Since, from experience, you sometimes move troops from A to B and then move them from B to A, or realize you need to send more from A to B, etc. Very specific optimization, but I think it will mostly be for the good. If it isn't, it's easy and safe to remove, since it isn't baked into any of the vital components of the pathfinding system. I hope it is worth it though, lol

I FINALLY DID IT!!! :D I got Dijkstra's Algorithm to work with my setup, and now we get pretty quick and easy pathfinding, that takes into account the area of the provinces being traversed, and accounts for them to make the genuinely shortest path. Now, in theory, the next step would be to implement the A* algorithm, which shouldn't be too hard, having this based already put down, and it will massively reduce our CPU overhead when we use big ol' maps, like, you know, what this is meant to use on a normal basis, duh. Let's see how that goes, now... :3

Welp, after experimenting a bit I decided to mostly optimize code. I have added an area value to each province, calculated when we generate the mesh, and representing the number of pixels it occupies on the map file. I'm gonna use this to try and hopefully implement A* and get some good pathfinding going :D

Welp, I've been hard at work trying to develop some pathfinding for the troops to be able to march. so far it's been going pretty well. I started with a very simple and barebones algorithm that just told me how many steps it took, as a minimum, to get from A to B, and I adapted it to actually give me the necessary steps for said path. It was quite the annoying task, and optimizing it so it works good with bigger maps and stuff is gonna be even worse :(

Welp, I did it :D I made adjacency calculations work now, and they are pretty efficient too not gonna lie. I even did a little optimization where only the colors used by the provinces are checked against, mainly because, whilst I am debugging, I am using run of the mill maps, which aren't thought out to make sure that they don't have any extra colors, so it ended up being 30x slower than it needed to be. Sure, in production this optimization isn't necessary, but I'll probably still leave it in for map makers and everything. Either that or make it so that it's only enabled on debug builds, I do not really know yet, but I will keep you all updated on how that goes about, on future devlogs :3

Have you ever had such an stupid bug that when you finally managed to solve it you physically cringed, or even wanted to cry? Well, that just happened to me. As I was trying to implement adjacency detection for the provinces, I discovered, lo and behold, that I had a massive bug. The list of adjacent province colors was being generated properly, but something, somewhere, was failing, and I couldn't, for the life of me, figure out what it was. Turns out, I had forgotten to add the variable to the copy constructor, so it was getting garbage collected in the background. I swear to god I'm about to cry.

I reworked the city system to now be its own struct, so that it's easier to handle and everything. This isn't really a huge change, but it allows the code to be cleaner. I also adapted the system so that we can OPTIONALLY set the city parameters aside from the city category, which is something that will probably come in useful later down the line. Whilst implementing this new system, I also rediscovered an old bug that has pestered me before, more specifically when playing with shaders, and it was about the resource file folder not being copied with every build. I fixed that with some CMake magic and now I'm very happy , because I just made my own life a tad bit easier :D

OK, I've reworked how province categories work. I have also removed the unnecessary cities file (for now), and decided to add error handling for when we create provinces with unassigned categories, which will automatically be made into wasteland.

I know this still sounds like I'm just working on the backbone and not any actual functionality, but, trust me, please, I beg of you, this is going towards an actual functionality upgrade. Not a huge one, nor one that will make the game actually, you know, playable, at least not yet, but definitely one that will put us closer to that awesome goal :D

I have slightly optimized the code and improved some background stuff, yet again. I seriously need to make some actual changes tbh...

I have fixed up some of the code and added acknowledgements to the README. I originally also wanted to optimize the text display even further (I'm obsessed with efficiency, I know), but I really couldn't find a good way to do it that wouldn't over-complicate the code. So it's staying like that for now :D

I've updated the mouse callback function to now use our marvelous vec2 classes to calculate the province and state we've clicked on in a more readable and clean fashion. Is it obvious yet how much I love this little helper class? :D

Welp, I've made some adjustments to the code so now the keybinds are better handled. I've also reworked the mouse drag funcionality so now it works with out really great vec2 helper class! :D

I have optimized the Text class a bit further. Now, characters are handled with a much superior and much more flexible switch statement, which should theoretically be a bit better than my previous if tower. Also, I have fixed WASD movement speed not scaling properly with scale, because it was bugging me out a bit.

So, I was coding on my laptop, and added a keybind system (for future usage :3), and whilst testing, I noticed something I hadn't noticed on my main computer. Turns out if you minimized the window, the game would crash due to a divide by zero error. I have done a quick and easy fix for it and now it works :D

I have taken the liberty of slightly optimizing the text rendering code. Now instead of creating an EBO and doing all that stupid stuff, we get the same amount of memory used, less geometrical complexity, and an object less we have to store, handle, and take care of. So yeah, it's not the biggest performance improvement ever, but it's definitely an improvement over the previous code. Much more readable and easier to understand now, too! :D

I reworked the Shader class to be able to, first, use our little vec2f helper structure to pass the player offset, and second, to work with the global error handler. This marks, officially, all classes that can throw an error, as compatible with the new error handler, which is really great for debugging and everything else. Let's continue now...

Ok so the servers fell and I could only do a devlog now, yippie so fun, this will not affect the quality of my votes or project in any predictable manner, I am fully sure :')

Anyways, I've slightly reworked the text system, and added an error handler to finally get rid of those TODOs that have been awfully pestering me since I started coding this engine, and so now we can more easily debug the code in a more precise and user-friendly manner.

I have done a good amount of work to fix some issues I had before with the text system. I tried to also fix some other issues with it but... They almost broke my skull open before getting any acceptable results, so I'm leaving the base there to implement later...

I have done a good amount of work to fix some issues I had before with the text system. I tried to also fix some other issues with it but... They almost broke my skull open before getting any acceptable results, so I'm leaving the base there to implement later...

This last hour has been mostly setting up a GitHub workflow so I can automatically generate the build files for the project. This way, they automatically compile, and this means I already have a demo compatible with Ubuntu and Windows! So, time to ship (I need to get verified lol)

Ok , so, still no visual or functional changes, but i have reworked a few of the internal systems to be more compact and better readable, so there's that. Now, let's see if I can get to something that actually shows...

After reworking basically all of the codebase to be more readable, and better optimized, cleaner, and more standard and proper, I have obtained... Having the same final result as before, hehe... Welp, NOW I'll go and add more features i guess :3

I managed to fix it!

Turns out I forgot the fact I'm passing color as an unsigned byte, so I had to divide by 255 to get a proper value. Now it works perfectly!

Now, to work on abstracting states so we can clean up the code and make main.cpp neater...

So, even though this project was started way before this summer, I think it's a good way to use my time. I'll post here updates about how it goes.

To explain what I'm working on right now, I have o explain to you the basic working principle of the engine.

The engine works with states in mind. Every country is constituted by a set of provinces. If you've ever played Europa Universalis or Hearts of Iron, you know what I'm taking about.

So, to define these provinces, I use two files. A color-coded png, which is read through the stb_image library (I plan on making my own version of this, since the idea is for the engine to have the least amount of dependencies), and a txt fie containing the actual information of the province.

The bug I'm trying to fix now is the fact that, when rendered, provinces don't have their own unique color, instead seemingly sharing one per state for some reason.

Let's see what the fix might be...