Some Music and Many Fixes

As the tactical screen continues to get refined I've been crushing a bunch of fun bugs that were really giving the UI a run for its number. I'm still not quite happy with the UI setup- but as the redraw happens bit by bit I intend to adopt the big chunky button style from the title screen for everything that I can. 

Progress has been glacially slow as of late due to life getting busy- but also I've been working through a musical block. It's finally time to start implementing sound effects and music and music is something I was completely unfamiliar with and have been bashing my head against figuring something workable (in the meantime the game has just been running the Metal Marines OST). Well, minor crack in the glacial block here with a tentative title screen theme. 

Objectives are in the middle of implementation as well as an objective screen, which currently sprouts from a big thumb on the side of the screen with a simple holo display as above. Speaking of displays, the ongoing Nvidia driver glitch has been a menace and still is- so I'm living on 566.36 right now for my own sanity- but here's hoping that gets resolved...

Progress continues.

Attack Animations, Race Conditions

Doing a lot of testing to ensure that all of the basic functions work before progressing and I've been running into a strange problem for awhile that I was calling a race condition. Essentially, what was happening was that instead of waiting for animations to finish in certain cases, the main thread kept going and causing chaos all over the place- like units taking turns when they shouldn't be and disrespecting the turn counter. What it turned out the issue was was my misunderstanding of how coroutines and awaits work in the engine, but now that that's solved things are running much more smoothly. Signals and a sturdy event bus are the way to go.

I did a little bit of testing of themes to see how to implement color swaps and was pretty satisfied with the results. After doing some investigating further, it looks like using a shader to swap colors, as seen above, is probably the best way to implement this. Going forward I also want players to be able to customize colors on their units but that will require a redraw to ensure there's a good breakout of which colors are where on all the sprites. 

While I was thinking about how to fix that race condition above, I did a bit of work on spiffing up and diversifying animations and figuring out a better way to implement them in the attack handling code. The results are a much better packaging of data and some nifty new animations. Next up is handling events, dialogue injects, and pilot chatter. To fully implement the theme swapping mechanic I'll also need to do some readability tests with text coloration and see what works- so themes might go on the backburner as I'm really trying to get the tutorial minimums done. Once events and dialogues are settled the next big hurdles will be the mech builder/equipping screen and getting sound effects and music setup.

Other Small Updates:

• Fixed sidebar text not updating after a one-per turn weapon was used
• Fixed sprites not facing each other when attacking
• Made pop up text and numbers more readable
• Fixed camera inconsistencies and implemented better zoom
• Fixed pop up text over units to display and scale correctly
• Slight tile changes to make things marginally less ugly 
  

First Devlog

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:

1. Set stretch mode to viewport
2. Set aspect to keep
3. Set scale mode to integer
4. 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.

A few more things were done in the past few days like setting up a logging system and doing a lot of bugfixing (sometimes your problems are there because you put them there) followed up by taking a break with some art to make the title page and these big, glorious, chunky buttons.

Where I'm at in the design document

There's still much to do but I hope to get a little demo of the tactical gameplay done soonish- though the art assets will take awhile to catch up as I'm new to VFX as with everything else. Also audio needs to be made and wired in which will also be a learning journey for me.