Caesar Engine

Welp, and that's that. I corrected some more of the code, but, at the end of the day, it is the same engine. It was a fun run doing 38 hours of this for Summer of Making, and do not worry, for I will be continuing development of this engine, both for the Athena Award and onwards. For now, I'm burnt out though... Bye, love y'all <3

Welp, I could not, for the life of me, resist my own primal urges, and did, in fact, continue hyper-optimizing stuff to a shameful degree. That said, it did bring forth a much cleaner codebase, and also, now, I have completely reworked how mouse keybinds work, so we can do the same we do with the keyboard keybinds and have and and or requirements for said keybinds :D

I know my devlogs are getting shorter by the moment, but it is not my fault, truly, that I keep making so many small improvements and adding so many small features. Annyways, now the province text is culled whenever it is a bit offscreen. Not too much just in case we quickly go back to where we were and/or jump to those provinces. Also I have decided to cull state text, because even if we have just 100 states, with 10 letter names, that is 4000 vertices worth of memory. Which doesn't sound like much but between shader processing, memory storage, and vertex processing, we're talking about a LOT of data and processing power... The way I decided to do it, since state text can appear at much further camera positions, is to start culling it even when it is still onscreen, prioritizing the states near the center of the screen. This should also give us a nice aesthetic, tbh. >:3

I have COOKED with this code improvement. And almost burnt myself doing so lol. Anyways it is just what it looks like, I took my tower of ifs and just did a fallthrough switch statement, which means it should be very very slightly more efficient. But, over the course of hundreds of provinces, any improvement is substantial! :D

Okay, okay, I might have gone on another one of my tangents, but I swear this time it is very justifiable. I decided to improve the efficiency and code safety of the province loader. Now, instead of province data being loaded into a vector, it is loaded into an array, which should be slightly lighter, both on the processor, as well as on the memory. Hopefully, with this slight upgrade, we can get a tad bit of a performance advantage when loading our map.

So, I've done what had to be done and, not only improved the hashing, so colors are actually more distinct now, but also decided to make it so that provinces have an outline. It's really simple, truly. I just scale down the provinces so that they go towards their own center. This also shifts them slightly towards the global coordinate origin, but I can live with that. I tried making it so that a border was generated between them, but I decided that, once the map is full, it won't matter anyways because then the border will be the background color soooo, yeah :3

Welp, as promised, now, if we do not provide a color for an state, the engine automatically generates one from the name of said state. This is cool because it means that as long as two states don't share a name, they (most likely) should not be able to share a color, which is just what we want! :D

Well, well, well... In preparation for the end of the summer of making tomorrow, I am making some longer devlogs, to cash in as many hours as I can, if you know what I mean. Anyways, I have implemented per-state, instead of per-province, colors. Now we can color states as we desire! Now, the only thing I have left to do is, one, make it so states without an assigned color get an automatic, non-random color based on their name, which should streamline stuff a lot, and second, I should try and get some outlines to show between provinces so I don't die staring at this cacophony of bright colors and whatnot lol

OK, so, I've continued my code micro-optimization and syntax fixing. To be honest this is really fun, but it also makes me feel shitty because I am not really doing anything productive with the code, you know? :( So, anyways, I think I will get started on getting armies to work and see if I can get to 35h before I need to ship it for the end of SoM :D

Welp this is another optimization update. I've mainly optimized how both the province and state files are read, as well as making sure it's proper and the code is just very very slightly cleaner. I've also made sure that some code that isn't needed if it's not a debug build won't be present in the release builds. This isn't really necessary, but it saves a bit both of disk space as well as memory, so there's that, you know?

Had to fix a few bugs around and optimize the code a bit all around, but now we have a ticker implemented with a callback that manipualtes the city values of all provinces, effectively simulating exactly what we wanted! Now, of course, this is just a rough draft, but everything great starts somewhere low, so, let us see where I can take this all to :d

Welp, I made it so that now we can add callbacks to the ticker, but, more importantly, in preparation to add resource usage, I have finally made it so that wasteland category provinces aren't included in the adjacency map, and much less used for pathfinding. This way we save ourselves a lot of problems down the line :D

I have decided to slightly optimize both the keybind system as well as the error handler. Nothing major, but everything matters in the end, to be honest, soooo. I have also started implementing a ticker class to make the ticks for the game work, which will happen once a day. Let's see how that goes :D

Don't you love it when you have to scrap a lot of your work because you discovered too late that you made it so messily it no longer works and it never could have but you failed to realize that little fact? Yeah that's me with the vector template idea... Anyways, back to the grind now... :(

OK, so, I have been on the process of reworking the vec2 class so that it works with template definitions. Why? Well, one, because I can. Second, because it does not cause a performance overload on runtime. And third, and most important, because it helps me avoid future problems with bad types and shit, so this is for the best. I have still got a lot of work to do, but I am progressing pretty well, if I say so myself :D

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...