Open tbeddy opened 7 years ago
@djwhitt I had a lot of questions, so I'm consolidating them into this post.
: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)?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.
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).
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. :smile:
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.
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.
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.
Yes, units/units-contained should be relation.
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?
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.
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.
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.
Cool. Should we also disembark passengers with a two step process because of the same terrain issues?
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?
Yeah, I agree, two step disembarking makes sense.
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