Hello and welcome to the Aegis Ascendant Devlog! Check out the About page for a little more detail but in summary Aegis Ascendant is a mecha strategy role playing game I have been developing for the last few months. Lances of mecha will go head to head in turn based combat on the tactical layer while on the strategic layer politics, intelligence, economy, and base building will be done.
I wanted to start keeping a devlog as a record for myself, anyone interested, and for other budding developers as I sure know that I have been able to glean a lot from watching and reading the processes of others.
Up to Now
Development proper began in November last year. I have no background in game design or art other than a few small projects that will never see the light of day, but I have been playing around with the Godot engine for the past two years and getting a general familiarity.
 |
| 2022 untitled project that never made it much further |
After spending a lot of time reading documentation and watching tutorials, the first bits of gameplay began to assemble. In order of development, the first thing to get down is going to be the tactical layer gameplay. Playing around with default assets was all well and good, but it was about time to get some art direction in. Since I am working on this solo and my art skills are under development, I opted to go with 16x16 sprites and keep everything to a 640x360 base resolution.
 |
| Earliest art and layout let out of their cages |
For the UI, I took a great deal of inspiration from Archrebel: Tactics by Ularis Badler whose pixel art still blows me away. After a few weeks I had gotten pathfinding together as well as initial attacks and animations.
Next big implementation was fog of war (which still needs some tweaking) and building in handling for mecha systems that weren't just weapons. Under the hood they both extend out of the same class but each individual type of system needs its own handling conditions manually.
After a week or so of banging my head against this obnoxious pixel squishing problem ruining the scaling for all of my text and for all of the tooltips I took a break after finally figuring it out. Once the holidays were over I finally took the leap and began working on enemy AI but wasn't really sure of where to start with it.
 |
| squishy- trying to stretch into a 24x24 frame |
 |
| corrected, 32x32 scaled up from a 16x16 base |
Actually, a note on the issues of pixel squish. Since the game is done with such a small base resolution, it became really, really important to ensure that EVERYTHING scaled correctly and- importantly with an integer as opposed to a fraction. This ranged from the camera the player interacts with the screen with to the sprites themselves- as by default the engine was taking subpixels and doubling them up to produce fractional scaling and giving a squishy appearance to things.I have not tested it with other hardware yet- but the solution I found for Godot was to ensure camera scaling was integer based and that in project settings under display I had:
- Set stretch mode to viewport
- Set aspect to keep
- Set scale mode to integer
- Used exclusive fullscreen
Basic things are pretty easy to find a good tutorial for out there- like pathfinding and some gdscript specifics. But more complex topics are more abstract because fundamentally their implementations all depend on the game and how it works. After finding a GDC talk about how X-COM 2's AI works I got the idea together and after a few days of tweaking and bugfixing have my little AI mecha fighting and hunting with the best of them.
The implementation I settled on is for the AI to assess all possible moves it could make and then rank them based on a variety of factors such as potential damage output, proximity to allies, how many more tiles it would reveal by moving to an area, projected evasion and terrain defense, etc. What it comes down to is looping through thousands of arrays for each unit for each individual move it wants to make- which eventually would hit a race condition that I had to solve with a simple, short, timer between enemy turns.
 |
| Weighting- still needs additional adjustments for AI personalities |
Once the AI scores each possible moves it builds a list of all possible moves with the same rating and then flips a few coins to decide one at random. I was on the fence for awhile about whether or not to make this sort of decision a random one or a procedural judgement-based decision, but then I thought back to another game I had made and was having trouble with getting its AI right.
 |
| So much glow effect |
Spike Drive: Interdictor is a little 2d space shooter I cobbled together and set aside a few years back that was inspired by someone else's Ludum Dare entry that, for the life of me, I cannot find right now. It's a high speed game about blowing up the enemy ships before they blow you up and over time the waves of enemies get faster and can shoot more.
 |
| Random jitter implemented |
The problem I was running into was in telling the enemy where to shoot based on the player's movements. If I told it to project ahead of time based on the player's current velocity and fire at that location then it would always miss as player behavior is erratic. With that model of target tracking the game became trivially easy due to the speed and ease of player movement. This is where my idea of adding "random jitter" to enemy shots came in. Instead of always shooting at one location they would instead shoot for a random nearby location within a small range. As it turned out this behavior made them more fun to play against and also much more deadly in fights- even on lower settings they were scoring better than players in duels.
Taking this idea back to Aegis, observing the behaviors of the AI with and without the coin flip saw them being not only more apt but also much more effective at things like searching the map for a missing or hidden player unit.
 |
| Where I'm at in the design document |
