Add transport unit

[tbeddy]

#67
The transport unit can carry personnel and armored units across bodies of water. See its definition in Elite Command: https://github.com/cvincent/elite-command/blob/c84a3afb3eb2aad3b88c9cc34a7c497caa156010/config/initializers/unit_definitions.rb#L1147

[tbeddy]

@djwhitt I had a lot of questions, so I'm consolidating them into this post.

1. If a player wants to load an infantry unit into a transport unit, should the infantry be selected and the transport unit targeted? Is the action being done by the infantry?
2. Should a transport unit be allowed to move the same turn that units have been loaded into it?
3. Should a unit only be able to load into a transport unit if the transport unit is one tile away?
4. Should a unit only be able to load into a transport unit if the transport unit is in a port?
5. Should the transport cost for each unit type be put into a map somewhere in the data file, such as
   :transport-costs {:personnel 1 :armored 3}
   or should it be hardcoded into each unit definition (the same way only personnel can capture but that information is represented as a bool within every unit definition)?
6. When a unit is loaded into a transport unit, what should happen to its representation in the database? It could be retracted, all of its relevant information (unit-type, round-built, count) stored within the transport unit's data, and re-added when it leaves the transport unit. If a transport unit is destroyed, all of its passengers would automatically go down too (which I imagine is the intended behavior). But I don't know what issues this could cause or if it's unidiomatic.

[djwhitt]

1. Yep, infantry selected and transport targeted. Infantry should perform the boarding action.
2. Yes.
3. As long as the transport is within movement range, it should be possible to board it.
4. No, loading anywhere along the shore should be allowed.
5. By cost do you mean the space occupied inside the transport? If so, then it should be part of each unit definition. It'll likely be the same for all personnel, but I could see it varying for armored units.
6. There should be a unit/units-contained attribute on the transport. When a unit boards, it should get related to the transport using that attribute, and its location should be retracted. When the unit deboards, the transports unit/units-contained attribute should be retracted and the new location should be added to the unit.

[tbeddy]

Thanks for these answers. Follow ups:

3/4. I'm having a bit of trouble determining when a passenger unit can board a transport unit, if the transport unit is on a terrain the passenger unit cannot move to. It might be better for me to leave it unfixed for now and we can look more closely at the code together when I make a PR.
5. Yeah, cost = space occupied. Elite Command gave personnel a cost of 1 and armored a cost of 3. For now, I've assigned 1 to all personnel and 3 to all armored, naval, and air (in their unit defs).

And some new questions:
Whenever a unit with units contained is selected, I imagine information about each of those contained units should be displayed. I'm thinking it could either appear below the screen (above or below the hover/terrain-effects info) or a button could appear (labeled something like "View units contained") that would trigger a modal with the same information (probably in a nicer, less compact format like the unit picker, with corresponding images for each unit).

• Which option seems better to you? Or do you have another idea entirely?
• What information should be displayed? I think only unit-type and count matter since the unit can't really do anything while being transported.

[djwhitt]

3/4. Ah, I hadn't fully thought through the implications of not being able to move to the terrain the transport is on. Pressing on sounds good and I'll keep thinking about it.

Re viewing contained units, I was thinking about this a bit when you asked your previous set of questions and wondered what your plan was. 😄

I think a "View units contained" (or something similar) button + modal popup is the better option. I don't love either choice, but I haven't thought of anything better. I agree about the information displayed. Unit type and count are all that's needed.

[tbeddy]

Cool, I was also thinking the button + modal popup would be better so I'll get that working soon. We can always replace it later if someone thinks of a better design.

[tbeddy]

I'm returning to this with the Datascript knowledge I gained fixing #87 and I'm wondering if I should also use a relation instead of a regular value for the stored/contained units.

[djwhitt]

Yes, units/units-contained should be relation.

[tbeddy]

Thanks.
Should a transport unit and its passenger separately store the same value (like a random integer) as a way to reconnect when loading a game from a URL?

[djwhitt]

I don't think a coordinating value is necessary. I'd just nest the passenger units under the transport when serializing the game state.

Also, on a different note, I like the "passengers" term. I think :unit/passengers is better than :unit/units-contained as an attribute name.

[tbeddy]

I've changed "units-contained" to "passengers" and fixed the :unit-passengers relation, so I've moved back to working on boarding and disembarking passengers. I'm wondering if instead of boarding by effectively moving to the location of the transport unit--which is difficult because the transport unit may be in a terrain-type the potential passenger cannot move to--a unit should able to move before boarding and board when it is one tile away from a transport unit.

[djwhitt]

I think splitting it into two actions is fine (move, then board adjacent transport). From a UI perspective, we may want to have a way to combine those (move + board in a single click), but don't worry about that until it's working.

[tbeddy]

Cool. Should we also disembark passengers with a two step process because of the same terrain issues?

[tbeddy]

Coming back to this, I'm remembering that the disembarking process was the biggest obstacle I was running into. Juggling unit selection gets messy. I'm thinking that the two step process (disembarking onto a bordering tile and then the former passenger being able to move from there) would be best. Thoughts?

[djwhitt]

Yeah, I agree, two step disembarking makes sense.