Jump to content
  • Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

4484 Excellent

1 Follower

About LorenzoGatti

  • Rank

Personal Information

  • Industry Role
  • Interests

Recent Profile Visitors

22950 profile views
  1. You can set a upper and lower limit to "unit scale" map by map to keep normal armies in a tactically acceptable range between a little sparse and a little crowded. Since more units need more orders, the amount of micromanagement (between too simple and too frantic) is likely to be a more restrictive limitation than occupied space. However, "unit scale" is a distortion that departs from the ideal map scaling. If you want levels with unusually large or small forces, the first choice should be adjusting the map (keeping approximately the same walkable area per unit or the same distance to the enemy in all levels, scaling road width to who's supposed to use the road...) and the difficulty (to require more orders when there are fewer units)
  2. LorenzoGatti

    Providing equal opportunity for each player

    Given a randomly generated rectangular half-map, you can obtain a full symmetrical map for two players in 8 different ways, attaching a vertically mirrored copy at the top or at the bottom, a horizontally mirrored copy left or right, or a rotated copy (180°) to any side. You can even make a symmetrical map for 4 players by copying a random querter of the map both horizontally and vertically. On a hex grid, you can attach six 60° slices or three 120° slices for a symmetrical map suitable for 2, 3 or 6 players. In any case, random resource placement without perfect symmetry is automatically unfair. Don't do it, unless you recover fairness by having matches consisting of two games with swapped starting positions.
  3. LorenzoGatti

    [question] Can you name this image software?

    Adobe Photoshop, I'm not sure about the exact version used in the video but for you getting the newest one should be a safe choice. Edit: and of course Unity and Map Magic, but it should be obvious from the video title...
  4. I don't think you are describing a RTS game, except in the most formal sense of featuring multiple units that can be given orders in real time. Steady resource influx and resource attrition is a cornerstone of typical RTS games: there can be an occasional blunder or stroke of luck, but on the whole victory goes to the player who makes the most efficient use of resources (by turning them into units and using units to destroy, over their lifetime, units worth more enemy resources than their cost). If instead, you have peon units exploring the map to collect parts of dangerous units, and in a later phase assembled dangerous units doing real fighting, very different patterns are to be expected: It can be a game about exploring and scavenging, in which the first player who completes a killbot wins by using it to exterminate the enemy without significant opposition (and without significant fighting, only a boring final demolition) It can be a game about building the killbot as fast as possible, for all practical purposes a planning and dexterity puzzle in which the map doesn't matter except for constraining building placement. It can be a game in which killbots are easily built, the fastest builder has a modest advantage, and the main activity is a fair battle (in fact, a very non-RTS-like arranged duel at a leisurely place, since with nothing left to build or collect there is no time pressure) between very similar small forces.
  5. LorenzoGatti

    XP for Feared/Enraged/Calmed enemies?

    It also leaves the programmer free to deal with the game without worrying too much about the metagame: the guarantee that any successful course of action gives the same amount of XP means that there is no risk of the player progressing past the orc encounter with too much or too little experience. It's still possible to spend excessive amounts of resources to overcome the orcs, but providing means to recover resources (e.g. allowing the player to assault orc archers to collect their arrows) is easier than dealing with abnormal experience levels
  6. LorenzoGatti

    Swing-Twist Interpolation (Sterp), An Alternative to Slerp

    Interesting, but I wonder about the example and possible generalizations. You choose the the rod's axis as the twist axis, which looks good in the example, but what twist axis is best in less obvious cases? For instance, rotating a cube. Decomposing the full rotation R as R=S*T and interpolating S and T separately obviously generalizes to splitting R into a product of three or more rotations and to interpolating the rotations at different variable speeds. For example, mechanical parts could do all or most swing before braking hard and beginning the twist (probably a much "smaller" movement).
  7. LorenzoGatti

    Loop Decorator Node design

    If the "loop decorator" you are talking about resembles the Unreal Engine one (repeat the child node N times or forever, presumably stopping when it cannot be performed) it must not matter whether it's the child of a composite node, or which type of composite node: after all, the execution of the loop node should be indistinguishable from the execution of a sequence (or other composite) of the appropriate number of identical nodes. Thinking the parent composite should deal with the loop counter of its loop child is particularly wrong. "Resetting" the loop node to execute it again is also a non-issue: the loop always runs until it stops (running out of iterations or having its child fail), so it can reset its loop counter etc. either at the beginning or at the end of execution, unconditionally.
  8. Translation doesn't simulate zooming, it aligns zooming with the intended target. Changing screen space X and Y scaling (X to kX and Y to kY) is a formally correct zoom, but it zooms "around" X=0 and Y=0 (the point of the screen, but also the line in 3D, which remains unchanged). Instead, if the mouse is located at Xm and Ym in screen space and you want the point under the mouse to remain in the same place, the transformed screen space coordinates should be k(X-Xm)+Xm and k(Y-Ym)+Ym. Depending on the purpose, you might want to further modify the transform by moving the point under the mouse towards the center of the viewport instead; adjusting with rotations the world space to screen space transform that represents the "camera" in 3D to look at an appropriate mouse controlled point might be necessary (commonly done in FPS games, if you want examples).
  9. LorenzoGatti

    Action combat without accurate, visceral animations?

    Exactly; and also what it is meant by "fuzziness": differences between sprites and hitboxes? deliberately unclear animations? Expensive details? Animations need to be accurate enough to support the desired kind of interaction and tactics: for the kind of "action combat" you describe the exact shape and position of the body of fighters needs to be visible and unobstructed, inaccurate animations would lead to inaccurate playing. Consider the difference between fine-grained movement (e.g. most popular 2D and 3D fighting games allow creeping back, forward and possibly sideways very slowly) in which distances need to be measured exactly and coarse movement (e.g. on a grid, like in roguelike games or Bomberman) in which the player only needs to distinguish which places in a small set are empty or occupied and therefore graphics are allowed to be symbolic and less realistic.
  10. LorenzoGatti

    Simple Windows C++ IDE

    Visual Studio has a large "surface", but most of it consists of commands that are either intuitive or irrelevant (if you need them, you know them). The only parts that need study are simple and straightforward, and as suggested following some tutorial would be a good approach to learn about them: general operation (docking windows, options, extensions, NuGet) the basic structure of solutions, projects, references, project properties, source control the handful of commands and windows you'll repeatedly use to build, deploy and debug applications specialty features and tools, e.g. (possibly) building the application with CMake or even with Make and GCC
  11. After realizing some game systems need to interact, you can find a way to let them interact nicely, minimizing complication and coupling. In the quest system example, I would introduce a new object type that could help distancing the inventory, the quests and the notification log: an inventory query specifying some items with possibly incomplete criteria ("a magical cutting weapon with a +3 enchantment or better" and a name that begins by P"). Why? An inventory object can answer whether it contains the specified items in an inventory query at any time without consequences; it is an obviously idempotent operation, it doesn't change the state of the inventory, and it preserves encapsulation in the best possible way. Crucially, an inventory query is part of the inventory system; it doesn't introduce a dependency from the inventory system to something inappropriate. A quest factory can create inventory queries along with other quest requirements: they aren't as "special" as throwing around ad-hoc references to quest or inventory objects. Other quest requirement types would be other kinds of game state queries: about who is dead or alive, where the character is located, whether something has been activated/opened/broken etc. Quests can check their respective inventory queries on the player inventory; it's reasonable to expect a quest completion checking processing step that has a reference to all game state (of which player inventory is a part) and tests all completion requirements of all quests. This quest processing step could easily prepare notifications for the log system to show, even aggregate ones across multiple quests ("you have all items needed for quests A and B but you need a spade and more sparrow blood for quest C and a wheelbarrow and a spade for quest D") and multiple requirement types ("you are missing a rabbit for quest A and you need to enter the volcano for quest B"). The quest system would be the natural source of messages about quests because it is the only place that knows all details of all quests; to avoid functional duplication the only smart things the notification log system should do with quest messages are generic ones that aren't related to quests, like squashing repeated or low-priority messages, making important messages more visible, etc. Arbitrarily classifying notifications (e.g. "quest completion update") and passing metadata about them (e.g. "game world change details" vs "game world status summary" vs "speech" vs "pedantic combat statistics") could allow the notification system to process notifications smartly without really knowing what they are, for example displaying quest status messages only when they change.
  12. Your conditions, that either side of the meteor bounding box overlaps the player bounding box, are incorrect. For example, suppose coordinates of meteor and player top and bottom are, in increasing order, Mt,Pt,Pb,Mb: coordinates overlap, but the player is "inside" the meteor (which is larger, 50x50 rather than 35x25).
  13. You appear to be discussing exploration of the static features of the map, not fog of war. Fog of war returns as soon as no unit is watching a certain part of the map, making most algorithms discussed so far pointless (for example, there's going to be a single connected component of fog, with a hole around your agent that corresponds to their field of view) and a single "explorer" completely inadequate.
  14. LorenzoGatti

    Increasing difficulty algorithm

    It is a level design problem, but the "level" it applies to, as already noted, is not a single wave of enemies but the actual unit of play: a whole session, from the first wave to losing as the game becomes too difficult. I think the main question that should guide you is how you want your players to lose. There are good and bad ways to fail. Because a brick appeared and reached the bottom faster than it could be reached and shot? Quite unfair. Because their firepower cannot possibly be enough for very many, very resilient bricks? Rather unfair, because skill should give the player at least a slight hope of progressing further. Because they failed to address some particularly dangerous brick, shooting low priority ones instead? Much better. Because they missed a needed powerup, falling into a firepower problem? Also good. Because they aimed badly and wasted bullets? Another important facet of player skill. Because of many little mistakes with a cumulative effect? Great, provided the player is aware of the mistakes. Because they got tired or their joystick and button fingers began to hurt? Acceptable, provided the game wasn't boring and overly long. I suggest ensuring that there is a way for a player of perfect skill to beat ANY wave. Not only powerups need to increase proportionally when bricks are more numerous and tougher, there must be an actual way to shoot them all efficiently and not too late. For example, a player ship with slow lateral movement could waste too much time in front of gaps with nothing to shoot at, reducing its effective damage output. An AI playing the game according to heuristic rules and with perfect aiming could provide a useful benchmark (if it loses, the level has a problem; if it wins, players can win too). I suggest increasing difficulty in the first part of the game, as a warmup, then varying enemies, formations and powerups without actually increasing difficulty. Sooner or later the player will fail to solve some unexpected efficiency puzzle.
  15. I don't see how "Religious & Culturally Meaningful" avatar features could be used in offensive and inappropriate ways. If these features are part of a standard avatar, managed by the application, they cannot possibly be associated with hostile text and imagery; the worst possible avatars would misrepresent a user as a member of a different ethnic or religious group (not something you want to police) or would be incoherent and bizarre (e.g. a woman with a turban, or a Hindu-Jew hybrid with caste marks on his forehead and a kippah). Even a "Religious & Culturally Meaningful" category could be a problem: it could draw objections from someone disagreeing on what should be in and out, and there is a large gray area of traditional but not really important stuff. For example, you'd have to draw a very arbitrary line between fancy headscarves and foulards for all women and "religious" Islamic ones. I'd prefer neutral categories where someone interested can easily find what they want: "hats" (including "turbans", "fedora" etc. as subcategories), "hair", "body painting and make up", "earrings and piercings", "pendants", and so on.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!