# Inmate2993

Member

1085

222 Neutral

• Rank
Contributor
1. ## Miss Dodge Hit Calculation Problem

An alternative idea might be to use that Hit% and Evade% as a damage reduction factor. Since HP is regarded as an abstract meter, with every Hit Point representing an ability to deflect a blow from being fatal (with the last HP being the end of that ability). What this means is that every attack would be considered a guaranteed hit, but using Hit and Evade values to determine where the floor parameter of the randomize-damage function lies. (The Offense-Defense values determining the ceiling). My version of this calculation would be something like this. DamagePotential = AttackerOffense - VictimDefense DodgeRate = VictimEvade / AttackerHit DamageActual = Random( DamagePotential * DodgeRate, DamagePotential ) In practice, this formula would probably need a lot of tweaking.
2. ## Turn Based Strategy Movement

Under the A* Pathfinding, assigning different G values to the terrain, and keeping the H heuristic admissible, will find the perfect route every time. There's a couple of things to note about using transports: At the node where a transport can be invoked, each subsequent child node added to the open list should check if it was in the transport at the parent node, to alter the G values. Because they would have a better G value, these nodes have to displace any existing nodes for the location on the open list. This means you can't use a priority queue, and may have to find a better alternative, such as a hashmap.
3. ## Control Scheme for Space Flight

Since it's a game and not a flight simulator, I would say have the LEFT and RIGHT arrows act as a combined yaw and roll control. I believe this was how the starfox games worked. Your area of uniqueness, since it's full 3d, and not 3d on a plane, would be that the spaceship doesn't have to automatically return to that plane, but rather the camera rolls to match the spaceship's plane.

The problem with quick-saving isn't the act of saving at all, it's the act of loading. I could save every turn on an TBS if I wanted to, it wouldn't affect the outcome of a single thing. It's when I reload one of those saved games to redo a particular thing that produces this perceived problem. Some suggest the delete-on-load to fix this. I'm not a big fan of this, given the loss of the crash-protection aspect of saved data. My personal advice would be to fix the part of the gameplay that could be exploited by reloading. If there's a 1 in 10 chance of the enemy automatically killing the player's unit, and the player saves before the fight to remove that possibility, then you have a faulty gameplay mechanic there. The better solution might be to randomize each unit's private unique ID on their creation, and have that 1 in 10 chance of kill be tied to the unique IDs conflicting somehow. That way, a given unit might always face losing against that specific enemy, regardless of the quicksaving.
5. ## Very quick question. (Sorting)

If you pass on the std::list solution, I would recommend a Merge sort, as it's fairly easy to implement. One note to make, however, is that you'll probably have to sap up some memory for the arrays needed for Merge, and the two additional O(n) operations copying the list to an array, and then creating a list from the sorted array.
6. ## Status Changes for my Action/RPG (Revised)

I would suggest having the degradation of the status effects be gradual, and that their initial stats be interleaved, so that typically, only one or two would ever become a problem at any given time. For instance, say at the start of the game, rather than every bar resting at 100%, all waiting to drop to noticeable levels at the same time, start hunger at 75%, so that it would be the first issue the player would need to deal with, and without interruption from others.
7. ## 2D Side-View Pathfinding

A* would still work, except now it's your G values and children nodes that have to be accurately computed. Each node should know its parent node so you'd have to calculate how far it has moved in, say, a jump, making the G value of moving from in a pit to on the floor above it being the maximum integer (since that would be impossible), or not even appear on the children node list.
8. ## A* on a multiple tier map question

The children node of a layer-switching node (a staircase) would include the higher layers, so there's no real problem there. Your heuristic would probably still be a normal distance formula, only with the Z direction appropriately scaled. If your Z size between layers is the same size of the X or Y, then this isn't an issue.
9. ## A*, so close to getting it working.

Do you have a "tie-breaker" to resolve the issue with multiple successor nodes all having the same F values? For the sake of argument, I'll guess no. G is indisputable, as it's the actual cost value, and shouldn't be tampered with. However, H, the Heuristic, is a guess value, and should be carefully tweaked to represent, as close as possible, the cost of the remainder of the trip from the current node. However, with heuristic distances like Manhattan and Euclidean, a lot of nodes will be have the same F distance from the target node (after combining H and G) and will all be considered, wasting time and deprioritizing your open list. The solution, which you should play with, is to add a Tie Breaker to the H value, so that the resulting F values won't all be equal. The easist tie-breaker, is to multiply H by 1.001. The larger the H distance, the less nodes will be considered at the start of the pathfinding. However, this might not fix the zigzagging. Another solution would be to figure out the Cross product of the deal, and use that to form a line between the start and end, which it'll try to follow as best as possible.
10. ## Annoying In-Game GUI?

The best UIs in my experience are the ones that integrate themselves well. It's no coincidence, for example, that the corners of the screen are where more things appear. Those spots out of the way, because vision is circular. However, the center of the screen could be a good place for things that are very immediate and neccessary. Crosshairs. A UI becomes intrusive when it shows you things that you don't need to know. A distance to something when I'm not facing it would be something that's intrusive.
11. ## SDL Fullscreen

SDL may have given you a shadow surface. Use SDL_GetVideoInfo and SDL_ListModes before hand to make sure you are getting the actual surface you want.