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.



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.


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.


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.