[MOD][WIP] FTL: Overdrive

[swixel]

I feel like this effort is a couple years too early. It feels... weird to start this before the devs have had a chance to even attempt a proper mod rework.

(shrug)

That said I wouldn't be surprised to see this grow into something much different than ftl.

I'm wondering why this is trying to use the base files and isn't just moving on into its own opensource game ...

[DaFranker]

I've been toying around with a few design ideas (on paper) for the past few days, with the underlying intent of starting a project somewhat similar to this (though more on the side of private project stuff that never gets finished because laziness). If there's a good place for it, I can throw around some ideas that I hope are a bit more practical than "Wouldn't it be nice if you could hack drones and shit?" (Electronic Warfare was one of the ideas I was toying with, yes, but it's also one of the least fleshed-out ideas and I'll probably regret even mentioning it here, but whatever).

I've also started looking at the code, with the mindset of making contributions aimed towards maximum modder-friendliness. I've also got a few ideas that are much more technical for this, but I'd like to run them by other coders before I start throwing diffs and code around.

That said I wouldn't be surprised to see this grow into something much different than ftl.

That does seem like the natural course of events if the project does stay alive. However, I'm compelled to think of Overdrive possibly becoming to FTL as Onlink was/is to Uplink. If you liked Uplink but have no idea what Onlink is, you're definitely missing out on lots of awesomeness.

Of course, Onlink had the tiny teeny minor little difference (and perhaps advantage, arguably?) that they had actual access to Uplink's source and were working from it as a base, while Overdrive builds up from scratch with a completely different architecture and a big new design goal.

[dalolorn]

It's not like I'm stealing the assets and trying to make a profit off a clone or something, the idea is to provide modders a means to add new content to the game (which I'm sure most people here will agree is a good thing) and to allow players to play said content. The devs don't lose out on anything, since the end user still has to have bought the game in order to use Overdrive (and the prospect of modding and lots of community added content might bring in more players so it's a win-win situation!). As I mentioned, if the devs don't like it, I will close the project.

Actually, celozzip has a point.

The end user can just as easily download the game assets from somewhere or get them from a friend without having to get the game .exe file. This effectively means that your rebuild allows easy piracy, unless it's attached to the .exe or is somehow validating it.

[icepick]

Meh. If they pirate a non-drm game, this isn't going to change anything.

[thomasfn]

It's not like I'm stealing the assets and trying to make a profit off a clone or something, the idea is to provide modders a means to add new content to the game (which I'm sure most people here will agree is a good thing) and to allow players to play said content. The devs don't lose out on anything, since the end user still has to have bought the game in order to use Overdrive (and the prospect of modding and lots of community added content might bring in more players so it's a win-win situation!). As I mentioned, if the devs don't like it, I will close the project.

Actually, celozzip has a point.

The end user can just as easily download the game assets from somewhere or get them from a friend without having to get the game .exe file. This effectively means that your rebuild allows easy piracy, unless it's attached to the .exe or is somehow validating it.

If the end user can just as easily download the assets then they can just as easily download the original game exe (which has no DRM on it). I was thinking of adding some kind of exe validation, though it wouldn't be hard to bypass (especially as it's open source). I don't think it will become a problem.

Does it count as piracy if they're using a program written by a third party rather than the game itself? It's an interesting question.

[marksteele]

That said I wouldn't be surprised to see this grow into something much different than ftl.

That does seem like the natural course of events if the project does stay alive. However, I'm compelled to think of Overdrive possibly becoming to FTL as Onlink was/is to Uplink. If you liked Uplink but have no idea what Onlink is, you're definitely missing out on lots of awesomeness.

Of course, Onlink had the tiny teeny minor little difference (and perhaps advantage, arguably?) that they had actual access to Uplink's source and were working from it as a base, while Overdrive builds up from scratch with a completely different architecture and a big new design goal.

That was my thoughts as well and its why I've supported and promoted this project from the start. To be honest I think the best thing the admins could do at this point is acquire (hire, ask them to volunteer, etc, etc) the people working on this project and them make it official or provide them with the source so they could work on it more.

(also R.I.P Onlink, you shall forever live on in the minds of wanna-be hackers everywhere)


Also as a thought on the project, have you considered adding some built-in moddability? For example something like a ship designer. Right now you have to go to a third party to use one but a built in one would be totally nifty.

[thomasfn]

Also as a thought on the project, have you considered adding some built-in moddability? For example something like a ship designer. Right now you have to go to a third party to use one but a built in one would be totally nifty.

It has crossed my mind, though such an addition is low priority until the rest of the engine is working correctly - same as multiplayer (unless someone clones and contributes, though the engine probably isn't in the right state for that yet).

[swixel]

I'm going to go ahead and ask this again ...

Why are you using Lua with C#? Wouldn't it make more sense to write an interface for the races, and then to load them from mod binary (cf. dll/so/dylib)? This way more work could be done on the core engine.

Were it in C++, or C, or a handful of other languages, I'd understand Lua for higher level work, but given how easy C# is, and the opportunity to give modders full access to the engine, it seems a little weird.

[thomasfn]

I'm going to go ahead and ask this again ...

Why are you using Lua with C#? Wouldn't it make more sense to write an interface for the races, and then to load them from mod binary (cf. dll/so/dylib)? This way more work could be done on the core engine.

Were it in C++, or C, or a handful of other languages, I'd understand Lua for higher level work, but given how easy C# is, and the opportunity to give modders full access to the engine, it seems a little weird.

I am thinking of supporting both Lua and C# libraries. The reason I don't want to go pure C# libraries is because it means people have to download and install Visual Studio (or some other IDE/compiler) rather than just type scripts in notepad. Lua is also (in my opinion) easier to learn from a "noob's" point of view than C#, as C# kinda throws you in the deep end with classes and interfaces. Obviously none of the issues I described would apply to a (semi)experienced programmer, but I want the modding API to be accessible to both programmers and the more arty kind.

We'll see - it's not set in stone yet, if it turns out I have major problems getting Lua to work on mono then I might scrap Lua later down the line.

[swixel]

I am thinking of supporting both Lua and C# libraries. The reason I don't want to go pure C# libraries is because it means people have to download and install Visual Studio (or some other IDE/compiler) rather than just type scripts in notepad. Lua is also (in my opinion) easier to learn from a "noob's" point of view than C#, as C# kinda throws you in the deep end with classes and interfaces. Obviously none of the issues I described would apply to a (semi)experienced programmer, but I want the modding API to be accessible to both programmers and the more arty kind.

The problem with using Lua at all is you lower the bar and people expect to be able to do complex things with it. If C# is the engine, then wouldn't it make more sense to spend no time on binds, but rather to load data files? Race specs could be put into XML files rather than hardcoded. Special abilities, of course, become an issue, but that's really going to be quite painful to interface between Lua and C# anyway.

We'll see - it's not set in stone yet, if it turns out I have major problems getting Lua to work on mono then I might scrap Lua later down the line.

I wouldn't have a clue if Mono will play nice out of the box with it, but a dylib or so could be thrown together in a worst case scenario anyway.