Not a Devlog
November 20th 2018 by SDGNelson
Small status update on the way toward 18
Sorry I've been keeping my head down a bit! Great reading through all the vehicle demo feedback, and I want to focus on making the beta available to everyone ASAP - I'm sorry I can't give keys to more players yet. Most likely the demo will be updated once these tasks are done (Combat Demo?), and then a pass on the test map to convert all the assets to my new maya pipeline.
Item Structure
The item rework is coming along well, and has been an interesting shift in my way of thinking. For years (dating back to pre-3.0?) I've been designing these systems around "assets" e.g. Eaglefire asset or Offroader asset which hold all the data, models, sounds, etc and then the game code constructs runtime objects from the data. The much more Unreal way of doing this is to create blueprint subclasses specific to each item, vehicle, etc and setup the data in the same place.
As an example of how this structure has changed in 4 now, previously some of the classes were setup like this:
BallisticWeaponDefinition is a UseableItemDefinition is an ItemDefinition. BallisticWeaponInstance is a UseableItemInstance is an ItemInstance, and the item instance keeps track of which ItemDefinition it represents. An ItemObserverComponent is responsible for the meshes, effects, etc which make up the ItemInstance, and it knows which ones to create from the data in the ItemDefinition, which can specify an ItemObserverComponent subclass to use.
The new setup basically has to be re-written because the architecture is so different, but relatively fast to do because feature-wise I've already done it once:
An Item actor combines the Definition and Instance, and can be subclassed for each specific item. ItemBehaviorComponents can be added which introduce different functionality, e.g. WearableItemComponent and EquipableItemComponent (analog to Useable/Weapon). You could have a gun that you wear as a shirt? Weapon actors are the new analog to UseableComponents, and similarly ItemObserverComponents are now ItemObserver actors. This shifts all of the observer data out of the definition and makes it a lot more customizable - less shared code changes needed for one-off effects like the spinning barrel on the minigun. This escapes the rigid inheritance tree. Primarily this change will really benefit modders.
Weapons and wearables are mostly transitioned, less-so the inventory yet. Inventory presents some tricky challenges in Unreal because you have to own an actor to call RPCs, but another benefit of the new design is that it's a lot easier for mods to call RPCs on their items because they are dormant Actors owned by the player now as opposed to simple UObjects. I've also reworked how interactions are discovered from module registry to actor/components implementing an IU4_InteractableInterface which is relayed to focused item instances, so your custom item behavior can easily define new actions like press F to attach night vision to helmet or something.
Anyway, easy to end up rambling about this. Also more little effects like shotgun shells make a different sound landing on grass than bullet casings!
Futureproofing 3
The past few days I've been busy on some updates for 3. I have to update 3 to Unity 2017.4 LTS before the end of January 2019, but I want to give workshop creators plenty of time to update their content because asset bundles will not be compatible. Among other changes I've added some (fairly obvious) features to allow multiple items/objects/etc per asset bundle so that all assets can be updated in bulk more easily, and transitioned Hawaii and Greece to this system. Most likely Hawaii, Greece, Cyprus and Germany will be moved to the workshop to increase space for future curated maps.
Runtime Shader Permutations
Right now 4 is GPU bottle-necked, at least in part because fx like grass displacement, snow displacement, snow buildup, etc are always active on the GPU. (CPU side is enabled/disabled). Unity had a nice feature for global shader permutations to enable/disable those shader variants as-needed, but the closest Unreal has are material qualities which are slow to switch-out. I've been working on re-purposing the material quality system to allow Materials to specify how they want to use runtime permutations (vanilla unreal, weather or foliage), and then quickly switch them out. My proof of concept for this works in editor, but there are some crashes and cooking issues to sort out. BUT now that I know it will definitely be possible that will put some of the performance concerns to rest.