Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove UnitEquipmentAttachmentResource? #24

Open
guerro323 opened this issue Apr 8, 2021 · 0 comments
Open

Remove UnitEquipmentAttachmentResource? #24

guerro323 opened this issue Apr 8, 2021 · 0 comments
Assignees

Comments

@guerro323
Copy link
Collaborator

After some thoughts, this resource is a bit useless and could just be replaced by an integer key (not an index!).

The only moment where we require to know the attachment is when receiving MasterServer units data.
But if we register archetype informations somewhere in the game (both GH and Unity) that contains a conversion of MasterServer-Id to Key, then it would be possible.

struct UnitDisplayedEquipment { int Key; UnitEquipmentResource Resource; }
struct MasterServerUnitData { string Archetype; Dictionary<string, string> AttachmentToEquipment; }

Buffer<UnitDisplayedEquipment> buffer;

var data = GetMasterServerUnitData(unitId);
var converter = GetIdToKeyConverterFromArchetype(data.Archetype);
foreach (var equipment in data.AttachmentToEquipment)) {
    buffer.Add(new(converter.GetKey(equipment.Key), equipDb.Get(equipment.Value)));
}

There isn't a strong reason to do that, but:

Pros

  • It would save a few bytes when transfering data in multiplayer or GH <-> Unity.
  • When creating NPC or AI enemies, the map-maker will not need to know the ID of the attachment, which is kinda good, and can also give an easier access to freedom instead of having the feeling to be constrained by availables attachments.
  • On the Unity side, we could just have a Model prefab with a map of integral keys instead of string keys (which is honestly, easier to work with, especially for map-making)
  • The Unity client will now have less dependencies to hard-coded master server ids

Cons

  • Models of the same "archetype" need to respect the same integral keys (eg: not mistyping 1 for helmet and 0 for helmet on another model)
  • If we implement dual-wield ability, and if it need to know the stat of each weapon, how could the ability know that? How can the ability enforce the archetype to be only dual-wield?
// on attack frame

var equip = default;
foreach (var equipment in GetBuffer<UnitDisplayedEquipment>(owner)) {
    // Is this right? WeaponHand would indicate which hand is using that weapon... (this mean it would be possible to have an archetype with multiple hands!)
    if (archetype.GetEntity(equipment.Key).Has<WeaponHand>().Index == isRightHand ? 1 : 0)
        { equip = equipment.Resource; break; } 
}

// apply stat based on 'equip' var

isRightHand = !isRightHand;
@guerro323 guerro323 self-assigned this Apr 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant