transcendence modding assumptions

[Betelgeuse]

All programs have assumptions. They are needed to simplify and/or speed up the code. So what kinds of assumptions go into transcendence code?

Of course George would know most if not all but if anyone else knows some please share.

A couple off the top of my head are.

UNIDs need to be stable.
When script is running no other script will be running. (not even transcendence code itself I think)

one questionable one

The topology of the game is set when the player starts the game and needs to be stable.

[george moromisato]

Excellent topic. I doubt that I'll be able to come up with a complete set of assumptions (many are hidden assumptions that I made in the code that I've forgotten about). But having this discussion will really help to uncover them and to figure out which are hard assumptions (impossible to change without a re-write/re-design) and which can be loosened with some additional code.

Here are some engine assumptions off the top of my head:

1. Single-player: For now, this is a hard assumption, at least in RPG-style adventures (such as D&O). There are too many places in the code that assume a single player (e.g., all docking screen code). Some day (and that day may never come) it may be possible to write a new engine (based on the existing one) that just implements head-to-head combat (no docking, etc.) But for now we should stick with this assumption.

2. 30-frames per second: Unfortunately, there are too many places that use "ticks" (essentially frames) instead of a frame-independent unit (such as game seconds).

3. Single-threaded scripts: As Betel said, this is a hard assumption (which certainly simplifies script development). However, this does NOT prevent nested scripts or re-entrancy. For example, inside a script you may call a system function (e.g., objDestroy) which ends up calling another script (<OnDestroy>). Thus you should still avoid using global variables unless you are careful of how they are used (i.e., you know that the globals are not used in any script that might re-enter).

4: Stable Topology: The one hard assumption is that topology nodes cannot be deleted in the middle of a game. However, I believe it should be possible to add new nodes dynamically and to change stargate connections dynamically [though I'm not 100% sure.]

And just for completeness, here are some assumptions that are "soft". I.e., they are true today but are likely to change in the future:

5. A player exists: Right now, all adventures require a player ship, but in the future I want to support RTS-style games in which there is no player ship. That means that individual types should not make assumptions about gPlayer and gPlayerShip (they may be NULL).

6. Systems are not created until the player enters: We've talked about this before. We should at least provide an adventure option to create all systems at new-game time.

7. Only one system updates at a time: This decision was made to conserve memory and CPU, but perhaps adventures can control this.

8. Fixed controls: Right now there is only one way to control the ship (thrust, turn, etc.) In the future I want to experiment with other methods, including mouse-control. Again, this will probably be selectable on a per-adventure basis.

9. Fixed mechanics: Right now, for example, there is no way to get rid of the Invoke menu (or the Communications menu). Nor is there a way to add new menus. This should change in the future.

I'd love to hear about other assumptions, including some that you want to keep (because it makes modding easier).