Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 25 Nov 2005
Offline Last Active Today, 09:11 AM

#5257001 Translation and Position terms

Posted by LorenzoGatti on 13 October 2015 - 03:30 AM

There's a fundamental difference between positions (which might or might not include an orientation) and transformations which can be applied to a position to get another position. Transformations have a group structure (they can be composed with one another to get another transformation), in common cases even a vector space structure (e.g. typical 4*4 matrices) while positions don't have useful operations giving other positions (finding the transform which maps one to the other or finding their distance give values of other types).

Even if you represent positions and transformations in an apparently similar way (for example x,y and z coordinates for points in a 3D space and displacement along three coordinate axes for translations) pretending they are the same thing causes only confusion.

#5249136 How to avoid "stacks of doom" in 4X? (Part 2)

Posted by LorenzoGatti on 27 August 2015 - 03:32 AM

A variant of area of effect weapons: severe explosions when ships are destroyed, imposing large safety distances (which the player could ignore to intensify attacks).

In an abstract combat system, just make fleet attack strength proportional to the cubic root of the ship count or similar formulas, to make stacks of not-quite-doom less useful than splitting forces to fight multiple battles fronts.

#5247637 Turning the ship around...

Posted by LorenzoGatti on 19 August 2015 - 06:10 AM

Common sense suggests studying mechanical engineering (without overly specializing in the oil sector) or something closely related and in demand, and making games as a side project.

#5246154 Isometric combat system suggestions

Posted by LorenzoGatti on 13 August 2015 - 01:31 AM

I'm probably going to be using sprite based animation instead of 3D. I guess I going define bind-points on each frame and use those, right?

You might need different character animations for different weapon strikes, even if you draw the weapon itself separately.

For example, a wide swing from left to right might be suitable for any polearm, but not for two-handed swords (hands are necessarily much closer) or one-handed shorter weapons like swords and axes (the other hand is swinging away for balance, holding a shield, etc.).

#5245396 Neat Magic System

Posted by LorenzoGatti on 10 August 2015 - 01:59 AM

A cycle of many days means waiting many days for the right night to do things rather than going forward ASAP with one's plans. This fits well with many roleplaying game situations where the player either takes initiative or has the means to plan and respect an imposed schedule:

  • You want to attack the evil mad wizard's fortress during the 4 hours window every 1440 days in which the defensive spells turn off. You have five weeks to get there from another country at an expected average travel speed of 16 miles per day. If you travel too slowly, or if you are delayed during the raid, the world is doomed.
  • You want to seduce a fellow student at the wizards academy, where charm spells, countermeasures and counter-countermeasures are a standard part of courtship. Depending on your magical resources and what you have scouted of theirs, what's the optimal day to ask them out between now and the summer break?
  • Today we have fire spells, let's torch giant spiders in their webs. On Wednesday we'll have enough ice magic to face the firebreathing dragon.

If the schedule is out of control, the game is going to be unfair.

  • You discover you should be at the evil mad wizard's fortress tonight. No teleportation? Sorry, you've just lost the war.
  • You want to seduce a fellow student at the wizards academy. Unfortunately you'd need several months of study to learn enough love magic for a good first impression. Sorry, wrong course plan at the start of the year.
  • Today we have fire spells, the firebreathing dragon attacking us is laughing with a hint of sarcasm because he knows.

#5241477 guns, ships and space combat :)

Posted by LorenzoGatti on 20 July 2015 - 02:54 AM

I don't see any difference between "main" and "secondary" weapons: both classes are used to shoot other ships. More meaningful distinctions include:

  • Weapons that can be mounted arbitrarily vs weapons that require a special position (e.g. gigantic particle accelerators along the middle of the hull of a large and elongated ship)
  • Weapons that can be aimed autonomously (e.g. typical real-world artillery) vs weapons that require orienting the ship to aim (e.g. said particle accelerators, and launch tubes for missiles and torpedoes)
  • Dumbfire vs aimed projectiles.

What's available in these different categories and effectiveness of different attack types depend on the needs of your game. For example, the first post shows a bias towards relatively low power and not very fancy weapons (only very large guns against very weak targets are capable of serious overkill, while humble weapons that don't pose a threat to well armored targets are common), accompanied by an expectation of weapons hitting almost always (no dodging or evasion) and, as a consequence, of battles of attrition being decided by imperviousness to damage. It would be appropriate for good armor to be very heavy and bad for maneuvering, to make heavy ships pay for it, but very effective against weak weapons, and for good energy weapons to require so much energy that they can only be used sparingly, with complications like charging times, turning off engines etc.


Even within these parameters, many possible styles of space combat are possible: fleets could routinely ambush each other from good cloaking, hyperspace etc. (making weapon ranges irrelevant), with mere seconds or minutes of engagement as the weaker party frantically escapes with FTL drives or the like, or battles could last for days as fleets chase each other at nearly the same speed, just out of weapon range, or fast ships with long-range weapons could surround and grind down an enemy without fear of retribution.

#5238135 Why platform games now focus on unlimited lives?

Posted by LorenzoGatti on 03 July 2015 - 01:41 AM

The problem is not unlimited lives, but restarting from the beginning after dying (or more generally restarting from sparse checkpoints), causing the player to go through a large boring level part before reaching the place where he died and where he can try again.

Limited lives are a means to stop playing: in a coin-op game because you are supposed to pay to play (and play for a time that's strictly proportional to your skill), in a console or computer game because independent successive attempts to beat the game are more meaningful than retrying forever.  

#5237092 Roguelike game with static map

Posted by LorenzoGatti on 27 June 2015 - 08:08 AM

I should mention, the main reason I want the map to be static is because I want some sort of storyline/environment in the game, where there are different cities fighting each other and the player has the freedom to choose which cities they want to help and which cities they want to destroy, and quests will adjust according to the choices that the player has made.

My fear is that having randomly generated cities might look bad, and will break immersion.


You can mix procedural and fixed content top down or bottom up; in your case, probably both. Content should be procedural by default, with specific things you need for plot or game balance reasons imposed as an exception.


Top down, you can simply constrain procedural generation: if you can ask for a city around a certain latitude and longitude and containing a certain list or number of buildings, NPCs and other features, your cities will be different every time but sufficiently "the same" to serve the purpose of a standard storyline.


Bottom up, you can integrate something fixed and detailed in the middle of procedural content. For example, a capital can be specified to contain not only, say, 3+3d4 swordsmiths and 4+1d8 luxury inns, but also a royal family of 20 members with names, stats and important possessions specified beforehand.


Both techniques are used all the time in RL games. At the highest level, the two common level structures are a major top-down constraint: both the sparsely connected graphs of small linked dungeon and outdoor locations and the combination of interesting places and vast and boring large-scale outdoor maps containing them determine the plot of the player character's exploration.

Some games have fairly fine-grained bottom-up "islands" of fixed content: Angband has vaults, predefined dungeon sections (with variable treasure and monsters) that can replace plain random rooms, while NetHack has, for example, a suite of levels consisting of Sokoban puzzles (exactly specified and picked randomly from a list of alternatives).

#5236281 Level design of a "Roguelike" set in outer space

Posted by LorenzoGatti on 23 June 2015 - 01:38 AM

There's an obvious counterpart to the traditional RL level structure of dungeon levels linked by stairs: solar systems where you fly around and some kind of "stargate" (which can require the same kind of searching and strategic combat as dungeon stairs) allows passage to a similar stargate in another system. Already done very well, with free movement rather than a grid, in Transcendence.

#5235140 Easy source control for educational uses?

Posted by LorenzoGatti on 16 June 2015 - 10:11 AM

I don't think Subversion is going to be practical, because conflicts and locks and inconsistent states in the shared repository can lead to serious frustration and waste of time. Git would be much safer, particularly if you tell your students to do things in a certain standard way without messing with complicated commands, because at worst users can can wipe their own uncommitted working copy changes.


Everyday use of Git requires few reasonably simple commands: pull (with few or no conflicts), log, status, commit, sometimes push. In particular, if you want to deal with merging yourself, you can pull from every pupil's repository at your leisure (presumably in class, while they are working and their computers are on, connected to your LAN and serving their repositories via HTTP) and tell them to never push changes anywhere, which is a significant simplification. You also have the solid fallback solution of backing up and/or sending entire repositories.


You mention Eclipse, which has fairly nice tool support for Git; it is likely to be even nicer than command line tools.

#5234600 C# becoming obsolete ?

Posted by LorenzoGatti on 13 June 2015 - 08:40 AM

From my business programming experience, I think C# is a fairly good and stable language, but the accompanying libraries less so; it continues the established Microsoft tradition of introducing frameworks (historically database access and web programming, lately also GUI) and keeping around the old ones.

Learning generally applicable C# complications and advanced features (e.g. signed assemblies, using native code, LINQ, extension methods, annotations, DLL hell, how to use Visual Studio, etc.) would be better than falling in love with the latest novelty framework.

#5233497 Engine design, global interfaces

Posted by LorenzoGatti on 08 June 2015 - 03:16 AM

A nice advantage of passing around pointers is that you can improve encapsulation by using pointers to the right thing instead of giving excessive access to global data structures and unneeded dangerous functions. For example:

  • A piece of a scene graph, without access to its parent(s), rather than the whole world.
  • When visiting game entities in order to render them you can pass around, and append to, passive collections of things to draw (e.g. managed vertex buffers) rather than a "Graphics API interface that makes draw calls"
  • When loading resources, you might be able to use objects that represent one resource and bury in their inaccessible implementation references to global variables representing a registry of what resources are loaded or not and other delicate mechanisms like spawning threads to load resources and concurrency control.

#5226933 Equipment/modules for ships

Posted by LorenzoGatti on 03 May 2015 - 06:02 AM

Maybe like this: you research (progress) better lasers and all ships are auto upgraded with these (+1, +2, +3), same for armour, reactor, shields, scanners, basic computers.

Not so fast. Upgrading all ships can be too expensive because resources are insufficient, not the best way to spend resources (for example, the player might prefer to build more ships) and even wasteful (for example, some ship classes might already have excessive firepower). Individual ships or fleets might also have a higher priority (closer to going into battle, outclassed by enemy fleets, etc.)
Asking the player what ships should be upgraded seems a good idea.


Assuming upgrades are desired, being able to perform them isn't trivial: some might be within the means of on-board workshops and maintenance crews (which only large enough ships would have), some would require transport from distant factories and/or dismantling major ship systems in a dry dock, causing a lot of travel. What sort of upgrade logistics complications could be fun?

#5224495 Equipment/modules for ships

Posted by LorenzoGatti on 20 April 2015 - 08:42 AM

If your "hulls" are a combination of useful payload space, engines and main weapons, they are still a bit complex, and having 20 or more is not surprising. Maybe some more differences could become upgrades and optional systems rather than intrinsic hull features; upgrades drastically reduce hull obsolescence.

On the other hand, multiple "designs" (e.g. low-performance inexpensive cruiser for blockades and incredibly well armed fast cruiser for planetary assault) would share the same hull.


Example: Star Trek Federation large ships, with their traditional saucer and warp nacelles design.

Constitution class (the TOS Enterprise) and the much newer Intrepid class (the Voyager) are about the same size and shape and they could therefore be the same "hull", even if the latter has more advanced engines, weapons, computers and everything else. Different hull shapes and arrangements are likely to be insignificant, and other classes of similar size and role, like those that are similar to the Enterprise with 1, 3 or 4 warp nacelles, are presumably similar enough too.

On  the other hand the Galaxy class (the main TNG Enterprise) is about twice as large, enough to be treated as a different hull with more cargo capacity.

Important Star Trek ships tend to be destroyed or fade into oblivion, but rebuilding would allow them to be updated to new technology; typical Star trek rebuilds would include experimental weapons, faster warp drives, fancy computers, better sensors.

#5223904 Is C++ RTTI good or bad?

Posted by LorenzoGatti on 17 April 2015 - 03:37 AM

The sort of situation where I would use dynamic_cast is where I'm using abstract classes for portability. For example I might have an abstract class called Image and a GlContext class with a pure virtual method uploadImage(Image *), and subclasses with implementations for SDL2 and Android (not using SDL2 for Android is another story). In the Android build all Image objects would be DroidImage and GlContext would always be AndroidGlContext. The implementation of uploadImage needs access to members of AndroidImage which aren't available in the abstract base, so it has to cast.
You don't need casting, because you don't actually need access to AndroidImage internals: you need a more complete separation between the generic and Android-specific parts of your code. Only Android-specific classes should be allowed to have variables with Android-specific types, while generic code like an uploadImage() function should be restricted to using Image, GIContext, etc. You probably need to add something to the abstract interfaces like Image.

I've implemented it in a base class Connectable, with derived classes Room and Region. The vectors of neighbours are of type std::vector. However, both Room and Region also need to do other Room-specific and Region-specific things with their neighbours, and it's better to reuse the vectors available in the base class and cast the members from Connectable to Rom or Region as appropriate than to maintain separate vectors of the subclass.

This is just a bad design; a Connectable interface doesn't make sense, because you are always connecting regions, which are aggregates of rooms, and some regions are allowed more than one outgoing door.