Cubes: Maximum higher than you would realistically want to use (although people would try anyway); perhaps 7200 is a good allowance. Ideally a size defined at level load, if that is possible, since that would effectively remove any and all barriers to level size. However, a revised rendering system would be required if not more, because with that many cubes it is still quite possible to slow a system to a crawl.
Addition of polygon-based geometry in conjunction with cubes would further enhance the engine's power, but considering the hassle of implementing it - rewriting EVERYTHING - I would say leave it out.
However, grouping of cubes into a given 'room' - a collection used for nothing but the level designer's convenience, effectively - could be helpful for things discussed later.
Matcens: Instead of a fixed list of three robots to generate, a list of perhaps 16 different -objects- of any nature, save of course players, with weighted chances to appear, or a probability list if necessary (but some restrictions have to be put in place to prevent the sum exceeding 100%). This would only be of use if the matcen was in random mode (which, nonetheless, would be the most frequently used I imagine). Also a spawn delay, if you want things to appear more or less often; and a repeat count (how many objects are spawned in a single trigger; possibly a flag for 'infinite', although in this case it is suggested to stop spawning objects if the matcen is full), plus number of times before death, etc.
Fuel centers: No changes except a recharge rate is specified.
There would optionally be repair centers with the same attributes (already exist in D2X-W32).
Walls: No changes needed, to be honest. At least I can't think of any at the moment. Except for more of them; even in 900-cube levels, it is perfectly possible to run out of walls if your level is strange enough. (People trying to copy D2 secret level 4 have probably found this out.)
Objects: Mostly similar to now, but with a possible 'fixed' flag, that means the object behaves like a mini-reactor and does not move no matter how much you shoot or ram it. This makes polymodel-based obstructions (such as collapsed structural supports) in levels possible. An increase in the maximum object count is probably not a bad idea.
Reactors: Same as now, except with a setting for reactor strength/shield count. That way, if some... um, people... among us, want to make ridiculously tough reactors for the later levels in a mission, they can do that.
Keys: Perhaps more of them would be nice. Eight keys, maybe? Most of them will hopefully not get used that often, but for the very large levels, the additional complexity would be nice. (People aren't going to like me for this, I can tell...)
Players: Eight co-op. If not sixteen. If sixteen, then the same for anarchy (normal) players.
Lights: Replace the system with a list of states, and a specified delay between each. Normally the light will cycle through the list, although you can toggle this off if you want.
And I'm saving the worst one for last.
Triggers. Redefine it as an event/action engine. The events could be as follows:
Light (of specified cube/side) blasted by player (specific/any)
Face (cube/side) hit by player (specific/any) with weapon (specific/any)
Player (specified/any) fired
Player (specified/any) crossed boundary on (cube/side)
Player (specified/any) entered room (specified) (oh, and this is where rooms come in handy)
Player (specified/any) left room
Player (specified/any) died
Player (specified/any) picked up powerup (specific/type (e.g. plasma cannon, energy boost)/any)
Player (specified/any) destroyed object (specific/type/any)
Player (specified/any) hit object (specific/type/any) with weapon (specific/any) (includes collision I guess)
Player (specified/any) shields dropped below (value)
Player (specified/any) shields increased above (value)
Player (specified/any) energy dropped below (value)
Player (specified/any) energy increased above (value)
Player (specified/any) vulcan ammo dropped below (value)
Player (specified/any) vulcan ammo increased above (value)
Player (specified/any) missile (type) count dropped below (value)
Player (specified/any) missile (type) count increased above (value)
Object (specific/type/any) died (in case some robot kills it...)
Object (specific/type/any) entered room (number)
Object (specific/type/any) exited room (number) (Boss in the wrong place? Well...
)Door (cube/side) opened
Door (cube/side) closed
Boolean variable (number) set to (true/false)
Integer variable (number) set to (value)
Probably have to have float (or really, fixed-point) variables too...
Timer (number) expired
Level start
Level end
Yeah, there's far too many. Even worse, ideally it should be any combination of the above, grouping events with Boolean AND and OR operators, and with any number of repeats of a specific event (say you want a player lined up over each of four triggers). Now, actions...
Set boolean variable (number) to (true/false)
Toggle boolean variable (number)
Set integer variable (number) to (value)
Increment integer variable (number)
Decrement integer variable (number)
Adjust integer variable (number) by (value) (note, supports negative numbers, so you can increase or decrease it)
Set timer (number) for (value) seconds
Give powerup (type, count) to player (specified/all)
Strip powerup (type, count) from player (specified/all)
Set player (specific/all) shields to (value)
Set player (specific/all) energy to (value)
Set player (specific/all) score to (value)
Increase/decrease player (specific/all) score by (value)
Send message to player (specific/all)
Set matcen (number) mode to (random/robot only/powerup only/specific object/off)
Set matcen (number) spawn count to (value)
Set matcen (number) spawn object to (id) (note, if this is not used 'specific object' behaviour is undefined; perhaps the first object in the matcen's list?)
Destroy powerup (specific/type/all) (use the all trigger sparingly folks!
)Kill object (specific/type/all)
Kill player (specific/all) (...use this VERY sparingly!)
Move object (specific) to (location)
Move player (specific) to (location)
Set object (specific/type/all) maximum velocity to (value)
Set player (specific/all) maximum velocity to (value)
Set fuel center recharge rate to (value) (which means you can turn them off also)
Set repair center recharge rate to (value)
Enable light (cube/side) cycle
Disable light (cube/side) cycle
Set light (cube/side) to (state)
Enable light cycle for all lights in room (number)
Disable light cycle for all lights in room (number)
Set all lights in room (number) to (state) (be careful with this one; they ideally need to all have the same state setup unless you really know what you're doing)
Set (cube/side) primary texture to (texture)
Set (cube/side) secondary texture to (texture)
Set (cube/side) secondary texture alignment to (0/90/180/270) (I don't like this much but it could be useful)
Replace texture (texture) with (texture) for all faces in room (number/all) (:D)
Open wall (number)
Close wall (number)
Set wall (number) to illusionary
Blast wall (number) (only works if it is blastable)
Set cloak value on wall (number) to (value)
Open door (number) for (value) seconds
Close door (number)
Lock door (number)
Unlock door (number)
Enable door (number) auto
Disable door (number) auto
Exit level
(Secret) Exit level
Again, any number - or at least a reasonably significant number - of these actions could be executed simultaneously. Ideally any number or value field could be a mathematical expression possibly using a variable, but I'm not too concerned about this at the moment.
However, at that I do think I'm done... and I realise it'll be a long while before this many features are implemented, if ever - but it might still be worth putting some ideas up on the table. Even though the trigger system would require a complete rewrite of the one in place...
