Official Codex Discord Server

  1. Welcome to rpgcodex.net, a site dedicated to discussing computer based role-playing games in a free and open fashion. We're less strict than other forums, but please refer to the rules.

    "This message is awaiting moderator approval": All new users must pass through our moderation queue before they will be able to post normally. Until your account has "passed" your posts will only be visible to yourself (and moderators) until they are approved. Give us a week to get around to approving / deleting / ignoring your mundane opinion on crap before hassling us about it. Once you have passed the moderation period (think of it as a test), you will be able to post normally, just like all the other retards.
    Dismiss Notice

Hexagonal Tile - Facing Directions

Discussion in 'StarLife' started by tiagocc0, Aug 7, 2011.

  1. tiagocc0 Arcane

    tiagocc0
    Joined:
    Jun 29, 2007
    Messages:
    2,056
    Location:
    Brazil
    I wonder how to calculate these: Hexagonal Tile - Facing Directions

    I have thought about two options:

    1. Really walk all the path so what determines direction is the movement of the last hex, before you reach the destination, to the final destination hex.

    2. Make the ship go a straight line from A to B, determine the angle and then translate it to a possible direction.


    Then I have the question about how to spend the direction points your ship probably has.
    If we choose the first option we could spend the direction points along all the way, but since this is an hexagonal tile map, going in some directions will spend much more direction points than other directions even if they are the same distance apart from the origin.

    If we choose the second option we will need to calculate how much direction points to spend to put the chip into the right direction before moving. So it would spend only once.

    Then after arriving at the destination you may spend more direction points to position your ship the way you need it.

    It seems the option 2 is better.
     
    ^ Top  
  2. Shemar Educated

    Shemar
    Joined:
    Oct 16, 2010
    Messages:
    260
    I am firmly in favor if option 1. True hex by hex movement. It will make calculations of speed/energy consumption much simpler. It is not enouigh for the computer to be able to do them. Ina turn based combat system players have to be able to predict these things before they actually commit to them. If you know you have X hexes worth of move it is far far better than having to figure out paths in straight lines and remainder moves.

    If your system has separate 'speed' and 'direction' points, which I hope it will, then it is much easier to use them in a hex based move as each of your 'speed' points directly translate to move to the hex you are facing and each of your 'directional' points transaltes to turn left or right by one side (60 degrees). You can also add a manouverability ratio of how much 'staright line' move has to be between each direction change.
     
    ^ Top  
  3. Destroid Arcane

    Destroid
    Joined:
    May 9, 2007
    Messages:
    16,620
    Location:
    Australia
    Well, it's pretty standard to have a ghost that shows the path and tells you the cost of your intended movement in TB games.
     
    ^ Top  
  4. tiagocc0 Arcane

    tiagocc0
    Joined:
    Jun 29, 2007
    Messages:
    2,056
    Location:
    Brazil
    I see, as long as we accept that hex tiles have limitations: [​IMG]

    I think it would be better to change the hex direction that I've used in the game, it would be better to go from side to side in a map than go from top to bottom on a straight line.

    Sorry, I didn't quite get this part. Could you elaborate?


    Ow, I haven't thought of that, great idea.
     
    ^ Top  
  5. Shemar Educated

    Shemar
    Joined:
    Oct 16, 2010
    Messages:
    260
    Indeed the system has obvious limitations in the fact that straight lines are hard defined into the 3 axis. I find that preferable than the alternative of dealing with true spatial movement. :D

    Movement (in conjunction with my ship engine example):

    Assume that my ship has the following characteristics based on engine and mass:
    Total manouvering points per turn: 10
    Max speed points: 8
    Max turn points: 4

    If I have no other limitation I could M, M, M, M, TL, TL, TL, M, M, M (Move 4 hexes, turn left 3 times (essentially do a one eighty on the spot) and then move 3 hexes in what is effectively the opposite direction. This works but it would not be so cool for a ship to be able to do that.

    Now imagine adding a amnouverability class (based on ship components and mass as always) that limits that. Class 0 would be what a ship needs to do my previous move. Class 1 would require at least one hex of straight line move between two turns so I would have to do: M, M, M, TL, M, TL, M, TL, M, M which would show up on the map as a much wider 180 turn.

    If my ship was even bulkier and it was class 2 manouverability: M, M, TL, M, M, TL, M, M, TL, M

    A class 3 manouverability ship would need more than 10 manouvering points to do a 180, so it would have to do it maybe in two turns and it would need an even bigger area to do it.

    That puts a nice and realistic limitation at abusing the interchange between movement and turning.
     
    ^ Top  
  6. tiagocc0 Arcane

    tiagocc0
    Joined:
    Jun 29, 2007
    Messages:
    2,056
    Location:
    Brazil
    I see, this works well for a ship that has one engine, what if we put two engines on opposite directions, any ship could then Move, Move, Move, Complete Stop, Move Opposite Direction (Without turning).

    Or Three engine, being two just so it could turn faster.

    The Complete Stop option would take longer on bigger ships and using engines to turn faster would use a lot more energy to turn and the ship would a lot heavier as well.
     
    ^ Top  
  7. Shemar Educated

    Shemar
    Joined:
    Oct 16, 2010
    Messages:
    260
    Well, the way I would do it is that all the engines push the ship forward and auxilliary systems are capable of redirecting some of the engine output to manouvering. The way you plan to do it may be crossing the complication threshold and it will also make your life much harder in coming up with balanced engines. Your plan is probably more 'realistic' in a neutonian way, but I personally prefer the unrealistic 'ships in space' type of spaceship movement.

    The way I would justify it physics wise is that most of the engine power is not really about accelerating and decelerating but about keeping the ship 'in control' during manouvering.
     
    ^ Top  
  8. tiagocc0 Arcane

    tiagocc0
    Joined:
    Jun 29, 2007
    Messages:
    2,056
    Location:
    Brazil
    Yes, it would complicate things a bit.
    I do think it could give some more tactical options.

    We could set it like an engine is so big that it could only fit one on a ship.
    Or like traveling on space on speeds that would make it possible for exploration made ships actually become interstellar engines with weapons and crew. Because most of the ship would have to be the engine.
    Other engine options would be more like a thruster were it would make pulses to help the ship to mobilize better at space.

    It could have specific types so the player would be able to tweak it so much. But anyway I'm completely off track here, sorry about my rambling.

    I had never thought of making space ships turn like this, it would be similar to naval ships, right?

    It's really interesting but we could have an option to make the ship turn without having to move but it would require more time and/or more movement points to accomplish, or we could risk having ships stuck at the border of the map.
     
    ^ Top  
  9. Shemar Educated

    Shemar
    Joined:
    Oct 16, 2010
    Messages:
    260
    Or airplanes, yes. I admit that my tastes in space combat 'physics' veer away from realistic 'void' to unrealistic 'fluidic space'.

    Good point. You can deal with it in several ways:

    - Best: Auto enlarge the map. After all space has no 'border'!
    - OK: Ships that veer off the map are still hittable as if they were on the hex just off the map. They auto return on the map on a hex and at a time calculated by their capability to turn themselves around. Basically what you suggested with the last hex on the map counting effectively as the first hex off the map.
    - OK: Off the map is off the engagement. Willingly or not ships that veer off the map are assumed to have disengaged.
    - Wonky: Map border is a bouncy wall. Ships auto-rotate when they hit it.

    I also had another idea but I did not want to bombard you. Special moves/manouvres. These could take a set number of moves/turns and 'possibly make use of the 3rd dimension and neutonian physics' to move the ship in non-standard ways. Moving backwards or sideways for example, like you mentioned, or over/under (effectively through on the 2d hex grid) other ships.
     
    ^ Top  
  10. tiagocc0 Arcane

    tiagocc0
    Joined:
    Jun 29, 2007
    Messages:
    2,056
    Location:
    Brazil
    That would be nice, we just have to be careful for ships that run away too much from the centre to make them escape the battle or we could end up with ships too far away from each other and then waste several turns just so they could engage again.

    I see, if careful balanced those special moves could add the right flavor to make this a unique game.
     
    ^ Top  
  11. Shemar Educated

    Shemar
    Joined:
    Oct 16, 2010
    Messages:
    260
    Yeah, at some point you would have to call the engagement over. But that would most likely be the player's/AI's intention as even the bulkiest of ships should be able to turn iteself around in a space much shorter than long ranged weapons fire.
     
    ^ Top  
  12. tiagocc0 Arcane

    tiagocc0
    Joined:
    Jun 29, 2007
    Messages:
    2,056
    Location:
    Brazil
    One problem I had with these before is having two separated combat situations where 2, 3 ships would go east chasing the enemy while fighting them and another 2 ships going west chasing other enemy ships. The AI would employ a shot and move the farthest possible tactic so it would not care if one of their ships is close or not to the other. (Space Pirates and Zombies)
     
    ^ Top  
  13. Shemar Educated

    Shemar
    Joined:
    Oct 16, 2010
    Messages:
    260
    The truth is that you will always have 'wonky' situations. Sometimes it is about picking the least worst option rather than the best.

    The AI will be a beast for this game. For example it would be fairly simple to have each ship do what is best individually, but getting AI ships to work togtether effectively will be an interesting challenge.
     
    ^ Top  
  14. tiagocc0 Arcane

    tiagocc0
    Joined:
    Jun 29, 2007
    Messages:
    2,056
    Location:
    Brazil
    That's true.
    I'm itching to start developing the AI.
     
    ^ Top  
  15. tiagocc0 Arcane

    tiagocc0
    Joined:
    Jun 29, 2007
    Messages:
    2,056
    Location:
    Brazil
    ^ Top  
  16. Shemar Educated

    Shemar
    Joined:
    Oct 16, 2010
    Messages:
    260
    Your program already converts pixel coordinates to hex coordinates, why change?

    The coord system in the article has severe deficiencies, mathematically wise, the major being that most 3-ccordinate sets are actually invalid, so looping through them would be impossible.
     
    ^ Top  
  17. tiagocc0 Arcane

    tiagocc0
    Joined:
    Jun 29, 2007
    Messages:
    2,056
    Location:
    Brazil
    Oh, I thought it was a complete solution.
    I was thinking of when I will need to deal with AI, moving must be difficult on a hex grid.

    No problem then, I'm finishing the code so the ship will have direction and will show the path when you move the mouse within it's movement range.
     
    ^ Top  

As an Amazon Associate, rpgcodex.net earns from qualifying purchases.