Friday, 1 February 2008

Design and tech choices

A certain column of inchoate evil asked me today what plans I had with respect to the combat, leveling and other game systems. As I waved hands and blathered, the realisation that perhaps some planning would be good slowly dawned.

Continuing my own tradition of using a blog with no readers as a brain-dumping site, here are the kernels of the design. I reckon I'll just drop things in as and when they occur to me whilst I bash out prototype code, and worry about a cohesive design when it reaches critical mass.


  • Dungeon mesh: Continuous meshes will be generated for the dungeon, regenerated to cope with changes due to mining/burrowing/destruction/construction, and possibly overlapped to provide for various transitions from one dungeon type to another (such as when the player mines into a worked stone wall). Generated meshes may be fully or semi procedural, the latter based around a palette of wall sections and some randomisation methods.

Reasoning: Previously (see screenshots in first two posts) I've used discrete quarter-tile meshes that allow any wall structure to be represented. Unfortunately this either requires hardware instancing or a large number of draw calls, and introduces visible geometric repetition. Continuous meshes are far superior for represented natural structures, more efficient to render, and generally nicer.

  • Rendering: Shader Model 2.0/3.0 equivalent using OpenGL, possibly (but unlikely) with a SM1.0 or even fixed function fallback.

Reasoning: SM2 provides more than enough power to create distinctive visuals for this style of game, but SM3 allows for hardware instancing which could be essential, as well as R2VB or VTF, which may be advantageous. As I anticipate dispatch cost from Scala via LWJGL to be higher than a normal (DX or OGL) draw call, any method of reducing the number of calls is important.

  • Height variation: Limited height variation, presumably of both tactical and aesthetic importance.

Reasoning: Fully 3D layouts are possible, but complicate LoS determination, map representation, pathfinding and all manner of other things. Simple Doomesque-2.5D maps provide scope for nice visuals and additional tactical options without much additional overhead.

Game design

  • Theme: Undecided, but probably counterTolkien fantasy. Aztec bee-lizards, or indonesian shark people, or something.
  • Flexible combat: Combat style is configurable on two levels. Balancing will be a bitch.
    • The first level uses three parameters: speed, accuracy, damage. Players can select a style by picking a point (or discretised area) on a triangle, where the barycentric coordinates of the point correspond to the weights of these parameters (which may also change with experience/usage).
    • The other level of configuration is a simple slider from 'defensive' to 'aggressive'. These apply not just to melee, but also to ranged and spell combat.
    • These layers of configuration taken together should represent some minimal, useful set of discrete stances, all of which would be used for optimal play. Using the exactly balanced default at all times should be sub optimal, but not suicidal.
  • Tactical movement: Techniques such as pressing/pushing/tripping an opponent into a tactically disadvantageous spot, forcing them into dangerous terrain or trapping them in a corner will be useful. I'm keen to exploit 'blink' type magic or acrobatic feats to grant interesting advantages - flanking with yourself, backstabbing etc.
  • Great AI: For a multitude of reasons, I prefer a small number of intelligent, tough foes to hordes of stupid, weak ones. For this reason the AI should be flexible and 'ard as nails right from the outset.
Reasoning: This will be fun and interesting to implement, and can be hobbled after the fact to make it as fun as possible. Emergent properties from good singular AI are often cool even without much group AI.
  • Upgradeable, non-permadegrading equipment with familiarity bonuses: The macuahuitl of your father that you entered the dungeon with will be the same macuahuitl you emerge victorious with. Sure, it's been blessed and inscribed by Tezcatlipoca himself along the way, annointed by the blood of a thousand worthy foes, set with precious gems and graven images of Mictlan... but it's still the same.
Reasoning: Item degradation is just annoying, so that's out. IVAN makes a good job of allowing you to upgrade your equipment by both enchanting and hardening it, as well as giving you a weapon-specific skill that generally ends up with a strong narrative feeling. You find something cool near the start of your quest, and use it 'til your untimely, hideous death (I've never finished IVAN by the way) not only because it's better than most of the new weapons you find, but also because it's yours and you have both a mechanical and emotional reason to stick with it. I like this, I want to steal it. So I shall.

  • Magic: There will be some. It will be important, because I like magic. More than that... I have nothing.
  • Feats/perks: Every N levels, there will be interesting perk or feat things to choose from. Full information will be disposed about prerequisites and effects of all such perks.
  • While I'm on the subject, an absurd amount of information should be available for those who want it, on any subject. Core mechanics will be transparent; random variables will be displayed in dice notation or as ranges (optional). A concious effort will be made that a uniform scale is used throughout, and a minimum number of mechanics. This information must be layered to prevent data being lost in noise. Fuzzy terms such as 'freqently', 'often', 'sometimes', 'usually' etc. will expand to actual numbers on demand, and map correctly.
Tech point: Effort must be expended to ensure descriptive text does not get out of synch with rule data. If Bibbly's Olefactory Exploration Finger changes to do 3d7 damage rather than 8d2, or even if it flips to causes the status effect Mild Disgust and no damage, this must be automagical (or at least hard to fsck up) as much as possible.

No comments: