Emissary Programming Technical Design Guide
November 11, 1996
Michael White
Cyberlore Studios



Emissary uses Unreal as its underlying engine.  The majority of
programming tasks involve modifications and additions to this existing code
base.


I. USER INTERFACE

	A. Console view modification

	Requires:
		1. Each vehicle has a different console graphic.

		2. Visual display for shield strength, energy, etc.,
		which may be located in different places and look different on
		different ships.

		3. Weapon display varies by vehicle.

	Current situation:
		The file "uncon.cpp" contains hardwired screen coordinates and
		such for the existing console graphics.

	Plan:
		1. Create a "vehicle" class which fits into the Unreal class
		system by deriving from "AActor", the existing actor class.

		2. Create a method for the vehicle class which reads a
		resource (during system initialization) for each vehicle
		describing the layout of its console.

		3. Modify the file "uncon.cpp" to use the new system.


	B. Console view additions

	Requires:
		Radar view.

	Current situation:
		No radar code exists.

	Plan:
		1. Study code in AActor class gives access to all actor
		positions.

		2. Create system that handles this and all radar properties
		and functions.

		3. Use color gradient to differentiate relative z-values.

		3. Modify the file "uncon.cpp" to show the radar screen.


	C. New menu/non-game interface


		(??? Flow chart of high-level)

		Much of what is normally done through generic menuing (a la
		Duke, Quake), will be accessed through the data log.


	D. Data log

	Requires:
		1. Regular user interface things (save game, options).

		2. Graphics/text descriptions from the HAL.

		3. Log of chat/system messages.

		4. Ship status info.

		5. Multiplayer: Network info.

	Current situation:
		None.  Data log is new.

	Plan:
		1. Modify existing Cyberlore code which handles graphics and
		widgets to work within the Unreal engine.  This will also
		serve as the basis of the file and memory structures used for
		data log entries.

		2. Create a "logentry" class to encompass all types of log
		entries.


	E. Automap???

		This will likely be dropped unless time permits, in which
		case a plan of attack will be decided.


II. GAME MECHANICS

	A. Each drone is a different size and has different capabilities, such
	as weapons available, maximum stair climbing height.

	Requires:
		1. Adjustment of various parameters for each drone.

		2. Tests to make sure various sizes do not cause collision
		problems, i.e. getting stuck. (Unreal currently seems to
		have trouble with close vertices.)

	Current situation:
		Many of the properties of drones are directly handled by the
		existing Unreal framework.  Problems with varying player sizes
		may arise with particularly large or small drones.

	Plan:
		1. Using "vehicle" class, described above, add any
		additional properties required that are not already there.
		Modify physics code to handle any differences this will make.

		2. Test various size vehicles in different types of worlds.


	B. Drone-to-Drone transfer.

	Requires:
		1. Each player is always hosted by a vehicle.

		2. Define new weapon class, "transfer", for sending player
		into a new vehicle.

		3. When transfer occurs, player is connected to new vehicle
		with all non-vehicle attributes unchanged.

	Current situation:
		Unreal has mechanisms for switching bodies (posession).
		However, the weapon-shot transfer is new.

	Plan:
		1. Use "vehicle" class, described above.

		2. When an empty vehicle is hit by "transfer" ammo, the
		player who shot that ammo player is hosted by the new vehicle.
		Player gets all the vehicle's attributes.


	C. Weapons.

	Requires:
		Modification of existing weapon system.

	Current Situation:
		Most weapon code is in "UnWeapon.cpp".  This contains all code
		specific to weapon types and their behavior.

	Plan:
		Modify "UnWeapon.cpp" so that it contains only Emissary
		weapons and projectiles, and no Unreal weapons.


	D. Power-Ups.

	Requires:
		Modification of existing power-up system.

	Current Situation:
		A power-up is a simple pawn-based class.

	Plan:
		1. Like with weapons, take out unreal-specific power ups and
		add our own.

		2. Some weapon code modification may be needed fo such
		power-ups as rapid-fire.


	E. New Monster and Drone AI.

	Requires:
		1. Realistic enemy behavior.

		2. Keypoint path-following enemies.

	Current situation:
		Waiting on Unreal AI scripting implementation to be finished.
		We know basically what the scripting language looks like, and
		sample AI code will be available.

	Plan:
		1. Determine specific needs of designers.

		2. Study sample AI scripts when available.

		3. Possible modification of AActor-derived classes.


	F. Special mechanical effects.



III. SOUND

	Requires:
		A. Music added.
		B. Voice added.
		C. SFX added.

	Current Situation:
		All of these are supported by Unreal.

	Plan:
		1. Put new sound files in place and test.

		2. Some code modification may be necessary to play HAL's
		sounds.


IV. SPECIAL VISUAL EFFECTS

	Requires:
		(Postrendering effects)
		1. TV Noise interference.
		2. V-Hold glitch.
		3. Cracked glass.
		4. Water pouring down viewscreen.

		(Rendering system mods)
		5. Infrared.
		6. Black and white.

		(Actor/Camera system mods)
		7. Damaged vehicle wobble.
		8. Earthquake shake.

	Current situation:
		These visual affects don't exist yet in Unreal.

	Plan:
		(Postrending effects)
		Create a new class "postrender_effect" which contains
		all postrendering code.  Insert calls to these postrendering
		effects into "UnCon.cpp" which has postrendering hooks.

		(Rendering system mods)
		Modify scan-conversion code to change colors of output
		pixels.  For instance, in B+W, all pixels' color intensities
		are extracted and set to no-hue (greyscale).

		(Actor/Camera system mods)
		Modify actor code to check damage level.  When in certain
		damage ranges, offset camera rotation/yaw by small random
		amounts.


V. MULTIPLAYER PLAY

	A. Run emissary as multiplayer game.

	Requires:
		Network capabilities.

	Current situation:
		Unreal engine will have networking already.

	Plan:
		Due to changes we make in other parts of the game, the
		high-level networking code may require some modification,
		especially where vehicle use is concerned.


	B. Add additional multiplayer modes.

	Requires:
		Capture the flag.
		Rugby.

	Current situation:
		Networking is incomplete, so it is hard to tell what
		multiplayer modes are planned.

	Plan:
		These are a fairly low priority.  As time permits, I'll look
		at the high-level network code to see where modifications
		would be made.  Unfortunately, no high-level network code
		exists yet.


VI. MISCELLANEOUS

	A. Install program.

	Requires:
		Custom or off-the-shelf installer system.

	Current Situation:
		N/A

	Plan:
		Use <???> installer.


	B. Compile demo.

	Requires:
		Playable but cut-down version of game.

	Current Situation:
		N/A

	Plan:
		1. Test <???> levels of game for robustness.

		2. After levels are complete, put up graphic advertisement for
		full version.

		3. Add system messages that remind player to purchase
		full version when attempting to use features that are
		unavailable in demo.

		4. Set up installer to install demo.
