[Hack-and-slash-code] The Future of the Hack and Slash Computer Game

[BFGalbraith <bga...@kr...>]

We haven't gone public with it just yet, but our lead programmer, Seth "the 
Serpent Lord" Galbraith, has left us temporarily (on very good terms,) and 
just before he left he sent this e-mail to all of us here at Galbraith Games.  
He intended it to be forwarded to the Hack and Slash mailing lists eventually. 
I am in the process of trying to incorporate some of this information into the 
"new hack and slash computer game documentation" on the hack and slash web 
site.

Don't let any of this overwhelm you, we've been working on hack and slash a 
long time and expect that it won't be 100% perfect/complete any time soon, 
it's just a question of how much more usable can we make it (some of the 
incomplete features now make it a lot less usable than we would like.) It's 
safe to say that we should work on the Hack and Slash "Quake C" (quake C is 
the Quake engine scripting language) code before anything else, because that's 
where the Hack and Slash's biggest and easiest to fix issues are right now 
(For example "ability to select a specific class for monster_players" is a 
pretty important missing feature that would be covered "in the Quake C.")  
Anyhow, here it goes from lips of the mighty Serpent Lord (sgalbrai) himself:

______________________________________________________________________________
_

>===== Original Message From sgalbrai <sga...@li...> 
=====
The current Hack and Slash game is a good DEMONSTRATION of what we want Hack
and Slash to be, but it isn't really complete enough to make the games we want
to make.  While the issue is still hot in our minds, I want to mention some
things I think need to be done before Hack and Slash is really complete enough
for the kind of general use we want, and some features that may not be as
important but could make Hack and Slash more valuable:

The following information can be forwarded freely, for example, you could use
it in an e-mail to the Hack and Slash mailing list (or Hack and Slash coding).

Perhaps the most important thing to do with this information is put it in the
Hack and Slash text files (todo, bugs, whatever they are called, make a new
text file if one doesn't exist.) then add and commit it to CVS.

Of course you should also look at the hack and slash code team documentation
for features which have not been implemented.  You might combine this with
other bug, todo and wish lists including the code team docs and the docs
distributed with Hack and Slash.

The system needs to be documented to be useful:

 * playing the game, starting and joining games, settings, etc.
 * editing the game, code, maps, models, gfx, sounds, music, etc.
 * creating classes of characters, and weapon classes
 * using other Hack and Slash entities

The weapon system is incomplete:

 * Missiles don't always disappear or explode when they should
 * Sometimes missiles explode when they should not
 * You can't collect multiple weapons and switch between them
 * Bots may need extra rules to switch between weapons
 * You can't specify weapons players or bots should start with
 * Weapons aren't carried over when you change levels
   (Use bit flags allowing up to 24 weapons per class?)
 * Missile weapon play control is not implemented as in the design
 * Missile attacks should not use hit points like hand to hand
   (see player.qc, player_attack)
 * Check whether weapons are automatically aimed up and down
 * Missile weapons should have a homing option
   (use for RPG-ish games, disable for more arcade-ish games?)
 * Missile weapons might have an option to disable to-hit rolls
   (especially for stuff like explosions?)

The role-playing system is not yet properly implemented or up to date

 * many rules implemented in the QC are outdated (armor for example)
 * many important rules are not implemented, such as size
 * when a character's class changes, it should affect their stats
   (call an rps_ function that copies stats from the class entity)
 * a character should have extra stats in addition to class defaults
   (changing levels should not make you revert to class defaults,
   so maybe the difference between your stats and the default are
   calculated before changing classes instead of being set to 0)
 * effort should be made to make the role-playing system more modular
   calling "neutral" functions like rps_isDead (self) instead of
   accessing "system-specific" feilds like self.rps_lastingDamage
   so in theory only rps.qc knows HOW damage and death is calculated

The HP used by each attack should be part of the class entity:

 * HP can be used to damage, manipulate, maneuver or recover
 * So, each attack should have a damage and manipulate value
 * animation_jab_damage, animation_kick_damage, animation_push_damage
 * animation_jab_manipulate, animation_kick_manipulate, etc.
 * OR you might combine them into a single .vector value
 * animation_jab_hp or animation_jab_hitPoints or something
 * The vector '1 2 0' might represent 1 damage, 2 manipulation
 * I don't know what the third number might be used for (kick?)

Monsters and other NPCs should become classes of monster_player:

 * ability to select a specific class for monster_players
 * have character classes which can't be selected randomly
 * class/weapon options for all abilities that monsters may have
   (flight, swimming, spread attacks, jump attacks, explode)
   these could also make for more interesting PC classes too
 * specify movement speeds in the class to fit monster animation
 * create variations of "monster_player" spawn function
   ("npc", "monster" functions can call "monster_player()")
 * freindly NPCs, NPC teams, non-combatants, guards, etc.
 * non-combat abilities - conversation, trade, trigger events

Cameras need some work:

 * Client-side cameras should be used when available
 * I'm not sure we need "hint" cameras, maybe they should work
   just like "revert" cameras, and both should be classified as
   "moving" as opposed to "fixed" cameras
 * "spawnflags" are a confusing way to specify options perhaps it
   (and other confusing options like "health") should be replaced
   with more human readable options like "camera_type" ("moving"
   or "fixed" perhaps) and "camera_distance" (a number)
 * Camera triggers should support more camera options such as
   fixed, moving, over-shoulder, auto-rotating (zelda 64-style),
   fixed auto-rotating (like zelda 64 market)
 * First person play should be an option, and may already be so
   but it probably works best if camera is manually controlled
   until you target an enemy, then your camera locks onto them

The Hack and Slash levels need some work:

 * gym_01: faster attack animation, add animation_rise_frames
 * oq_hands: disable trigger near single player start in deathmatch
 * valley: add monsters then run "QBSP - Only Entities"
 * IKLITE emulation in OpenQuartz light.exe is not bright enough
   Fixing OQ light is doubly important because IKLITE no longer
   runs from QuArK (though this could be called a bug in QuArK)
 * wyvern too dark because of this problem with OQ light
 * 3streams: big black blotches, whether IK or OQ light is used
   (could it be a problem with the QBSP programs? QuArK texturing?
   if so, perhaps using an older QBSP will have different results?)

The QuakeForge engine needs some work:

 * The menu system has not been totally re-implemented
 * Client side QC should allow us to design a new status bar
 * We need a system for installing the game and engine in Linux
 * Input doesn't work in QF dedicated servers (Windows only?)
 * Joystick control does not seem to work in Windows
 * 24 bit texture support (32 bit without alpha)
 * 24/32 bit textures on players (option to disable team colors?)
 * 24/32 bit textures on water and other textures still only 8 bit
 * Alternate water warp effects like scrolling instead of oozing
 * Allow larger playable area (compile option, per-map variable,
   or an option to compile with or without the variable?)  see
   MSG_ReadCoord, MSG_WriteCoord and similar functions in msg.c

Other things that could be done:

 * current swimming might put you a little too low in the water
 * implement climbing, climbing onto and other animation
 * scale speed of some animation to movement speeds (climbing)
 * don't get too close to characters longer than bounding box
 * make weapon classes, traps, and triggers that spawn NPCs
 * freindly characters that follow you (between levels?)
 * finish menu.qc system (develop character, select weapon, etc.)
 * implement a class selection and character development system
 * finish character save and load system (code.qc, rps_save.qc)
 * trigger_changeserver, so multiple levels can run on one machine
   (on different ports) and worlds can be spread across machines
 * random level elements (makes random mazes and stuff possible)
 * use stuff like serverflags (runes in Quake) to track major
   plot elements in multi-level story-based Hack and Slash games
   (get "rune" by triggering entity instead of touching object,
   so any trigger, including killing enemy can advance plot)
   make game different depending on which plot elements trigger
   (entities with certain flags do/don't appear depending)
 * in-game cinematic and "machinima" technology for storytelling

What the heck, this is just the tip of the iceberg.  I've tried to break down
every big idea into small features that would be fairly impressive or useful
individually, but some of those features could be divided even further into
individually impressive features.

Good luck, and I'll try to let you know if I think of anything important I've
missed.
______________________________________________________________________________

-BFGalbraith
Hack and Slash Project Manager
BFG...@pl...

Here's what's up:
www.planetquake.com/gg