Once again, I am making the call out for volunteers who wish to become potential scripters on this project. I prefer to recruit dedicated volunteers from a familiar setting who have an affinity for FTL rather than randoms from r/INAT from reddit who are generally more interested in game development as a whole and may jump off to pursue their own game development projects once they've accumulated enough experience.
I am lowering the general requirements. You only need drive and aptitude. Drive comes from the person. Aptitude is innate. Those can't be easily trained. Skill can be trained given those two attributes and time, and I have plenty of time.
If you feel like you have free time, could become an asset to the project, and have an interest in learning coding/game development, post here and contact me.
A drive for Overdrive
-
John Luke Pack Hard
- Posts: 112
- Joined: Thu Nov 15, 2012 8:45 am
-
John Luke Pack Hard
- Posts: 112
- Joined: Thu Nov 15, 2012 8:45 am
Re: A drive for Overdrive
STATUS UPDATE:
I got a reply from the professional artist I contacted. He's in the middle of moving so he won't be able to meet with me/start work until next week. Once he finishes though, I'll implement the full scale customization UI and finally you'll be able to easily navigate through unlimited ships and 27 layouts. I'll finalize the vocabulary so it's consistent.
FTL: ambiguous
Faster than Light: the original version
Overdrive: the reworked modability-focused version
Ships: The class of ship including all the layouts
Layout: The specific layout, meaning the floor and the weapons.
With R4V3-0N's layout buttons, my asset edits, and this professional artist's customization menu background edits, the legal status of the assets we hold enters a fuzzy zone, as some of the assets are strictly our assets, and not Subset Games's. As Lead of this project, my official policy on the use of those assets are, as long as you hold a legitimate, legally-purchased copy of Faster than Light, you may download a copy of our assets, doesn't matter from who. NOTE: This may change as I have future plans for this project that I have yet to reveal.
I got a reply from the professional artist I contacted. He's in the middle of moving so he won't be able to meet with me/start work until next week. Once he finishes though, I'll implement the full scale customization UI and finally you'll be able to easily navigate through unlimited ships and 27 layouts. I'll finalize the vocabulary so it's consistent.
FTL: ambiguous
Faster than Light: the original version
Overdrive: the reworked modability-focused version
Ships: The class of ship including all the layouts
Layout: The specific layout, meaning the floor and the weapons.
With R4V3-0N's layout buttons, my asset edits, and this professional artist's customization menu background edits, the legal status of the assets we hold enters a fuzzy zone, as some of the assets are strictly our assets, and not Subset Games's. As Lead of this project, my official policy on the use of those assets are, as long as you hold a legitimate, legally-purchased copy of Faster than Light, you may download a copy of our assets, doesn't matter from who. NOTE: This may change as I have future plans for this project that I have yet to reveal.
-
John Luke Pack Hard
- Posts: 112
- Joined: Thu Nov 15, 2012 8:45 am
Re: A drive for Overdrive
Hello all who have been following (and a big thank you to the 5 who were willing to vote in the last poll, that was meaningful to me), it's time again to poll your opinions.
I've been perusing the blueprints.xml document from base Faster than Light and reviewing the augments. The xml entries for augmentations provide very little information, namely because augmentations can have a nearly infinite range of effects and defining their effects via xml is downright impossible.
I did some quick thinking about this and did some research into advanced programming techniques. What I discovered is that there *may* be options available that will give modders capable of Java the ability to code their own augments and inject them into Overdrive. Emphasis on *may*, as what I'm imagining may not be possible. 9/10 times when treading into unknown territory there will be complications that cut your progress dead in its tracks.
At the bottom of this post is a poll. First, read the post to let me describe the paths development can take when it comes to this stage of the project and the consequences each choice will have.
1. Hardcoded. This is vanilla Faster than Light style. All the augmentation behavior is defined in the code. The flavor data is defined in the .xml file. To add more augments, modders would have to reach out and work with the developers to turn modder ideas into game reality. The upside is that this is the easiest system for me (us, if I get volunteers) to implement. The downside is that adding additional augmentations is constrained by developer approval and free time, and the externality that there will be a developer overseeing Overdrive in the future.
2. Softcoded. This is the potential system that will allow modders capable of Java to have an API to implement their own unique augmentations. What I imagine will have to happen is that I implement some open ended code that runs a top-level polymorphic (for those non-coding types, a rectangle can turn into a square, or a rhombus, get the analogy?) object and activates its methods on certain triggers. The caveat is that Java has to explicitly include packages and jar files (from what I know, I'll ask if there's a way to implement dynamic inclusion and importation). As long as this restriction exists, I or someone else may have to code a packager that packs all your augmentation mods into a single jar that gets included and run with Overdrive. The upsides are wondrous; if you have the ability, you can make it happen, essentially. The downside is comparatively massive; it's a complicated, open-ended system that I/we have to look for every possible trigger/effect point, include it into the API, and make sure it doesn't break. Essentially, even after all the work is done, we'll be performing constant tech support, adding new features and making sure earlier features don't break from the strain. Since we have to implement such a complicated system and test it before release, it will most likely delay release.
3. Hardcoded release, transition to Softcoded via updates. This option gives you the benefits of both; you get Overdrive sooner, and the ability to make your own augments later. The downside is it multiplies the work for us as we have to implement two systems.
https://www.strawpoll.me/12825071
This time, if you're following this thread, I highly encourage you to vote, as this is one of the critical points of opinion that will affect Overdrive's development and outcome.
I've been perusing the blueprints.xml document from base Faster than Light and reviewing the augments. The xml entries for augmentations provide very little information, namely because augmentations can have a nearly infinite range of effects and defining their effects via xml is downright impossible.
I did some quick thinking about this and did some research into advanced programming techniques. What I discovered is that there *may* be options available that will give modders capable of Java the ability to code their own augments and inject them into Overdrive. Emphasis on *may*, as what I'm imagining may not be possible. 9/10 times when treading into unknown territory there will be complications that cut your progress dead in its tracks.
At the bottom of this post is a poll. First, read the post to let me describe the paths development can take when it comes to this stage of the project and the consequences each choice will have.
1. Hardcoded. This is vanilla Faster than Light style. All the augmentation behavior is defined in the code. The flavor data is defined in the .xml file. To add more augments, modders would have to reach out and work with the developers to turn modder ideas into game reality. The upside is that this is the easiest system for me (us, if I get volunteers) to implement. The downside is that adding additional augmentations is constrained by developer approval and free time, and the externality that there will be a developer overseeing Overdrive in the future.
2. Softcoded. This is the potential system that will allow modders capable of Java to have an API to implement their own unique augmentations. What I imagine will have to happen is that I implement some open ended code that runs a top-level polymorphic (for those non-coding types, a rectangle can turn into a square, or a rhombus, get the analogy?) object and activates its methods on certain triggers. The caveat is that Java has to explicitly include packages and jar files (from what I know, I'll ask if there's a way to implement dynamic inclusion and importation). As long as this restriction exists, I or someone else may have to code a packager that packs all your augmentation mods into a single jar that gets included and run with Overdrive. The upsides are wondrous; if you have the ability, you can make it happen, essentially. The downside is comparatively massive; it's a complicated, open-ended system that I/we have to look for every possible trigger/effect point, include it into the API, and make sure it doesn't break. Essentially, even after all the work is done, we'll be performing constant tech support, adding new features and making sure earlier features don't break from the strain. Since we have to implement such a complicated system and test it before release, it will most likely delay release.
3. Hardcoded release, transition to Softcoded via updates. This option gives you the benefits of both; you get Overdrive sooner, and the ability to make your own augments later. The downside is it multiplies the work for us as we have to implement two systems.
https://www.strawpoll.me/12825071
This time, if you're following this thread, I highly encourage you to vote, as this is one of the critical points of opinion that will affect Overdrive's development and outcome.
-
TheFallenAngel359
- Posts: 111
- Joined: Fri Feb 13, 2015 8:22 pm
Re: A drive for Overdrive
Sorry, I ended up being pretty busy this week and was unable to get anywhere near FTL, much less the combat assets. Since you've contacted your professional artist, is there still anything I can do to help?
-
John Luke Pack Hard
- Posts: 112
- Joined: Thu Nov 15, 2012 8:45 am
Re: A drive for Overdrive
TheFallenAngel359 wrote:Sorry, I ended up being pretty busy this week and was unable to get anywhere near FTL, much less the combat assets. Since you've contacted your professional artist, is there still anything I can do to help?
Well, I still need your answer as to whether you'd be willing to take training in Java early from me and become a coder on the project. That's option 1.
EDIT: There's only 2 corrupt sound files according to the script I wrote. No need to uncorrupt ALL of them.
-
John Luke Pack Hard
- Posts: 112
- Joined: Thu Nov 15, 2012 8:45 am
Re: A drive for Overdrive
UPDATE:
I'm currently studying for a final exam. No progress will be made until the first weekday of next week, when my last final exam takes place in the morning and I meet with my professional artist later that evening.
Other than that I uncorrupted the two corrupt .ogg files in the system and implemented a system to detect corrupt sound files and auto-exit when it detects corrupt sound files and lists them in a text file when it detects corrupt sound files, as well as creating a pop-up that alerts the user that corrupt sound files were detected. I haven't tested the system with corrupt sound files though. When I get the time I'll create this user-friendly pop-up dialogue exception alert system throughout the rest of the app too.
I did that because it didn't take much time.
To FallenAngel, I'm just waiting on your answer if you'd like me to train you in Java and libgdx a little early before your summer CS program. I already uncorrupted all the sound files in the assets.
I'm currently studying for a final exam. No progress will be made until the first weekday of next week, when my last final exam takes place in the morning and I meet with my professional artist later that evening.
Other than that I uncorrupted the two corrupt .ogg files in the system and implemented a system to detect corrupt sound files and auto-exit when it detects corrupt sound files and lists them in a text file when it detects corrupt sound files, as well as creating a pop-up that alerts the user that corrupt sound files were detected. I haven't tested the system with corrupt sound files though. When I get the time I'll create this user-friendly pop-up dialogue exception alert system throughout the rest of the app too.
I did that because it didn't take much time.
To FallenAngel, I'm just waiting on your answer if you'd like me to train you in Java and libgdx a little early before your summer CS program. I already uncorrupted all the sound files in the assets.
-
John Luke Pack Hard
- Posts: 112
- Joined: Thu Nov 15, 2012 8:45 am
Re: A drive for Overdrive
So gentlemen, another opinion, and since this would be a drastic change, I'm going to implement this as an optional add-on mod (see file structure at parent post of this thread for reference) for those of you who have your preferences either way, but I want to poll your opinions anyways.
In Faster than Light, humans are described as boring and uninteresting, without any special characteristics that set them apart from the other races.
This is one way to go about describing mankind, however, most of the time in other sci-fi settings, humans are given a more brilliant, exceptionalistic characterization, setting into the stars with a grand ambition of conquering the unknown, able to brave the unforgiving challenges of space with their unique trait of adaptability.
To reflect this, in my mod I will be giving humans an XP buff of -20%, allowing them to level up 25% faster than other races, and the unique ability to level up 2 times past the normal limit. This allows them to level up 4 times total in any skill. With this ability, humans become the jack-of-all-trades race, able to develop strengths in many areas and serve many purposes, and in some cases, outperform other races in certain tasks. Still, even with this adaptability, some races, with their inherent attunement to their element, such as the Engi to engineering, or the Mantis/Rockmen to combat, will still fare better than the most skilled human in your crew.
What are your thoughts to this idea? I'd like to know.
https://www.strawpoll.me/12863611
In Faster than Light, humans are described as boring and uninteresting, without any special characteristics that set them apart from the other races.
This is one way to go about describing mankind, however, most of the time in other sci-fi settings, humans are given a more brilliant, exceptionalistic characterization, setting into the stars with a grand ambition of conquering the unknown, able to brave the unforgiving challenges of space with their unique trait of adaptability.
To reflect this, in my mod I will be giving humans an XP buff of -20%, allowing them to level up 25% faster than other races, and the unique ability to level up 2 times past the normal limit. This allows them to level up 4 times total in any skill. With this ability, humans become the jack-of-all-trades race, able to develop strengths in many areas and serve many purposes, and in some cases, outperform other races in certain tasks. Still, even with this adaptability, some races, with their inherent attunement to their element, such as the Engi to engineering, or the Mantis/Rockmen to combat, will still fare better than the most skilled human in your crew.
What are your thoughts to this idea? I'd like to know.
https://www.strawpoll.me/12863611
-
TheFallenAngel359
- Posts: 111
- Joined: Fri Feb 13, 2015 8:22 pm
Re: A drive for Overdrive
I suppose I wouldn't mind learning a little Java. After all, I could use it.
-
John Luke Pack Hard
- Posts: 112
- Joined: Thu Nov 15, 2012 8:45 am
Re: A drive for Overdrive
So gents, this was a thought, and it popped up again, so I thought now might be a good time as ever to ask you all about it.
On the topic of enemy AI in Faster than Light, all enemy ships will handle weapons the same way the artillery system on the Federation Cruiser fires; fire when ready, and fire randomly, which nerfs the challenge somewhat.
Now let me introduce the topic of state-based engines. State-based engines are an abstract machine, in computer-science terms and will run a constant procedure based on that state. Using a state-based machine, I can simulate an enemy captain and a certain tactic: aggressive, attempting to lock down your weapons and render you into helpless prey, or defensive, attempting to keep the shields up and flee.
In addition, it wouldn't be too hard to analyze given weapons and theorize a "best possible firing solution", which isn't too different from what we players use, i.e. missile the shields, then laser the priority system, or missile the shield system, laser the last layer down, then beam the priority system.
This time there are two polls, as there are multiple facets to this development aspect:
https://www.strawpoll.me/12869288
https://www.strawpoll.me/12869363
On the topic of enemy AI in Faster than Light, all enemy ships will handle weapons the same way the artillery system on the Federation Cruiser fires; fire when ready, and fire randomly, which nerfs the challenge somewhat.
Now let me introduce the topic of state-based engines. State-based engines are an abstract machine, in computer-science terms and will run a constant procedure based on that state. Using a state-based machine, I can simulate an enemy captain and a certain tactic: aggressive, attempting to lock down your weapons and render you into helpless prey, or defensive, attempting to keep the shields up and flee.
In addition, it wouldn't be too hard to analyze given weapons and theorize a "best possible firing solution", which isn't too different from what we players use, i.e. missile the shields, then laser the priority system, or missile the shield system, laser the last layer down, then beam the priority system.
This time there are two polls, as there are multiple facets to this development aspect:
https://www.strawpoll.me/12869288
https://www.strawpoll.me/12869363
-
John Luke Pack Hard
- Posts: 112
- Joined: Thu Nov 15, 2012 8:45 am
Re: A drive for Overdrive
UPDATE: I just finished fully implementing the ship select screen in the Ship Customization Screen, but I haven't tested it with more than 12 ships. I would like someone to step forward and try testing it by downloading the latest version (go to the links in the parent post) and adding 3 ship archetypes to the list and seeing if the system still works. F12 should take a screenshot and upload it to the new screenshots folder in the assets folder. Please upload the screenshot to Imgur and post a link to the screenshot to this thread.
A screenshot of the implemented ship select screen
Also, for the AI distribution, it seems to be shaping up that advanced AI should become a mod in the new Overdrive, I will allow AI distribution to be adjustable via XML settings in the mod.
As of now I am working fervishly. If you have been following both this thread and the thread "Hard-coded FTL Modding", something of a competition has formented between Overdrive and the Assembly mod taking place there. The timeline to release is a month, expect a product then.
A screenshot of the implemented ship select screen
Also, for the AI distribution, it seems to be shaping up that advanced AI should become a mod in the new Overdrive, I will allow AI distribution to be adjustable via XML settings in the mod.
As of now I am working fervishly. If you have been following both this thread and the thread "Hard-coded FTL Modding", something of a competition has formented between Overdrive and the Assembly mod taking place there. The timeline to release is a month, expect a product then.