Why does the official client fall short?
-
As I understand it, this is mostly a consequence of devtime always being in short demand. There's only so many devs who are active for FAF, and the list of things that need fixing, maintaining, or improving grows faster than they can clear.
There are several known issues that have been marked as easy 'beginner level' problems, in case anyone with the required knowledge has the motivation to try their hand at improving the project!
See a list of beginner issues for the game here, or for the launcher here. -
Just to make it clear, Python client has no issues with replays or live replays. Not so sure about the latter one, but so far I have not experienced any real issues. So it's just a Java related problem.
-
@BullydozerNoob said in Why does the official client fall short?:
Just to make it clear, Python client has no issues with replays or live replays. Not so sure about the latter one, but so far I have not experienced any real issues. So it's just a Java related problem.
Really?! I never knew that, i guess its a must have. Can you send the link?
-
@Nuggets It's available on the FAF github. https://github.com/FAForever/client
I've tried launching 10 different live replays, including dualgaps, and every single one launched. -
@BullydozerNoob said in Why does the official client fall short?:
@Nuggets It's available on the FAF github. https://github.com/FAForever/client
I've tried launching 10 different live replays, including dualgaps, and every single one launched.After trying around a bit I actually cannot believe how smooth this client is. Havent had chat disconnect yet, I can switch between tabs without lag, the leaderboard is intergrated, replays works and best of all... mapgen generation works faster and you can generate multiple at once
Edit: and the rating graph works!
-
This post is deleted! -
This is a fair question and it deserves an official answer.
Decisions in the context of time
First of all: all decisions made are/were made under the circumstances, context and given knowledge of it's time. The best decision at that time is not necessarily the best decision under different circumstances. That doesn't make the decision wrong, only because the circumstances change over time. However it also doesn't mean that a decision is final forever. It can be reevaluated and changed any time.
Developers, developers, developers!
Tools are only as good as the people using it A project like FAF cannot commit to a technology nobody is capable or willing to work in. This is the fundamental truth of any open source project and it haunted FAF from the very early stages.
The original FAF client and server used Python. While everybody claims Python would be so easy to use, I cannot agree to that in bigger projects, and I can argue about that for hours, but this is not the right place about it.
The amount of time FAF had a dedicated Python-skilled contributor in the last decade is very small. So small in fact, that the Lobby server is unmaintained for a while now and Pull Requests have been piling up and will be probably stuck there until someone with a long-term engagement is showing up.
Nobody in the core contributor team wants to or can do work with the Python codebase today. And it was the exact same situation when we promoted the Java client to the official client. Features or bugs don't really matter, if nobody is touching the code.
You might argue, what is there even to touch, the Python client has stayed the same for years and that is where you are wrong. We had multiple fundamental changes that were necessary, in order to keep FAF maintainable or (especially looking at the DDoS situation) alive.
Some examples are:
- Moving from an unmaintained php based map/mod vault (which wasn't even in version control) to a proper REST API approach
- Moving from the odd binary patching logic sending files over raw TCP to a simple HTTP patcher (to shutdown another Python server component that was rotting along)
- Changing the replay format from ZIP to ZStd back when the server disk was running full
- Changing the OAuth login provider (due to security requirements in our backend)
- Basically all the DDoS related changes (websocket connections for lobby protocol, websocket for chat, hmac protected urls ...)
All these things work now in the Python client. But they didn't from the start. The were fixed with a certain delay.
And this is the core point: We, as the core contributor team, must be able to make necessary core changes anytime when there is an urgent need. This wasn't the case back then and it still is not today. I know multiple people who are able to patch some immediate things into the Java client if needed, in worst case I can do it myself. But I only know one persistent developer working on the Python client and he has never shown interest to become part of the core team.
And I get it. The Python client has 1 dedicated developer. He can do whatever he wants. There is only a small userbase, there is no pitchfork mob waiting if something goes wrong. There is no overhead of reviewing pull requests and helping onboarding people who vanish very fast. It is a very efficient development process. But I believe it would not scale, if you promote the Python client back to official and tell other developers to put stuff in there.
The incubator advantage
There is a very funny thing I noticed in several projects now. If you build an alternative tool, you are fast, visionary, you iterate a lot, you break a lot, and you innovate a lot. This allows creating a good project. This is startup feeling. But as soon as you roll it out to the masses and people rely on it, the effect stops. Suddenly the project becomes conservative, people don't want to break anything for your user base. You try to do more testing, but there aren't much testers. Things slow down, you are suddenly no longer a startup, you are an enterprise now...
Until someone else comes and builds an alternative tool...We try our best
The FAF client used to be much more active than it is now. I didn't expect it back then, but development has significantly slowed down indeed. We have lost many core contributors over the years and they were not filled up with new people. My general feeling is: the remaining people, myself included, are just tired and put in the least amount of work to keep FAF running.
We try to involve other clients in changes. We share upcoming changes, provide documentation. We talk to people, when they approach us. We are answering questions. We do everything we can think of help people keeping alive the Python client or building a new one. So that you or anybody else can still use it. If the Python client works better for you, that is great. Feel free to use it, we're not sabotaging it. The only thing we ask for not to bother us, if something is broken there because we made changes in our system.
Also, it's not just Python, there also was the interesting approach for C# with the Ethereal client, but it seems to have died down.
Conclusion
I would still argue that the choice to make the Java client the official one was the right choice at the time. And I think the reasons from back then are still valid today. So right now I see no reason, or not even the possibility to make a different decision. But this is a community project, and should the situation change, we might need to reconsider.
-
I know this might seem unfair to existing or previous contributors, but if there simply is no contributer wouldnt it make sense to hire someone or pay existing to invest some time? Sure there isnt huge budget, but surely some things can be temporarily reasigned?
Im all up for paid tourneys, but if this is viable wouldnt it make more sense to invest into that? -
I blogged about that too over for years ago in The complexity of the FAF infrastructure and why throwing money at it doesn't fix shit.
-
@Nuggets This would be kind of a slap to the face to those who already have or are maintaining the coding today. Lot of the time given to the FAF project especially for developers is free of charge. Something will always break even if we just hire a temporary developer. This is just one of those topics that will always be controversial.
-
@Radiance said in Why does the official client fall short?:
@Nuggets This would be kind of a slap to the face to those who already have or are maintaining the coding today. Lot of the time given to the FAF project especially for developers is free of charge. Something will always break even if we just hire a temporary developer. This is just one of those topics that will always be controversial.
I'm aware, thats why I also mentioned "pay someone existing". But that also makes others not even wanting to join if not paid and so and so on.
Sadly and ultimately this however just means we are stuck in a void
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login