Jump to content

  • Log In with Google      Sign In   
  • Create Account


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

#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).

#5191575 Is there a cheap okay rigging/animating tool that isnt blender?

Posted by on 06 November 2014 - 03:45 PM

You are probably overestimating the learning curve of Blender (you don't need to learn everything, only rigging and animation; hard to remember UI for modeling and the fairly advanced concepts and techniques needed for materials, rendering, compositing etc. are out of scope) and underestimating the learning curve of other tools (which, as you experienced, includes lot of testing and discarding; probably you could have learned how to animate models in Blender in the time you already invested).


Since you know that Blender is good enough, my advice is to assume a more open attitude (you are not a beginner!) and learn the bare minimum of Blender commands and concepts that you need for your tasks.

If you are really allergic to Blender (or other complex software) consider the tried and true solution of getting someone else to help you. This includes both recruiting an expert and convincing a generic friend to learn animating with Blender in your place.

#5191211 Minkowski Sum and tessellation

Posted by on 04 November 2014 - 04:25 PM

You have a polygon, with a single loop of edges, and you need to find all self-intersections, which is a simple matter of segment-segment tests (using a grid, quadtree etc. to reduce the number of tests).


After you find an intersection, it gets interesting: the edge loop is split into two parts, one on each side, and you need to delete the bad part (replacing it with the intersection point). Given a known "outside" point away from your line stroke (e.g. outside of the Minkowski sum of AABBs enclosing your original line and your pen shape) the piece you should keep has that point outside.

#5188605 Balance (early game difficulty) [strategy]

Posted by on 22 October 2014 - 03:29 PM

If, at the beginning, the player is weak, infighting and balance of power between AI empires would take priority over investing resources to wipe out the small player empire.

The player isn't much of a threat, and brutal aggression can have severe diplomatic consequences.


Imagine more rational counterparts of European powers in 1939: the player can be more or less like Poland (or a more peripheral place like Norway), but Germany wouldn't be strong enough to believe in successful world conquest, and invasion attempts would earn them momentary expansion followed by crushing defeat.


Another historical reference: the expansion of the Roman republic and empire due to the high fragmentation of other powers and its inclination for relatively peaceful mergers rather than destruction and extermination. How compatible are alien races with each other?

#5185621 How to implement curved boomerang ?

Posted by on 07 October 2014 - 02:59 PM

You can also apply an heuristic since the beginning of the flight: slightly different paths depending on the player's expected position after a certain time, when the boomerang comes back. Adjusting the endpoint as others have suggested can then take care of the prediction error.

In the simplest case, you can distinguish between walking and standing still; the player can be expected to, respectively, walk in the same direction for a large fraction of the flight time and for a very small fraction of the flight time. In some kinds of platform game you might be able to predict jumping down a ledge, interacting with an obstacle, and other variations.