Re: Hard-coded FTL Modding
Posted: Sat Apr 29, 2017 3:53 am
I can pretty much do all the assembly/reverse engeering myself, since I have heaps of experience with that. I'm also more than happy to teach people how to disassemble/reverse engineer the game if they want to help with that.
How far along is Overdrive? Writing this scriptable API for FTL would definitely take an order of magnitude less time than re-writing the entire game engine from scratch. That, and it doesn't need to be feature-complete to be useful to modders. Even with basic hooks for ships, units, weapons and events (most of which I've already partially implemented) modders would have an immensely more flexible way of interacting with the game. I totally agree though, if Overdrive is already very far along, it would make more sense to work on that.
The easiest and most useful thing for people to help me with is writing and testing wrapper classes for the game's structs in memory. Writing and testing these is reasonably simple, but somewhat time consuming. Wrapper classes need to be created to properly expose the game's structures to scripters, and to stop bad things happening when objects are accessed when they don't exist in memory.
An example of this problem is with the player ship. The player ship isn't created until you leave the hangar. This means without a runtime-checking wrapper class, if a modder tried to get the player ship health before the player ship is created, you would get a segfault, instantly crashing the game. By creating a wrapper object, you can check if a player ship currently exists before accessing the player ship pointer, and throw a nice human-readable exception that modders' scripts can handle. An example of what this looks like is the ShipWrapper and UtilityManagerWrapper classes here.
How far along is Overdrive? Writing this scriptable API for FTL would definitely take an order of magnitude less time than re-writing the entire game engine from scratch. That, and it doesn't need to be feature-complete to be useful to modders. Even with basic hooks for ships, units, weapons and events (most of which I've already partially implemented) modders would have an immensely more flexible way of interacting with the game. I totally agree though, if Overdrive is already very far along, it would make more sense to work on that.
The easiest and most useful thing for people to help me with is writing and testing wrapper classes for the game's structs in memory. Writing and testing these is reasonably simple, but somewhat time consuming. Wrapper classes need to be created to properly expose the game's structures to scripters, and to stop bad things happening when objects are accessed when they don't exist in memory.
An example of this problem is with the player ship. The player ship isn't created until you leave the hangar. This means without a runtime-checking wrapper class, if a modder tried to get the player ship health before the player ship is created, you would get a segfault, instantly crashing the game. By creating a wrapper object, you can check if a player ship currently exists before accessing the player ship pointer, and throw a nice human-readable exception that modders' scripts can handle. An example of what this looks like is the ShipWrapper and UtilityManagerWrapper classes here.