Scripting has to be done from the beginning (reducing even vanilla actions to scripts).Hyperdrive wrote:If I understand correctly, the goal of this project is to add moddability to FTL by making an open source scriptable clone of it. So a good milestone could be a program that runs quite like vanilla and can use all vanilla resources correctly. From that point we could easily add some more moddability
Trying to bolt-on an interpreter after the fact would not go well.
The SavedGame Editor is already a working demo of how resources can be read (though JAXB will not be the specific xml parser used here) and translated into a game state.
- Current demo code is still trying to passively display aspects of a hardcoded static game state.
- Then resource loading can dynamically generate some of that state
(eg, load the name list, to randomly label crew).
- Then scripting can dynamically manipulate that state.
- Then the player can interact with the GUI to trigger scripting events to manipulate that state.
- Then, hypothetically, the game state can be managed by a server and synchronized among players: doing much of the scripting itself, taking players' requests to change the state, and distributing changes to everyone (or dropping requests it doesn't like).
- The engine will be java (while trying to avoid incompatibility with the Android dialect).Hyperdrive wrote:But I haven't found if the programming language (and the scripting language if the programming language is not interpreted) has already been decided.
[...]
What do we need to start towards that milestone ?
- a programming language
- a rough delimitation of the different parts
- anything else ?
- The interpreted-at-runtime embedded-in-java scripting language has not been decided.
(Android support is the limiting factor here)
viewtopic.php?f=12&t=2866&p=48271#p48271
viewtopic.php?f=12&t=2866&p=48965#p48965
- The primary candidate for the graphics library is TWL. If it proves to be too inflexible for this project, other options may need to be explored.
- The SavedGame Editor has already broken down the game into parts, though the playable engine will organize them differently (separating multiplayer-agnostic game state, from local player's sprite states, from GUI widgets depicting the sprite states).