Jump to content
  • Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

4496 Excellent

1 Follower

About LorenzoGatti

  • Rank

Personal Information

  • Role
  • Interests

Recent Profile Visitors

23642 profile views
  1. Your family of overloaded functions or your function template (why do you have a struct template instead in your code example?) should not try to list types in its name; it should be named for what it does. Forbidding unsuitable types is a job for the function implementation, presumably by testing compile-time predicates.
  2. LorenzoGatti

    Power plant types in sci fi empire builder

    Find meaningful power plant varieties, don't put them in the game only for "realism". Given the obvious baseline of "whatever power plant type is appropriate for a planet and its resources", making the player decide what power plant to build, or even explicitly giving details of what the actual power plant types are, should bring some value to the game: There could be important "side effects" beyond energy. For example, a fission power plant can produce weapon-grade plutonium in addition to energy, which matters a lot if nukes are an important weapon, geothermal plants can make cold planets habitable, and exotic ultra-tech power plants could be high performance but easy to blow up. There can be ties to the story and world settings. For example there could be a choice between mundane power plants and advanced alien technology-based power plants that perform much better, can be obtained as a favor from a certain faction, and can be remotely disabled by the aliens in case you cease to be their friend. There can be a thematic relevance; for example, fission and fusion power plants, with their opportunity for radiation and accidents, are appropriate (excluding other less dangerous types) if the game is about mitigation of widespread radiation and contamination from nuclear weapons, radioactive materials, space phenomena etc.
  3. There are two important optimization opportunities: Consolidating any number of transforms into a single matrix, saving computational effort compared to cheaper but repeated calculations. Anything can be transformed with a matrix-vector multiplication. Hardware accelerated matrix-matrix and matrix-vector multiplication is worth implementing. The special case transforms in your library are highly likely to cost more than the general case on the GPU.
  4. LorenzoGatti

    Need suggestions and ideas for this building design

    A whole building dedicated to an arcade looks strange. Arcades often occupy a small portion, either on the ground floor or an upper floor, of some residential or commercial building, including shopping malls. Conversely, if you want a relatively large building for use as a game location you might choose a better looking general category, e.g. a diner that attracts the same youths as the arcade and has interesting architecture and furniture.
  5. LorenzoGatti

    Anyone use Dear ImGUI?

    Techniques aren't mutually exclusive; in a typical game there's a place for using Dear ImGUI for in-game developer tools (property panels, editors, graphs...), whatever 2D overlay rendering your game engine offers to draw a HUD, non GUI related libraries like ICU or Freetype to handle text, generic custom "services" like rendering text to textures, a simple custom GUI framework that fits well with the rest of the game engine for simple GUI with simple variants (e.g. fullscreen menus), and harder to use complex skinnable GUI libraries for complex cases.
  6. The Horten 229 (presumably small, fast and stable enough to show promise as a fighter) appears to have reasonable engines (below the wings, with a large indentation to avoid the exhaust), a significant positive dihedral angle, and a thick and bulbous fuselage. I think this design falls in the gap of relative ugliness between large and elegant flying wing designs with an iconic chevron shape (all bombers, of course) and extreme and futuristic stealth fighters with faceted shapes like the F-117. At an intermediate size, it could be a boring ECM platform or small bomber, but it's too large to be a fighter; maybe you should design weapons too.
  7. LorenzoGatti

    Revival Gaming

    Feedback: If you have a crowdfunding campaign, link to it. Hire a spelling checker. On your web site, spending a greater than zero number of words to explain what your game is wouldn't be a bad idea. "Introducing" and "watch our trailer" don't count as descriptions.
  8. Some parts have really strange shapes that look wrong, not futuristic, to me: Bent and elliptical engines. Reaction engines and variants thereof are strictly cylindrical. EDIT: thinking of it, engine asymmetry is possible with obviously external components: fuel tubes, extra air intakes, pods... Engines ending in the middle of the wing. Realistically, they would scorch the wing structure (possibly beyond the melting point) and disrupt airflow. Plausible similar structures could have one engine above the wing and one below, with sufficiently distant exhaust ports. But why bother, if you can simply mount the engine slightly further and avoid the wing completely? No tail; the front winglets and the point in the back are both very small. Tailless aircraft usually have wider wings and/or a less flat body..
  9. LorenzoGatti

    how does one typically model an anime character?

    Can you draw your anime character with pencil and paper, without technical complications? If you fail, or if it looks bad, you need more experimentation (or the help of a better manga artist) to obtain a better and/or more defined character design before attempting a computer version. If you can draw your character, you can use your drawings as reference material. Please explain your workflow (2D painting with a tablet? 2D painting with vector shapes? 3D model from scratch? Adapting a 3D model? Something more complex?) and what your eyes don't fit with.
  10. Your idea is a game with unusually many characters (unusually low-detail graphics in order to show them all are a logical consequence). Making these characters complex is a problem and a cost, not a feature. You appear to be pushing the limits of gratuitous complexity, rather than trying to find something for the characters to do and an effective and interesting way for the player to interact with them; you don't have to remake Dwarf Fortress. For example Liquid War is a very simple RTS with very many units, represented as single pixels.
  11. DP_PLAYER *player = network.FindPlayer(msg->dpnidPlayer); If you have player IDs, why don't you use a much more natural and deletion friendly std::map (from the type of the id to DP_PLAYER*) instead of a std::vector? The existence of network.FindPlayer() suggests that you already have such a map.
  12. I think a visible grid would help, particularly to solve ambiguities between height variations and horizontal displacements, count horizontal distances, count height differences (this tile is N layers above the adjacent tile). Seamless isometric graphics work well with simple natural shapes and ramps, like in Starcraft, not with stylized steps. Alternatively, a nicer map structure would be legible without needing outlines; I don't think a regular structure (e.g. Q*bert) could be an option given the current screenshots, but maybe you can decide that the game is set on a slope (given two tiles if x1>x2 or y1>y2 then z1>=z2) to prevent occlusion and avoid having to turn the viewpoint.
  13. LorenzoGatti

    RTS Unit Production

    It looks like a type of game that requires frequent turnaround of unit types to build, not only because with a small amount of units every one of them matters but because you need to adapt to enemy moves (a single enemy unit can tip the scales) and to early/middle/late game phases and different strategies. Automatically building the wrong unit in this situation would be far more catastrophic that building it late because the player was too busy to give an explicit command.
  14. LorenzoGatti

    RTS Unit Production

    A good point. Continuous unit production is common in 4X strategic games where planets have to be kept busy and extra units tend to be always useful (often to create extra fleets and defensive forces and do something specific, and at the very least, to crush the enemy more severely through more excessively superior numbers, and win faster). Building a unit in this sort of game is not a significant move (convert X resources to the best possible tactical impact on current and near future battles), it's something that keeps happening, as often as possible, thanks to strategic level moves..
  15. Observations about individual weapon types: HCSA firearms aren't particularly high-tech. In the future, something more advanced than an assault rifle with a 30-round magazine should be rugged enough and cheap enough for battlefield use. In what ways is this assault rifle better than a Kalashnikov, reflecting centuries of progress? HCSA spikers could be low recoil: really fun APFSDS spikes should have rockets. Also, how exactly would an armor-piercing projectile drain energy shields better than the same kinetic energy delivered with multiple bullets? HCSA lasers cannot have such long pulses that they need tracking. A bullet at 2000 m/s covers 10 m to a target in 5 ms; even ridiculously long laser pulses of several nanoseconds are much faster. Rather, thermal dissipation and power management issues can require the laser to shoot many low-power pulses, with the appearance of long pulses, bursts, or even continuous operation. HCSA pulse projectors are not likely to work as directed "projectors"; in particular, a magnetic field would be bent or diffracted by any small obstacle, without stopping. You could stick to omnidirectional EMP grenades, which if one of the other faction consists of robots should be a common weapon. HCSA "electrolasers" aren't very plausible; for the purpose of frying electronics at a distance you could use appropriately futuristic x-ray lasers or less erxciting particle accelerators that can cause ionization inside semiconductor devices, typically with permanent damage. .HCSA particle projectors compete with shotguns and chainsaws, both as useful weapons worth buying in the fiction and as fun toys for the players, and it isn't clear how they compete. Hallowed blasters are as implausible as electrolasers, but probably fun. Directing the previous blast doesn't seem better than shooting again. Hallowed ion blasters aren't distinguishable from blasters. If you want an anti-bot weapon, it should be markedly different. Hallowed stun blasters are only one of many possible nonlethal weapons. For example, why not tasers? Droid gyrojets should be of the one shot, one kill persuasion, not "scattershot" and definitely not "1800 rounds per minute": every one should be an individual lethal menace, far worse than a bullet. Droid micromissiles, being missiles, have the privilege of being shot independently: a belt-fed launcher is extremely disadvantageous. Do you have a reason to avoid the traditional arrays of launch tubes? Droid jet cannons appear to be competing with drones that get close and shoot opponents properly. Why should they be used? In general, there is an arbitrary segregation of technology between the factions (e.g. the droids have the advanced firearms that the HCSA should like) and a lack of coherence in the three factions (with different weapons sharing similar uses). I'd keep the cool designs and make them available to all for the sake of variety and verisimilitude (humans should be even better than robots at using salvaged technology).
  • Advertisement

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!