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.
Banner advertising on our site currently available from just $5!
LorenzoGattiMember Since 25 Nov 2005
Online Last Active Today, 10:23 AM
- Group Crossbones+
- Active Posts 1,678
- Profile Views 10,284
- Submitted Links 0
- Member Title Member
- Age Age Unknown
- Birthday Birthday Unknown
Posted by LorenzoGatti 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).
Posted by LorenzoGatti 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.
- 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.
Posted by LorenzoGatti 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.
Posted by LorenzoGatti 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).
Posted by LorenzoGatti on 29 December 2014 - 09:08 AM
- 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.
- Not a question. Where do triangles come from? Do you have sloped or partially solid tiles?
- 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.
Posted by LorenzoGatti 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.
Posted by LorenzoGatti 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".
Posted by LorenzoGatti 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).
Posted by LorenzoGatti 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.
Posted by LorenzoGatti 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.
Posted by LorenzoGatti 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?
Posted by LorenzoGatti 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.
Posted by LorenzoGatti on 13 September 2014 - 12:15 PM
Assuming you are making a FPS-like game with small battles between a few player-driven or AI tanks, you should consider how stats affect combat.
- If a tank is slightly faster than normal, is it really better than a baseline tank? In which ways, and in which circumstances?
- Can the environment or the kind of engagement make the advantage useless? For example, the fast tank could pass the whole battle in the same place in a sniper role or stick behind cover without serious movement.
- Assuming being fast is good, what can you worsen to make the slightly fast tank fair? For example, slower turning can compensate faster straight movement. There's no reason to assume "power" (by the way, what is it?) is the right choice, only because it's the stat you have already designed
- As the fast tank becomes faster, what are the qualitative tactical changes? Are they good variations, or boring easy strategies? For example, a ridiculously fast tank would be able to dodge artillery if there's enough room, which could be a good thing if obstacles make dodging challenging or a bad thing if nobody ever hits.
Posted by LorenzoGatti on 08 September 2014 - 03:45 AM
I thought the hunter would be more of a crossbow/axe kind of hybrid, but sword may very well be more efficient.
This sort of consideration needs context:
- what monsters are being hunted?
- how do they fight back?
- what other cases of combat deserve an investment of suitable weapons and related resources?
For example, good crossbow targets are hurt seriously enough by one hit to fall down or, at worst, wander away harmlessly to die elsewhere, while bad crossbow targets are likely to just get angry if hit. Since a bow can be reloaded much faster, it's usually better because the range of good targets includes anything that can be brought down with 2,3 or more hits (depending on how long it takes to fight back), leaving only some niches for the higher power crossbows: extremely long range, armored targets, anything that allows only one shot before reacting very effectively. What kind of armor are witches and demons wearing? How fast are they with magical attacks and movement?
Another example: melee weapons and defensive equipment. An axe might be good to decapitate a vampire in combat, but worse than a wooden staff if the vampire is fast and armed with a rapier. Long polearms might keep creatures of the night at a distance, but not among thick trees and bushes. Heavy steel armor is effective, unless "heat metal" spells like in D&D are common enough to become a standard tactic.