FtA game engine

[Finnik]

As you might know, FtA uses own engine, that is a fork from OpenXcom Extended repository.
Two years ago I decided to develop my own fork because the goals of my project are different from those of OXCE.
The main value for the FtA project is to provide a completely new gameplay experience within a classic game. In terms of visuals, I'm doing my best to make it seem like my game is some kind of DLC (in the modern sense) to the original game. It would be ideal if a person who hasn't played the original game couldn't tell the difference between the content of the original game and the new one. As for new features - I don't want to stifle source code changes by supporting backward compatibility for other mods.

From a modder's point of view, my engine only differs from OXCE because of the new rollset properties. Although I don't strictly adhere to the doctrine of minimizing unmodified changes compared to vanilla as OXCE developers do, when run with default settings FtA engine is compatible with all OXC/OXCE mods (as far as I know).
All incompatibilities and the most significant features are protected by mod's base property `ftaGame: true` (default false). Turning on this property opens Pandora's Box, implementing new logic and most mechanics. Some properties start working differently than in OXC/OXCE. I maintain detailed documentation on the project, you can find it on engine repository wiki https://github.com/723Studio/OpenXcom_FTA/wiki
There, I highlight every case of non-standard behavior with value `ftaGame: true`. 
Not all new mechanics are blocked by this property. Additionally, I try to regularly merge with new changes in OXCE, making edits when incompatibilities arise (each time praising Yankes's ongoing refactoring crusade, rejoicing at every change in how existing methods work). So far I've been able to implement all the new features from OXCE, but I can't 100% guarantee that this will continue in the future.
So if you for some reason would like to use my engine for your mod - I'm not against it at all, but please note - I'm developing this engine for my project only, other goals will be secondary for me. If you would like to suggest that I create a new feature, you would need to explain to me why I need this feature in FtA and not in your mod.
Also, I'm not very willing to implement general functionality. For example, I developed a mechanic for reinforcements, and then 6 months later a similar feature appeared in OXCE. Now I have to maintain two solutions at the same time, because they had fundamentally different solutions on a fundamental level, and the OXCE solution didn't work for me. The same thing happened with VIP, now I have two types of VIP in my engine, which have very similar names but work very differently...

Although only about 60-70% of what I had in mind is realized, I am proud of the progress I made over these few years (because I started to change the engine code without knowing how to program at all). I want to say a huge thanks to everyone who has supported and helped me - Yankes, SupSuper, Meridian, Warboy and Ohartenstein, as well as to the guys who are directly involved in the development - Buscher, PedroTerzero, Isotop and Drosan. You rock!

[Yankes]

Indeed, duplicated features are bit painful. OXCE have this much easier as OXC only now have bug fixes.

when merging become too big pain in ass you could revert to cherry picking only things that are compatible with your code base.
This will keep difference between engines low but reduce your work on maintaining code you do not need.
This could be archived by "merge" that throw away some code (like `merge --strategy-option ours`).

btw now we can start "fork wars" for best version OXC like doom have ZDoom, GZDoom, LZDoom, or other from https://doom.fandom.com/wiki/Category:Source_ports

[Finnik]

Indeed, duplicated features are bit painful. OXCE have this much easier as OXC only now have bug fixes.

when merging become too big pain in ass you could revert to cherry picking only things that are compatible with your code base.
This will keep difference between engines low but reduce your work on maintaining code you do not need.
This could be archived by "merge" that throw away some code (like `merge --strategy-option ours`).

I was thinking of doing so at the point when OXCE introduced vip unit mechanics. But in turn, if I will start cherrypicking, I will not be able to stop. And this will make things like Debriefing state even more painful to maintain.
For now my tactic is to suggest a feature, that I want, and that IMO can fit OXCE goals to you first, and only start working on it after rejection.

btw now we can start "fork wars" for best version OXC like doom have ZDoom, GZDoom, LZDoom, or other from https://doom.fandom.com/wiki/Category:Source_ports

I don't want to start it, I will lose for sure =) OXCE has 2 core developers, and I'm almost single. I appreciate contribution to my fork from other devs, but currently it's far from the level of collaboration you have with Meridian. Also, I'm also developing mod part at the same time, also 99% solo.

Besides, I don't see the point, as projects goals are quite opposite, both in core values and game design preferences (for example, Meridian hates RPG, while I love it both standalone and merged to xcom-like gameplay).

Though I don't doubt that you would have a lot of fun in such a war. Your dominion has not been challenged in a long time  https://openxcom.org/forum/index.php/topic,6580.msg103527.html#msg103527

[Yankes]

I was thinking of doing so at the point when OXCE introduced vip unit mechanics. But in turn, if I will start cherrypicking, I will not be able to stop. And this will make things like Debriefing state even more painful to maintain.
For now my tactic is to suggest a feature, that I want, and that IMO can fit OXCE goals to you first, and only start working on it after rejection.

Yes, this is good strategy.

I don't want to start it, I will lose for sure =) OXCE has 2 core developers, and I'm almost single. I appreciate contribution to my fork from other devs, but currently it's far from the level of collaboration you have with Meridian. Also, I'm also developing mod part at the same time, also 99% solo.

Remember when you can't win "fork war" then you can use fork to kill you opponent and win by default as other branch can't be developed further
Problem only start when police try enter your home because I doubt they let you access internet from jail :>

Besides, I don't see the point, as projects goals are quite opposite, both in core values and game design preferences (for example, Meridian hates RPG, while I love it both standalone and merged to xcom-like gameplay).

Of Course, different goals require different forks. But still we can compete in with one is "better", you can always claim your is better for RPG, instant win

Though I don't doubt that you would have a lot of fun in such a war. Your dominion has not been challenged in a long time  https://openxcom.org/forum/index.php/topic,6580.msg103527.html#msg103527

Technically OXCE+ challenged me and I lost :>
And forum post is hard to name as challenge, working fork is, and modders having option to switch engine versions.
Is possibility in far future your fork will be "main" OXC version to make big mods. I win "war" with OXC but lost to OXCE+.
Compatibility with old version is always stating bonus but starting from scratch with breaking changes could be beneficial in long run.

[Finnik]

Well, I don't think it would be popular for modders, as it is designed for a single mod =)

Even though I have some nice OXCE compatible features, and many modders, like people from IDT community are familiar to its possibilities, none (AFAIK) use it for his or her mod. I don't mind, really.

Instead, I want to fight for the players. Actually, my initial goal when I started FtA was "create da best mod ever!" 

[Solarius Scorch]

Requests to implement some FtA feature in OXCE starting in 3... 2... 1...

[Finnik]

Requests to implement some FtA feature in OXCE starting in 3... 2... 1...

pls, no =)

Out of jokes, it does hurt. If the developers of OXCE pulled the changes as they are, that would be fine. It's opensource, I can't and don't want to interfere with that.
But I know this will never happen, the guys will use cherry-pick, or just write the same thing in their own way. And that in turn will block me from merging these and other current changes from OXCE. So this will add more work for me, make it harder to maintain the code, and bring me closer to the point where I won't be able to support OXCE's new features. I know it's not the problem of OXCE and OXCE modders, but still...

[Finnik]

You might be wondering if the project is dead, I am happy to say - absolutely not!
If you follow its development in discord, you might know, that for quite a long time I was working hard on a massive change, that I call "Soldier roles". It has massive impact on geoscape gameplay, as I am removing scientists and engineers as they were in vanilla (well, technically, the original code is there, but FtA player can't access it). Instead, I developed what `Soldier` is. Now people on your base can do different things, they can be soldiers, pilots, scientists, engineers and agents. Each person can combine several roles. A lot of new stats and corresponding mechanics added, I described it in https://github.com/723Studio/OpenXcom_FTA/wiki/Soldier-roles. It's more a developer doc, rather than a player guide, but you guys still might be still interested. As always, I appreciate feedback.

[Nord]

Good day.
Any plans for Android version?

[Finnik]

Sorry, iOS/Android not planned, until someone would help me with code/testing. I don't play any mobile OXCE version, and don't have enough understanding how it works. It has some difference, and OXCE has separate branches for that. No idea what I would need to do to have FTA on it. I knwo only one thing - some very backend vohdoo coding (it is related to rendering AFAIK) has to be done and desktop and mobile branches will fuse together.

Probably, after the game would be complete I will come back to this task. My hope is that this magic would be performed in OXCE, so I will just merge it to FTA =)

[Finnik]

Eh, after much deliberation, I've come to the point where I've given up on backwards compatibility with OXCE. Before version 1.3.8, almost all exclusive features were hidden behind the `ftaGame: true` mod property. By turning it off, you could play an OXCE mod (and vanilla) and expect generally similar behavior to OXCE except for just a couple of things. However, some interesting features are available with the property turned off, as they are minimally invasive and in general could even be part of OXCE. Turning the property on opens Pandora's box, normal mods won't work without adaptation. Of course, the FtA mod itself has this property enabled.
However, supporting backwards compatibility costs a lot from an engine development perspective - some simple features become much more complicated if I need to maintain the original logic. I've never positioned my engine as a universal platform (like OXCE or BOXCE), as my priority is to develop my game. Considering that over the years of development my fork has not received any interest from the modding community (most likely - quite deservedly so), I decided to completely abandon backwards compatibility. This way, the FtA engine will work correctly with FtA mods and potencial FtA-oriented sub-mods. I don't think anyone will have a problem with this. However, if you have a different opinion - I will be as always glad to get feedback. I'm especially interested in the opinion of representatives of OXC and its forks development community and your point of view on my solution, taking into account your background.

[Yankes]

Remember to disable loading of OXCE mods (using reporting of engine types).

[Meridian]

I'm especially interested in the opinion of representatives of OXC and its forks development community and your point of view on my solution, taking into account your background.

Short answer:
- do what YOU feel is right

Longer answer:
- backwards-compatibility, development cost, review cost, maintenance cost... and some different opinions/priorities too... are all reasons why FtA is not part of OXCE
- I could talk about each point above for days, but there's no need to... you've figured it out yourself in the meantime
- OXC is a success, because it had a clear goal and followed that goal
- OXCE is a success, because it has a clear goal and follows that goal (not as crystal-clear as OXC, but we try our best)
- if I can recommend just one thing to you: define your goals and non-goals carefully and (try to) stick to them... that way you have a good chance of success; without them you have a good chance of failure
- being incompatible or even just being a fork is NOT a shame, it's normal... and also necessary if your goals require it
- PS: what would be a shame is if you were to say you are compatible even if you aren't

That said, I believe you are making the right decision and I wish you good luck in achieving your goals.

[Finnik]

Thank you so much for your kind words!
My primary goal is to make a sequel to the original game in a way I see it (not in the form of TFTD, that is basically a reskin) with fresh gameplay experience and new mechanics. At this point, I don't see any other goal or priorities.

Remember to disable loading of OXCE mods (using reporting of engine types).

Oh, yes! I also tried to make so that FtA mastermod would load by default instead of vanilla or the last active mod. But I had not figured out how to do that =(

[Meridian]

I also tried to make so that FtA mastermod would load by default instead of vanilla or the last active mod. But I had not figured out how to do that =(

Making a change here: https://github.com/723Studio/OpenXcom_FTA/blob/fta/src/Engine/Options.cpp#L563
(and maybe here?: https://github.com/723Studio/OpenXcom_FTA/blob/fta/src/Engine/Options.cpp#L903)
should be enough.