• Content count

  • Joined

  • Last visited

Community Reputation

4466 Excellent

1 Follower

About LorenzoGatti

  • Rank

Personal Information

  • Interests

Recent Profile Visitors

22008 profile views
  1. It depends on the design of your game. First of all, you say a switch statement would be "huge": does it mean that there are going to be many potion "SKUs", many essentially different potion effects requiring separate specific code, or both? In general, switch statements are appropriate for a small and stable set of alternatives: probably not potion types. If potion effects are shared between many potions (e.g. one potion gives a lot of mana and heals a few hit points, one gives a little mana and heals many hit points, one heals hit points only) or with other sources (e.g. a bath in an enchanted fountain restores mana or heals hit points like drinking a potion) you can reduce duplication by focusing on the effects (e.g. a routines to heal N hit points , add N mana, etc.) and describing potions with a data structure listing their effects and other properties (e.g. "this potion is called potion of invigorating healing, it is pale blue, it heals 45 hit points, it gives 3 mana, 3 energy, 0 experience"), even without an ID. Then when a potion is consumed you would go through its description, processing general drinking rules (e.g. choking because of bad taste) and effects one by one in a standard order, without low value potion-specific code, This data-driven approach would facilitate potion variations by allowing them to be anonymous, whereas potions with the same ID would have to be identical. Potions could be generated randomly (e.g. average strength of healing potions increases proportionally to character hit points, and they are all a "potion of healing"), altered (e.g. by mixing them), deduced from other data (e.g. distilling a corpse produces a potion with effects that depend on the creature).
  2. C++ C++ saving this ptr offset

    Mixin classes imply inheritance, and inheritance defines a class hierarchy whether you want it or not. You don't have the privilege of "avoiding" inheritance by hacking around with reinterpret_cast and the like instead of using polymorphic pointers properly.
  3. Do You Like Time Trial Modes?

    Why? Shouldn't you have a single leaderboard for "view switched as the player sees fit"? If switching view between first person and third person is a meaningful tactical choice, there doesn't seem to be any reason to forbid it; if either view is strictly better, it will be used almost exclusively in the good games in the leaderboard, but it isn't a problem. The only role I see for forbidding view switching is in multiplayer games where some or all players agree to use the bad view, respectively as an handicap or as an increase of difficulty.
  4. C++ C++ saving this ptr offset

    This also means that optimizing access from a component of an entity to other components of the same entity has limited usefulness. Most computations are going to involve components of different entities, and often the same type of component for many entities (e.g. collision detection and response using the respective geometric shapes of entities).
  5. Physically Accurate Material Layering

    The metallic flakes are obviously repeating: are you using an excessively small texture (maybe shrunk by inappropriate texture mapping)? Can you afford procedural "noise" for the normal map?
  6. what is the appeal of fps games?

    The appeal of FPS games is unusually realistic and immersive combat. Even with implausible weapons and unnatural physics, the experience of running, jumping, turning, looking around in a solid environment is close to the player's body perception in a way that is impossible for other kinds of equally twitchy realtime games (e.g. a RTS where you scroll a map. point with a mouse and press buttons or a driving simulator where you learn to master the controller, not the vehicle itself). FPS games can have genuine differences, but the fundamental similarity makes the differences minor and, from a more technical point of view, games can be usually altered drastically with easy and "superficial" tools (level design, weapon selection and if applicable placement of monsters, traps, bonuses etc.) making FPS design a matter of making a capable FPS engine first and defining gameplay details second.
  7. Could do with a little perspective on something....

    From a professional point of view, being paid should be the first priority. If you have no control and you are sure the project won't be profitable, it's time to let the more optimistic members of this hopeless team fail without you, and get a paid job. Consider the money you invested as the cost of learning game art animation etc. and acquiring valuable experience about teams, projects and people; it's clear from what you write that the price of wisdom could have been much worse.
  8. Does u,v,w texture mapping exist?

    Do you expect your mesh to contain 3D texture coordinates? It doesn't seem likely.
  9. Boids, a way not to check flock every update?

    Remember you don't need full flocking computations for every zombie at every frame: they can decide periodically (go straight for N frames unless they hit a wall), abandon flocking for a variable time while they follow a fixed path (e.g. from the beginning to the end of a narrow alley), spread computations over multiple frames.
  10. Any idea on this boss mechanism?

    Maybe the boss (assuming it sees through fog) could throw something at the player: it would provide interesting dodging action (perhaps while the player is busy dispersing fog) it would indirectly give away the location of the boss, so that attacking blindly (e.g. by aiming a crosshair to an arbitrary place on the screen) becomes meaningfully skil-based rather than pure guessing.
  11. Best way to create a nice looking card game?

    You might be overestimating the effort to make your game look good enough. If you don't sell the game, and possibly earn a little money by letting people play it online freely on your site (attracting visitors, advertisements, donations, maybe gambling, publicity for a future physical version...) there's no need for fancy graphics with expensive assets; you just need dragging and dropping cards, chat etc. with a pleasant UI. As examples of this relatively spartan card game style, I recommend looking at https://epicmafia.com/home (particularly the "games" lobby, Texas Hold'em in particular, but also the fancy chat and the use of icons in the main mafia game) and https://www.alternativeoutput.it/brisk/ (visit around lunch break GMT and prepare to be insulted for playing badly).
  12. Historic unit types

    This seems a backwards approach to designing your unit roster. I don't think you want to spend time and money on assets and game balance work for redundant units that serve only to confuse the player. Instead, you should start with a small set of units that work well together, introduce advanced newer units that disrupt existing tactics, and then figure out what they could be. For example, what unit can seriously threaten naked cavemen with stone-blade axes? Someone with good ranged attacks: naked cavemen with stone-blade axes and several spears p.c., which should be at the exact same tech level but much more expensive.
  13. C++ C++ IDE for Linux

    Emacs needs some plugins and external tools to turn from a "raw text editor" (are you kidding?) into a C++ IDE, but it is fairly lightweight and good-looking, it supports mouse use, and it can search symbols across files beyond your wildest dreams. The main pieces are defining "projects", creating symbol databases, compiling the project and providing a GDB front end, and there are redundant options for each.
  14. Lead Moving Target with Moving Shooter

    Sometimes you should because it's appropriate for the game. If the "shooter" is a grenade-throwing killbot attacking trespassers, what should it do if not measuring target speed and velocity, computing an exact solution and lobbing the grenade exactly there? It's not only realistic for an AI with excessive computational capabilities and motor control accuracy, but transparent for the player and interesting to interact with (player controlled trespassers need to take cover or to change velocity while the grenade is in the air). Other kinds of shooter, like artillery in trench warfare, might be more realistic if they guess iteratively, but even in that case if they are remotely competent the exact computation, maybe perturbed with inaccurate position and velocity measurements, is needed as a starting point.
  15. Lead Moving Target with Moving Shooter

    If you choose a frame of reference in which both target and shooter are moving at constant speeds vt and vs, follow the calculations in the article pretending vt is vt-vs and vs is 0. Times are unaffected, while if you want the projectile velocity you need to add back vs.