Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 25 Nov 2005
Offline Last Active Today, 12:52 AM

Posts I've Made

In Topic: Apocalypse/ Collapse of Civilization

23 August 2016 - 01:58 AM

A survival RPG in which the player character's well-being depends on inventory and friendship with AI agents imposes a lot of disagreeable constraints on the "apocalypse":

  • The disaster must be fairly advanced, with the game set when society is already collapsed, after the interesting slow initial period in which people attempt to prepare and adapt with increasingly desperate measures (not catching the plague, escaping the enemy, containing the zombies, avoiding the war, etc.) but are not forced into a survival adventure.
    Things can go from bad to worse (for example, you might be reduced to hunt rabbits for food until you begin finding disgusting mutant ones) but not really from good to bad.
  • Most natural catastrophes aren't bad enough. A game about finding food, water and shelter for many days until rescue ships reach a tsunami-blasted island or until the first helicopters are able to fly into a burning city would be emotionally weak. A true collapse of civilization requires a global problem and a relatively long time to cook.
  • If civilization is over, shouldn't NPCs be hostile and self-interested? Can a friend be more useful than a slave?

In Topic: There's Too Much Space In Space (Cover/strategic Depth In Turn-Based 4X S...

05 August 2016 - 10:49 AM

Actually I would love to do a simultaneous movement system like it was used in Frozen Synapse for example, both for it's tactical possibilities and entertaining replays. ;)

The point of my suggestion (and others) is eliminating tactical movement in a boring "arena" of empty space and focusing instead on strategic movement around interesting and important places. Using large enough battlefields that contain interesting features is a valid but completely different approach.


There are many possibilities; for example, a technological setup that leads to building carefully designed fortresses and not fighting anywhere else could be

  • All ships have an instantaneous jump drive, cheap enough for private vehicles, escape pods, drones and missiles, etc. fast to use (a few seconds between jumps), and long range (at least a whole galaxy). 
  • The jump drive cannot be used around reasonably affordable emitters of special forcefields, that can cover whole planets with a handful of devices.
  • Planets, mining operations, space stations, spaceships themselves, sometimes even stars are protected against invasions by jump drive using this technology. Any attacker has to jump at a significant distance from their objective and use good old thrusters.to charge in. 
  • Everything of importance is surrounded by fixed fortifications.(including flying defense fleets). Keeping fleets in reserve to jump into the battlefield when an attack begins is usually too slow to be an effective strategy.
  • Ships can easily escape from battle by jumping to random places or back home. Very good defense systems are needed to turn hit and run assaults into hit, get hit and run.
  • Strategy would consist of keeping on top of the arms race, not leaving weak spots in fortresses, exploiting weaknesses in enemy fortresses, and choosing what deserves to be attacked or defended.

In Topic: Virtual Machines

03 August 2016 - 12:55 AM

Replace your computer and make the world a better place by destroying an Intel integrated graphics adapter. You deserve more than fighting with Intel OpenGL drivers.

In Topic: There's Too Much Space In Space (Cover/strategic Depth In Turn-Based 4X S...

02 August 2016 - 01:43 AM

While squad games like XCOM have a whole range of level architecture at their disposal to create choke points and personal cover, space combat seems a bit like group jousting to me - two parties line up at their respective side of the map and charge upon each other until one of them gets in shooting range.
This contains an assumption: that there are parties and that they have a chance to "line up" before a deliberate assault. Many other types of military interaction are possible, and with the appropriate choices of technology, and game scale and rules they can be prevalent. For example:


Fleets detect other fleets at very long range, well before weapons can be used. All you know of the enemy is a number of blips on the map, who knows where they are now. When fleets come into weapon range, shooting everything as efficiently as possible or sneaking away with stealth technology are the only reasonable options, and the latter can be impossible if unwanted; no need for tactical battle management.

Large forces try to surround small ones, small forces try to guess holes in the enemy battle lines, many campaigns have the purpose of merely steering the enemy away from where they want to go. In a typical turn-based 4X the usual kinds of locations would provide a sufficiently dense environment of objectives and obstacles (e.g. how could the enemy reach a certain planet before my forces?), strategic-scale fleet positioning is decisive, a simultaneous movement system is probably more intuitive.

In Topic: Xml Dialog Tree For C++

30 July 2016 - 03:13 AM

My main issue I am having right now is figuring out how to do tree traversal stuff with my XML, eg. nextDialogue='2' should send me to <dialog id='2'>


any ideas on this?

"Tree traversal" related to the XML document structure when you need to follow dialogue links? Don't do it! Before you use your dialogue graph you should have left behind its artificially tree-structured XML representation, which is just an utilitarian file format that has no place beyond asset loading.

As a reasonably simple data structure for a read-only dialogue graph I'd suggest a std::vector of fairly complex Dialog objects corresponding to the "dialog" elements ("Exchange" would be a better name), that refer to their successors using indices into the vector; it would be easy to load from the XML files because the numbers in the "nextDialogue" attributes could be used immediately, without converting them to pointers in a separate pass.