Entity Placement File

Intial entity placement and server side savegames are identical. Scripted spawning at runtime needs a file format similar to DEM files. Scene geometry (as given by the map/BSP file), currently static (w/o moving entities), should be stored separately from the entity placement. A unified handling of savegame, intial spawning, DEM3 and delayed spawning/scripting would be a very elegant architecture.

Advantage:

• Fixing entity placement bugs can be done w/o changing the map, or adding custom code to the spawn process (as was done for Q2 by id).
• Providing game mode/mod specific entity placement for existing maps is straightforward.
• You could use a modified DLL and Q3 as such for the entity placement stage of level editing. Once the geometry is done, you would just walk through the map, and drop entities along the way (in a special "frozen" state). You would save the game afterwards, and your savegame would give the initial set of entities, placement and all.
• Playtesting alternatives would be easier. Randomizing placements, and delivering separate initial placings would work easily, as would recovery from a server shutdown (for ongoing stuff, RPG's need persistency).
• You would save code (same code used for spawning and save/ restore). You would also get a network transmission format for transferring server state.

Disadvantage:

None known. If the distinction between static environment and dynamic objects vanishes in Q3, this would not apply. If certain moving/changing parts of a map are not cleanly described as entities in Q3 (doors, changing lights), this would not apply. If certain animations (trains, doors, plats) are fully done client side, this does not apply.

"Editing In Game" has a real appeal to it, but requires running the game from the editor. Map designers that do not want to switch from an editor to the game and back might not like using a modified DLL for editing, which requires the map being sealed, processed, and minimally lit.

Effort:

Requires overdue rewrite of savegames, and changes of the Q3 map processing tools. The latter will be simplifications. A mechanism like this has allegedly been implemented by the "War of the CTF" mod to Quake, and has also been implemented as part of the LMCTF mod.

A (server) savegame should be a complete state dump of the world, that is, everything except the scene geometry that does not change. Now, that statedump (and the file format chosen) could also serve as "initial state" for a map.

Basically, the map file gives the static environment, non-moving details, and static lighting. A savegame delivered with the map gives the initial state: which doors open/close, where is a rotating entity, which entities are where. In beginning the game, you just use the savegame as delivered with the map, or optionally you override it with another one. On restarting a game, you use a savegame created during the previous game.

Up to a degree, DEM3, the Q3 network protocol, and Q3 savegames are all different takes on the same problem, that is, a snapshot or a sequence of snapshots of things in the virtual world that change. There is redundancy, which could be removed. DEM3 ties into in-game scripting of events, and delayed spawning. To enforce certain game events at a later time, the same file format could be used.

Alternatives:

This proposal would compete with other scripting proposals. It is also an example of something the community could do without id Software, yet it would open the engine architecture, and would work better as an official standard instead of an add-on.

Submitted 980411, revised 980420, revised 980504, comments to bk@gamers.org.