And so we begin 2021. So far it still feels a lot like 2020.

Recap

• A gameplay design for Fighter Squadrons
• A gameplay design for missile weapons
• Additional support for Persistent Effects
• More asset validation tools/features
• Technical and other Debt items

Results

I don't feel like I did very well this last sprint. There we a number of contributing factors: 1) A little bit of burnout, I didn't particularly want to do anything of substance on my computer. But recognizing that and taking a break is probably better than pushing on a project that doesn't have any real deadlines. 2) I think I overshot on the tasks that I queued up for my milestone and as I progressed there was a bit too much pressure to work on things (which probably contributed to the burnout a bit). I'm really appreciating Codecks as a tool, I just need to dial in how much “effort”/"points" I can realistically queue up. It's unfortunate that the first milestone I used it was one where I was primarily on vacation with a whole lot of time available. 3) Christmas Presents - this refreshed my book backlog so I've got a number of new books to read so there was time set aside for that. Almost done with The Software Craftsman and finished Every Tool's a Hammer (by Adam Savage of Mythbusters fame). I've also sunk a whole lot of time into Horizon Zero Dawn which I also got for Christmas. I'm really enjoying it and since it was the complete edition, it also had the DLC included.

Squadrons Design Spec

This probably went the best. I think it's also the first thing that I've really written as an up-front design that lays out the gameplay in a way that is only describing the gameplay and engineering elements. That's almost always where my head goes at first. I was able to finish it while I was still on vacation so I was able to show it to a couple of the designers from work whom I had a few video conferences over the break to just chat about random stuff. They had some good feedback about things I had and hadn't considered. I'll add it to the end of this blog if you're interested in what I'm going to be building towards!

Missiles Design Spec

This is where I really whiff'd it. I didn't get anything done on this. For some reason I just couldn't wrap my head around exactly what I wanted the gameplay for this to look like. I've continued to think about it so I hope to hit it this month.

More Persistent Effects Work

This was a little mixed. I was able to get the support I wanted so that hull breaches persist from tactical to strategy and back again. I wasn't able to work on the repair transaction to remove them or modify the repair times. For now that's been moved into the the backlog and I'll address it sometime soon. I was able to add support for passive effects and added a passive effect to the asteroid from one of my mission so that it's completely immune to hull breaches, ‘cause it’s got no hull to breach in the first place!

Expand Asset Validation Support

This sort of spiraled out from what I had originally planned to do, but in a good way. Once I started adding it in one place I found a few other types (all various families of Instanced object types) that could also benefit from it. A couple of the instanced type are also used by my custom nodes, so I was able to expand my validation support so that the same asset check messages that appear at editor and game start would produce Blueprint compile errors!

Tech Debt Items

I got quite a few items here done, but quite a few also got missed, though nothing that was particularly critical. In advance of getting strikecraft into the game I was already planning on moving the functionality for stat tracking (things like HP, armor, shields, etc) to an interface so that it would be sharable between those two types. That was pretty important to get done and was something I tackled early on in the sprint.

K2Nodes Tutorial

I got my tutorial back from my proof-reader who really liked it and said it taught him a lot. Technically I published it here on GameDev this week, so that would really make it part of February ‘21 sprint but I’m too excited to not mention it now! You can find it here! I hope you find it useful. As a primarily C++ programmer, I've always found a few things that drive me nuts about working in Blueprints. Writing custom nodes takes a little extra work, but has made quite a few things less annoying. Plus it makes it seem like a good way to take advantage of the things that Blueprint does well.

Goals

• Missiles Design
  • I'm hoping that the extra time to let this percolate in my brain gets me some where. I'll have to brainstorm a bit and figure out a process that works for me when I have a less clear idea of what I'm designing than I did with the Squadrons.
• Separate out some code to a new plugin
  • I've got three core systems that are very gameplay agnostic. I'd like to separate them out from the StrategyTech plugin they currently live in, into something between StrategyTech and my lower level CoreTech plugin.
• Begin Work on Squadrons
  • I'm excited to start work on the next big chunk of new gameplay that I'll be adding in. I'll need to start with a new category of equipment that's not a weapon but still equippable to the slots of a starship. The equipment will also need to be able to affect the stats of the ship that it's assigned to, which is something I don't have any support for yet. I've left this a bit vague which might be to my benefit or detriment. The spec I wrote been broken down into all the tasks needed to build it and I've assigned as much as I think is a good idea for this sprint, but it definitely won't be done.

Squadrons Design

New Ship Stat - Hanger Capacity - Additional maximum squadron storage capacity
New Ship Stat - Launch Capacity - Additional maximum squadron launch/recover capacity
  (maybe launch and recovery stats separate?)

Ship Equipment - Hangers - Increase Hanger Capacity
Ship Equipment - Flight Decks - Increase Hanger & Launch Capacity
Ship Equipment - Launch Bays - Increase Launch Capacity

Each turn a starship can deploy or recover 1 squadron for each launch capacity
  (each launcher has a separate cooldown?)
  (separate launch and recovery cooldowns?)
  Squadrons can be recovered by any starship with available hanger capacity (not just the ship that launched them)
  After being recovered, Squadron has cooldown before being able to be launched again

Squadrons have X number of strike craft (at full strength)
 - Start at 4(?)(faction specific?), increase with Tech and Refinement research
 - Hanger capacity should be measured in Squadrons, but tracked in Strike Craft
     A hanger with capacity for 2 Squadrons could hold 4 squadrons that are each at half strength
 - Individual Strike Craft have HP, Armor, Shields, ShieldRegen (or at least the capacity for them)
     Armor & Shields can be fully restored on recovery.
     HP restored on tactical completion.
 - All Strike Craft in a squadron are of the same class and same equipment configuration
 - Armor and Shields are non-directional (contrasted with Starships which have 6 separate Armor & Shield stats)
 - Strike Craft have no defined facing direction
     They can always move to any adjacent hex (assuming it's in bounds and occupancy rules permit)
       Occupancy rules should be revisited to allow for:
         Things that block everything (Stars/Planets)
         Things that block somethings (Dense Asteroid Field could allow Strike Craft but not Starships)
         Things that don't block anything but collide with some (Sparse Asteroid Field would apply collision effects to Starships but not Strike Craft)
     Multiple Squadrons can occupy the same hex
     Squadrons can occupy the same hex as a Starship
     Squadrons do not block occupancy, movement or line of sight
 - Damage is applied to a randomly selected strike craft when the squadron takes damage
     (this application should change as weapons begin to be differentiated or specific AA weapons/mounts designed)
     Random selection should include the chance to not hit any of the Strike Craft
       (this random chance to hit will need to be modified as weapon/mount differrentiation is designed)
     Extra damage beyond that which destroys a Strike Craft is *not* applied to other Strike Craft
     If all Strike Craft are destroyed, Squadron is Destroyed
 - Damage dealt by Squadron is scaled by Current/Max Strike Craft in Squadron
     If a Squadron deals damage to a target in the same hex, damage direction can be based on previous Squadron Location
 - After launching Squadron has X Endurance (depending on class/techs/refinements)
     (perhaps this is just the Energy stat?)
     Endurance ticks down:
       Each turn(?)
       Action based (movement & attacks)(?)
       Each turn an action is taken(?)
     At least 1 Endurance is required to move or attack
       Squadrons with 0 Endurance can still be recovered by a starship
       (relaunch cooldown based on 0 Endurance? shorter the closer to maximum Endurance?)
       Squadrons still deployed on mission failure/retreat are lost (regardless of Endurance)
       Squadrons still deployed on mission success are automatically recovered (regardless of Endurance)
  - All surviving Squadrons returned to their assigned ship on the completion of tactical
  - Full Squadrons can be constructed in Strategy
      Separate production queue from Starships(?, probably)
  - Understrength Squadrons can be repaired (LERP of full construction cost? with a minimum time?)
  - Multiple understrength Squadrons (of the same type) can be combined
  - Squadrons can be reassigned/swapped between Starships
  - Squadrons can be built and assigned to "storage" on Nexus
      These can be used to replace destroyed squadrons or reinforce understrength squadrons
  - Squadrons configured with weapons/equipment the same as Starships
      Techs could unlock weapons for both Starships and Strike Craft at the same time(?)
      Strike Craft Techs could be gated behind separate Techs which are themselves gated on the original tech and a Strike Craft building tech(?)
      Strike Craft weapons could be gated behind Refinements which are gated on the original tech and a Strike Craft building tech (?)
      Some weapons/equipment may not be compatible with all types of Strike Craft (Heavy's may be the only ones able to mount a Strike Craft variant of Plama Bolts for example)

Changelog

• 1282 Cleanup enumeration style-ing to match CamelCase style elsewhere.
  • Resave content using any of the modified enumerations.
• 1283 First pass at breaking out stats and action point support into their own separate interfaces and utilities.
• 1284 Rename the stats enumeration type to be a little bit more generic.
  • Resave the starship assets.
• 1285 Shift ActionPoint API over to the new interface.
• 1286 [[UE4 ENGINE]] Import a fix from 4.26.1 that broke abstract classes showing up in class pin drop downs in blueprint.
• 1287 Restore the Abstract markup to the GameStateObject type.
• 1288 Add blueprint compiler checks for event nodes to flag event types that are marked as Deprecated.
• 1289 Move functionality from the tactical starship over to the StatCapableObject interface.
• 1290 [[UE4 ENGINE]] Add the OutputAfterExec metadata to the macros header so it (should) show up in auto complete like the others.
• 1291 Oops. The Persistent Effects Container interface included some reference to Templates which aren't a thing in this code. Definition is the term that should be used.
• 1292 Fix some terminology references to Effects when it would be better for it to be EffectIDs.
• 1293 First pass on Fighter design documentation
• 1294 Add a utility for a structure that can be cast safely using pre-existing reflection data similar to the casting of UObjects.
  • Swap the Persistent Effect Apply Params to use this as a base and leverage the new utilities instead of doing it manually.
• 1295 Add missing DLL macro.
  • Move the cpp to Private.
• 1296 Extend the asset checks support to allow for routing verification errors to a kismet compiler instance.
• 1297 Add a verification function to state effects and their modifier types.
• 1298 Replace the direct use of CheckFlags with the, now more general, Verify call.
• 1299 Add a Verify function to State Conditions.
  • Add Verify check to the K2Node that can check conditions.
• 1300 Add a verification routine to Costs.
• 1301 Add a verification routine to transaction params.
  • Hook that routine up for their use in Transaction Definitions.
• 1302 Add verification hooks to the targeting previews and styles.
• 1303 Hook up the new Instanced type Verify functions to the Verify functions of existing definition types.
• 1304 Add some labels the buttons for the active project widget.
• 1305 Make the IsValid Native node visible to blueprints. Add a output pin that is just a pass-thru of the object that was che.ked.
  • Update existing blueprints to use this version (where appropriate)
• 1306 Add some labels to the BranchProgress widget buttons for incrementing and decrementing the resource assignments.
• 1307 Move the determination of local space hex direction between two locations to a utility function
• 1308 Basic implementation to support the movement of a persistent effect from one target to another.
• 1309 Fix a bug when checking the apply params for a hexside effect. We need to calculate a direction when none is provided. Not the reverse.
• 1310 Fix a bug with effect moves not updating the target and source ids.
  • Fix a bug with moved effects being marked for remove (bad side effects is being removed during archiving).
  • Create utilities that can find all the attached effects that meet conditions, regardless of whether or not they implement the container interface.
• 1311 Add support to markup SRPG effects as either movable between strategy & tactical or to cause a new effect to be placed on the tactical/strategy representation to persist that effect into the other mode in a different format.
  • Hook up starships to support this transition.
  • Flag the Hull Breach effects to function like this (as moves).
• 1312 Create blueprint node for GetOriginalRevision.
• 1313 Replace blueprint callable functions that return state pointers to instead return IDs like in native.
• 1314 Replace the ID return versions of map generator functions to just use the same functions as native that return the non-const, newly constructed object.
• 1315 Convert the inputs to the ship spawning to be pointer based instead of IDs
• 1316 [[UE4 ENGINE]] Tweak the reorder of output params coming after execs so that order is maintained and not reversed.
• 1317 Make improvements to the objective scripting nodes to be more generally in line with native patterns.
• 1318 A tweak to the spawn faction for multiple outputs.
• 1319 Hull breach rules should early out if the Breaching tag can't be applied to the damaged ship.
• 1320 Tweak the matching rules for immunity to work with the hierarchical aspects of GameplayTags.
• 1321 Add support for passive effects applied to the strategy or tactical starship as part of their inherent configuration.
• 1322 Create a passive effect that grants immunity to hull breaches.
  • Setup that effect as a built in passive of the asteroid target.
• 1323 Tweak the dialog node to return the dialog that was opened. Allow for cases where an external reason to close the dialog might be required.
• 1324 Swap the speed change control over to be a separate dialog instead of directly embedded in the tactical hud.
• 1325 Tweak the names of the dedicated tag ini files.