Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 25 Nov 2005
Offline Last Active Today, 08:12 AM

#5218411 Projected Decals Stretching

Posted by on 23 March 2015 - 02:22 AM

Your projected decals look exactly like projections should, with the same extreme stretching you'd get from aiming a projector wrong into a room's ceiling and side walls: your problem is that you need something different.

To apply "stickers" onto surfaces you should use far smaller decals (more geometry but less fragments) and, for each small decal, use a projection vector that is approximately perpendicular to the target surface. In extreme cases, like "-X" in the last figure, no single direction allows good projection of a large decal and you might need to split it according to the target surface or to balance stretching of different portions.

#5218259 Armour & penetration

Posted by on 22 March 2015 - 09:45 AM

The WWII example is interesting, it sort of has a nice dynamic, as you end up with straight armor piercing rounds, armor piercing high explosive, high explosive and high explosive anti-tank. The first three tend to have a sort of rock-paper-scissor effect. The first round is great at penetrating, but doesn't hurt internals all that much, just pokes nice holes. APHE has less penetration, but if it does penetrate, does a good deal of system/crew damage. And then HE has terrible pen, but is good for unarmored targets, and is area of effect, and it also doesn't lose penetration over range and can be used for damaging external systems. HEAT is an odd duck of the bunch, and tends to mostly fall in the realm of being a better APHE, except not as good against certain armor types, in WarThunder it also tends to have terrible velocity.

No, there is no rock-paper-scissor relationship between different shell types because they have the exact same role: hurting what they hit, despite armour. With a single armour type (thick and tough steel) and no significant difference between the vulnerability of people and internal tank subsystems, the relationship between shell types and armour types cannot be more complex than the one-dimensional tradeoff that against better armour, shell designs that penetrate more at the expense of damage are more effective.

Such a choice of shell types isn't even necessarily relevant in the game, because:

  • Some shell types could be better in all respects than obsolete ones.
  • Some shell types could be preferable because they are cheap and plentiful. For example, if on average an enemy tanks is disabled after taking 4 AP rounds or 5 HE rounds and you can choose between going into battle with 15 AP rounds or 35 HE rounds, HE is likely better if getting shot at a bit more is acceptable.
  • Tanks don't necessarily carry different shell types.
  • Any available shell type could be too ineffective at a given size, requiring the adoption of bigger guns (as discussed in the OP), or conversely they could all be overkill.
  • Instead of switching to optimal shell types, tanks can switch to optimal targets. For example, if enemy tanks are very tough the tanks could usefully employ their mediocre guns against buildings and fixed defenses, leaving enemy tanks to infantry or artillery specialists with rocket launchers.

There can be rock-paper-scissor relationships beyond the narrow scope of armour penetration, in particular:

  • Focusing on a fixed budget, armour quality vs weapon quality vs number of vehicles. With the right realistic cost structure, swarming tends to beat weapon quality (the larger army shoots more against less targets), armour quality tends to beat numbers (as it virtually reduces enemy firepower and works better if one gets shot more), weapon quality can easily beat armour if good enough (taking advantage of armour effectiveness nonlinearities).
  • Focusing on the tactical level, armour weight vs gun weight vs being light and fast. The tank can expect to get hit and survive if slow and tough, to get hit less than normal because the enemy dies first if slow and well equipped, or to be missed if very fast.

#5217177 Dynamic Difficulty Adjustment

Posted by on 17 March 2015 - 04:15 PM


A situation in which specific levels can unpredictably become roadblocks, for example because many general skills (e.g. timing shots and judging distances for jumping) and game-specific skills (e.g. exploiting koopa shells and finding secret passages in Super Mario Bros.) might or might not be aligned between player and level, can be approached with suggestions ("Don't forget to use your flamethrower. It can be activated with button 2"), offers to run special tutorial levels ("Improve your aim at the firing range tutorial"), and difficulty settings, possibly allowing them to be set for each level.



Or there can be a “secret” passage that let's the player bypass the roadblock. Players will feel smart or happy for discovering this easier route, while hardcore players will love to take on the challenge. It can basically be a Skippable Boss, or an Easy Level Trick.

More simply, hard levels can be not roadblocks by not being on the critical path.


For example, Gemcraft: Chasing Shadows, a tower defense game, unlocks levels after beating other levels, lets one play any unlocked level at any difficulty setting, limits possible grinding, and "ends" after beating a certain level. Whenever the player is stuck there is a vast choice of other, quite different new levels and old levels that allow gaining experience point up by replaying on higher difficulty; eventually the player learns some tricks and/or levels up to be strong enough, and a level that was set aside is beaten.


Many games, mostly puzzle or action ones, adopt the even simpler scheme of freely choosing any level, or any small sequence of levels.

#5217034 Dynamic Difficulty Adjustment

Posted by on 17 March 2015 - 03:37 AM

The level that "got easier after the first couple times you died on it" is a very specific kind of dynamic difficulty adjustment, and in most situations not a good one:

  • It isn't very adaptive: what if the player was enjoying the retries and about to learn how to beat the level? Simple rules can guess wrong.
  • It is likely to be considered an insult: the game officially decides and announces that the player isn't good enough.
  • It can be easily perceived, even subconsciously, as a limitation of player freedom: the game closes access to the "true" version of the level.

A situation in which specific levels can unpredictably become roadblocks, for example because many general skills (e.g. timing shots and judging distances for jumping) and game-specific skills (e.g. exploiting koopa shells and finding secret passages in Super Mario Bros.) might or might not be aligned between player and level, can be approached with suggestions ("Don't forget to use your flamethrower. It can be activated with button 2"), offers to run special tutorial levels ("Improve your aim at the firing range tutorial"), and difficulty settings, possibly allowing them to be set for each level.

If the difficulty settings affect something simple and obvious, like increasing a time limit or making the character less vulnerable, instead of "corrupting" level features like enemy placement or obstacles, the player will be more confident at switching to harder difficulty when ready..

#5216249 Multiside space battles

Posted by on 13 March 2015 - 05:39 AM

If the battle is turn based and the display is abstract (stacks hurting other stacks) rather than spatial (ships aiming, shooting, moving into and out of range) you can display the stacks of the active faction in the middle and all enemy stacks around the borders of the view, with arrows or the like connecting attacking and attacked stacks. The enemies can be sorted conventionally (e.g. factions in alphabetical order by name clockwise from the upper left corner, stacks of each faction by size and age), the active stacks could be sorted according to graph layout heuristics (e.g. in a circle, about in front of the enemy they are attacking). You could then display nice animations of moving stacks between turns.


You might also go further with graph layout approaches, for example starting with all stacks around the border as above and pulling together two stacks when one attacks the other, resulting in stacks drifting close to their specific enemies over the course of multiple turns without large movements.

#5215626 x86 / x64 and the crazy conditional moves based on flags

Posted by on 10 March 2015 - 04:41 AM

I understand that a conditional move based on equality "maps" to c or c++ code like


but what about operations based on register flags like the carry flag? I understand the use of the zero flag for loops etc but instructions like cmovc and cmovp have me puzzled how they can be used practically


You try to reason about assembler at the wrong abstraction level; machine instructions have a direct and simple correspondence with high level variables, arithmetic, loops etc. only in easy cases, and optimizations (like using conditional move instructions rather than jumps and plain moves) tend to depart from the easy cases.

#5210109 Roguelikes and "dice"-based combat

Posted by on 11 February 2015 - 03:04 PM

A player who finds NetHack too complex and Rogue too random is on the wrong side of the learning curve and possibly unaware that there is one; and of course a player who considers the threat of dying of bad luck a "bug" rather than a thrilling motivation to manage risk shouldn't play roguelike games. 

#5209868 Movement in a Space Tactical Combat System

Posted by on 10 February 2015 - 02:55 PM

The "Battle Fleet 2" model might be suitable in real time, if errors are easily corrected and their effect is limited (reducing movement speed slightly, wasting or losing a small fraction of shots, requiring additional maneuvers in bad cases, etc.) but not if dexterity matters to the point of turning a strategy game into Angry Birds.


The "pirates" model is obviously good for turn-based movement, and well proven in tabletop miniature games like Warhammer and (closer to starship combat) Warhammer 40000.

To avoid frustration and players placing rulers and improvised templates on their screen, take care of assistance: for a tentative end position you can display (in real time) firing arcs and firing ranges, possible targets, movement ranges for the following turns, etc.


The "X-Wing Miniatures" model is also good, it merely has a different system of abstractions: discrete facings and combinations of facings instead of turning as much as needed to bring weapons to bear, and (usually; some games use a grid with Euclidean distance) an integer number of grid spaces instead of qualitatively different ranges. If the rules emphasize movement and agility and attacks are mostly at close range, a grid might be preferable (no pointless movement choices, easier medium-term planning); if spaceships have discrete weapons, each with their different and limited firing arc and range, freeform movement would probably be more natural (for example, you don't need to answer embarrassing questions like how large is a grid space or what happens if two ships are in the same space).

#5209275 Pacman ghost ai

Posted by on 07 February 2015 - 10:59 AM

Assigning a quadrant of the playfield to each ghost seems wrong; they are supposed to surround and chase Pacman, clustering around him until they are not only all in the same quadrant but close together. Barring wrong turns and lack of dexterity on the player's part, teamwork is the only way to become a threat.


You don't really need a good performance from your ghosts, Pacman needs a fighting chance. The ghosts need to follow naive and suboptimal rules, like the original ones.

For example: 

  • At every crossing, go straight if possible, else take the shortest path towards Pacman.
  • At every crossing, choose randomly among the paths that don't lead away from Pacman
  • Always the shortest path to Pacman
  • When choosing a direction at an intersection, exclude from consideration as if obstructed all corridors sections already containing a ghost (so that ghosts spread apart on alternate routes)
  • Follow a predictable patrol route until Pacman comes close (e.g. in the ghost's field of view)
  • Shortest path to the closest or second closest intersection to Pacman, to somewhere ahead of Pacman's movement, etc.

Note that the actual difficulty of the game depends very strongly on maze design.

#5208038 algorithm for bullets to base collision in space invader

Posted by on 01 February 2015 - 10:08 AM

You are calling DrawDamage() only once, with the data for a random collision, rather than once per collision.

#5203746 4X Game - Making sure players 'can't have it all'

Posted by on 12 January 2015 - 02:31 PM

From your descriptions, you seem to be neglecting a powerful tool: diminishing returns for making stronger ships, so that at the same building and operation cost a smaller fleet of the best ships the system allows is seriously weaker than a larger fleet of nontrivially designed specialized ships. This situation would remove incentives to explore degenerate and obvious ship design, greatly reducing the need to limit what can and cannot be built (all excessive designs would be failed player experiments).

Diminishing returns can be obtained by simple, player-visible means like increasing costs (of any type) faster than the corresponding benefits (e.g. baseline energy shields cost 1, double energy shields cost 3) and/or "taxing" the implicit complexity of multiple areas of specialization (e.g. having N major weapons costs k*(N-1)^2 material/time/money/energy to use/spaces etc. in addition to a fixed base cost of each weapon).

#5200556 Collision Detection Problem with Scale,Rotate,Fast Object

Posted by on 29 December 2014 - 09:08 AM

  1. As you are checking collisions every time step, you should be able to approximate the continuously changing collision shape of your character with a succession of slightly different shapes. Of course, assumptions about axis-aligned rectangles, testing exactly 4 or 9 tiles because the character is as large as one tile, and so on are limited to simpler cases; implement tests for arbitrary convex polygons vs. the tile map.
  2. Not a question. Where do triangles come from? Do you have sloped or partially solid tiles?
  3. Sounds like tunneling due to large movements. You should be able to figure out how far the character has to move (e.g. in a vertical fall towards a platform) from each valid position (e.g. barely above the platform, the worst case) to reach an invalid position (e.g. legs through the platform and feet in the air below it) beyond the range of correct ones (e.g. with feet penetrating the platform interior, which collision response will correct to standing on the platform).
    From this maximum movement distance you can either limit velocities to ensure that, even in the worst case, these movements do not occur in a single frame or subdivide each update in a sufficient number of simulation steps.
    For example, if the platform is 30 cm thick the character can fall at most 30 cm for update (less, to have some safety margin); a fall at 12 m/s requires 40 physics timesteps per seconds (more, to have some safety margin), presumably 2 for each redraw at 30 fps, while good behaviour at 30 updates per second requires reducing fall velocity below 9 m/s.

#5199501 Is it just me or are all horror game key hunts?

Posted by on 22 December 2014 - 04:22 AM

Getting out of a horrible place with minimum damage is a perfectly fine objective in any horror story with characters who don't have the obsessive motivation and/or power needed to fight back. Since achieving this objective has to be a long and nontrivial process (or there would be no story and no horror), key & lock puzzles are a natural design pattern to make player characters explore the place they want to run away from.

Key and lock puzzles as an excuse for horror moments become boring only if there is no development; a common but good resolution is accumulating resources, information and motivations as a byproduct of exploration and encounters until they cause an interesting change of purpose or strategy (a climactic fight, surrendering to death or self-sacrifice, realizing who the real enemies are...) to end the game or story.

#5197027 Fleets (as formations)

Posted by on 08 December 2014 - 02:47 PM

The most fun action to do, and the one that tolerates the most micromanagement, is moving fleets around to make them do something useful.

Building ships and fleets is a clearly preliminary task that should be simplified and stripped down to leave only the interesting decisions, such as what shipyards are most suitable, what ships models and improvements should be researched and produced, which assignments need new ships more urgently, etc.

Even using fleets could be boring; the player should be allowed to automate tasks such as patrol routes/zones, escorts of civilian convoys (possibly including escorting new military ships to their assigned fleet's home if travel is dangerous), generic travel, exploration with long range sensors, and so on.

There might be some opportunities to turn boring abstract actions into regular fleet movement (for example, explicit temporary fleets representing convoys of reinforcements or cargo ships instead of abstract movement of resources)


Regarding moving all units every turn, player attention to each fleet should be required every now and then (e.g. when a multi-turn order is finished) but optional every turn, with some appropriate user interface to efficiently exclude uninteresting fleets that should continue following the same orders.

For example, if the enemy Death Star is detected, the right turn to inspect all fleets, decide which ones should take part in a great offensive against it, and changing their orders to execute the new strategy is right now, regardless of feelings about micromanagement. The player would simply enjoy a special, important "big turn".

#5196953 Best way to follow a moving object

Posted by on 08 December 2014 - 08:34 AM

Adding to ApochiPiQ's suggestion, you can obtain better incremental pathfinding at a higher cost by discarding the last part of the old path and extending the chaser's path from there, with increased opportunity to take shortcuts against the target's meanderings. At most, you can discard the whole previous plan, going back to non-incremental pathfinding. The amount of discarding can vary adaptively (e.g. according to how much of the last discarded path portion is reconstructed without change).