Aegis Devlog 6 and a Side Project

An Aegis Update 

Well, strapping that UI together for the demo/tester missions sure was a lot more involved than I thought it would be. It's funny how sometimes things are actually very easy to implement even though they sound hard. Customizable palettes for units was very easy to implement and took maybe half an hour of fiddling around, but some of the more finicky data handling things like "swap this pilot's mech for another one" takes much longer, but after a good deal of finicking it came together.

Interface sound effects are also mostly good to go, still playing with a few varieties here and there to see what fits best. Handling the four audio buses and volumes is a delicate balancing act.

Along the way I also resolved two problems that have been plaguing me- or at least were slightly annoying.  

The first was a consistent issue I had with tooltips. Something is up with how Godot handles tooltips, and to get my own panels looking the way I wanted to I needed to overrwrite the built in method. This led to a second problem which was sizing the windows correctly for dynamic text- which was resolved by using PanelContainers to adjust size to the text given. However, after not long of this I noticed another fault, which was a grayish window popping up for maybe a few frames before being filled in with the custom tooltip. After weeks of tinkering and searching around for solutions, it seems like this is something to do with the way Godot 4 processes tooltips natively, so the best solution was to completely overrwrite its tooltips and write in my own- which have come out quite nicely so far with none of the strange popup issue. 

The second problem was one with the VFX getting hung up while the AI was thinking, which turned out to be a relatively easy solution with just a few calls to await get_tree().process_frame here and there. It's fractionally slower during the AI's turns now but the smooth effects and lack of jitter are well worth the cost. 

Progress has been on pause for a few weeks as I chew over a few mechanical questions that I haven't quite sorted out yet and hammer out more animations and sprite work. I've also been tinkering with some of the art redraw but am not quite ready to share that progress as it's still looking rough to my eyes. Additionally, the development of the strategic layer has started and I've figured out how to get a global 3D map and generate locations and such on it- which will be exciting once I have something that looks good enough to show off.

IN THE MEANTIME 

I have so, so many projects sitting in my godot workspace. Some of them are just procedural tweaking or little tests and probably 70% of them are me iterating and getting better and better at working with interactive fiction games. Specifically the journey started with recreating command parsers and Zork-style dungeon explorers which quickly became very involved as I discovered the challenges of hand-coding JSON files of dialogue and use case trees. 

Over time these IF projects evolved into a few different directions trying out a variety of styles and I gradually abandoned the parser in favor of a choice-based system (though the parser will be back some day, stay tuned Bifurcate). While chewing over the ideas for bits and pieces of Aegis I had the itch to go back and tinker with another IF project and so I threw together something new (I'm getting so quick at whipping up a functional IF UI at this point) that I could use to both keep honing my skills with handling dialogue systems as well as put to paper a specific story idea I have been cooking for a bit- something science-fiction. 

After getting the UI together I had the idea for a system called the Pulse, a representation and mesh of both the player character's stream of subconscious thoughts as well as advertisements from nearby locations, scraps of unrecognized conversations and net chatter, etc. I wanted to keep things strictly as text-based as possible to keep me from going down another art rabbit hole and pull attention away from Aegis, so the Pusle became a few running lines of text. 

forgive the FPS, the software I'm using only goes to 30

 Once I got it working and began putting together the dialogue handlers and working on the first few scenes, I kept finding I would just be staring absentmindedly at the Pulse as it ran. Bits and scraps of sentences all meshed together and constantly flowing, your eyes just sort of naturally run across it and you try to string together the underlying meaning of whatever is feeding into it. After some discussions about the game with a friend, I got the idea to make an arcade-y simple little game that was all about these lines of text and finding things in them. So, naturally, I stayed up through the night and after about eight hours I had put together Babblyte, a little typing game where I learned a few things about FPS, audio transitions, and apparently did not spend enough time polishing the high score database inputs before publishing.

Anyways, this new IF game I'm working on is called Moonwell.

 

 

 

Devlog 5: UI Updates

 

 

A quick (video size constraints) demo of the intro and some of the animations I wired in today.

After a long time of living with the current UI I finally went through and updated it, redrawing the tactical UI in line with the title screen's and giving them both a slightly darker recolor which feels much better to look at.

I also finished making a batch of pilot sprites and I'm so far pretty satisfied with the goofy-ish look of them.   

The mech builder needs to get wired into the demo-mission select next to make testing easier, which will give some good opportunities to test out some of the interface sounds I made today and see how they fit. This will also be a good time to adjust how shields work. 

Right now, shields function as the first-reduced damage pool on a unit but are tied to a certain damage type, similar to how Underrail works. After some playtesting though, it just doesn't feel great and hampers build diversity. I'm going to rip the shield typing out and leave a flat damage reduction and replace the typing with some systems that can be added in to reduce damage received from certain weapon types.  

Devlog 4: Progress Update

 

It has been a tough few months and I haven't quite had the time that I would have liked to work on Aegis, but now I'm back in the groove of things and making progress.

Since the last updates on the game, things have been busy and I took a break for a bit to focus on other things, but now we are back and chugging along. 

One huge thing that was a total road block for progress was me getting stuck on figuring out what I wanted to do for music and sound effects. While scrapping things together up to now, I had been using placeholder music from the Metal Marines OST as well as public domain sound effects, but I really wanted to make the soundtrack and effects myself so I spent months learning FL Studio and banging my head against it until I could finally make a few tracks I was satisfied with. Music has very much so never been something I have studied or practiced so it was a challenging process to get over the initial road bumps- and there will still be some refinement and updates as I learn more- but I am happy to say the music induced "designer's block" has been cleared for now.

 

Added:

- A huge amount of small touches here and there and optimizations to a variety of parts of the game- too many to count 

- Exfiltration system that handles units leaving the map

        - Wrecks of destroyed mechs which can be salvaged for resources

 

- Objectives that can be captured to grant resources, progress missions, disable enemy buffs, enable friendly buffs, etc.

- Music! A new main menu track, two additional tracks for the tactical battles

- Sound effects for attacks, movement, UI interaction

- Mech assembly allowing loading mechs with different equipment between missions (still needs an art pass to dress it up, otherwise fully functioning aside from a few things that need to get implemented like default palettes, etc.)

- Some initial visual flair to the tactical screen, work in progress

- Intelligence and Objectives tabs to view mission objectives and enemy intel

- Actual victory conditions to end the tactical battle

- Color palettes for unit sprites

- Saving and loading! This was one of the more daunting challenges to undertake and there's still much more to come, but after some time studying and trying things out this turned out to be smoother and took less time to implement than I had thought. 

 

Fixed:

-A ton of small problems that took way too long to figure out and had me going "Who could have done this? Oh wait, me"

-Removed (at least for now) some oddness with how fog of war generation worked and revealed units. Originally the intent was for units to have a much wider sensor view that gives them basic terrain layout and a smaller view within that gives them direct vision and reveals enemy details, but I had been tinkering with "sensor ghosts" in the non-direct vision radius to reveal the presence of an enemy but no further details. I need to rework some things with the vision system and play test it for a bit before deciding to drop this or re-implement it better. 

Future 

Some work still needs to be done on refining the AI's behaviors as, even with how much has gone into it, there are more features that need to be added and some odd edge cases that need handling. All in all though, I'm quite happy with how they function now on a basic level, being able to hunt, correctly assign appropriate weapons to targets, and all while keeping survivability in mind. 

Before moving on to the strategic game:

• Make another pass at tile textures and diversify out of the soggy green mess that makes up pretty much all of the in use textures 
• I'm going to dummy up a few demo missions to test out and get some feedback on game feel, and that should probably be done in the next week or so. 
• Also, I'll be jamming out the necessary world building to start designing the different factions and their tech and mechs. 
• Finally, there will be a necessary art refresh, particularly for the tactical screen as I want to get it more in line with what I drew out for the title screen.

Devlog 3: 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.

Devlog 2: 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.