Yet another client

[MrAntares]

Hi!

First of all I would like to point out, that I support any new idea and development, and I cherish that people are still willing to create amazing software for free like this. So KUDOS!

But! I have been following RO since 2007 and there is this returning trend of someone starts a client from scratch, then abaondons if after a year or so when only the GRF/MapViewer part is ready. PLEASE don't waste your resources! Don't start all over again and again. Just pick an already decent implementation and continue it! I did the same with roBrowser. It is not only multiplatform, but amazing to improve and analyze, because everything inside it is easilly accessible. I even made some improvements to make it work even better, and now it is capable of basic gameplay. So Please, for the love of god, just go there, and pick all the code you want! If you want, you can integrate everything into your client. JavaScript is a pretty easilly translatable language to other programming languages. Please don't waste your time on writing yet another graphics engine. Just take whatever you need, or fork it:
https://github.com/MrAntares/Ragna.roBrowser

[rdw-software]

As someone who has also worked on RO-related projects and similarly decided to not build directly(!) on what's already there, let me just add my thoughts on the reasons for your consideration:

• With any open source project, in using the software you opt in not only to the technology but also the management/team. This is crucial because RoBrowser doesn't have a team, nor was it ever "properly" organized, so you're basically on your own in trying to use and maintain it
• Each project has a unique vision (if they have any at all), and if yours differs substantially from that of existing projects there's little point in attempting to mold it to your needs because it would require too many drastic changes in order to be made compatible
• Technology changes at a breakneck pace, and a project that's been abandoned for years is frequently 100% legacy code/inherited technical debt, which means that writing similar functionality using modern approaches is almost certainly faster than using the existing code directly
• From a creative perspective, if your desire is to create something magnificent, then using someone else's work directly will likely not stifle those urges unless you essentially retrofit so much of it that you might as well write it yourself
• You're almost certainly exaggerating when you say "everything is easily accessible", because open source doesn't inherently mean the software can easily be understood, nor simply re-used. RoBrowser in particular is a great example, as it has virtually no documentation and making substantial changes to it is very much nontrivial (particularly if you're talking about the rendering logic)

I think RoBrowser made some good choices that can be used as inspiration for any other project with similar goals, but it's also not nearly as useful as you make it out to be here. This might explains why it hasn't really taken off, and likely never will unless an entire team were to manifest and start working on it in earnest. For the reasons mentioned above, I highly doubt this will ever happen, so why not let people try and build something they enjoy building and see if any of them can do what the others could not? That's how innovation works in any field, and I don't see how this would be any different.

That said, I do have some concerns as to whether this project really will turn out to be any different, which I've mentioned to Daniel before. For what it's worth, I at least partially agree with some of your points:

• Writing a low-level/rendering engine is an utter waste of time (unless your goal is to write one yourself), but using a custom one like the one ROB includes is almost as bad IMHO since it comes with most of the same drawbacks
• History has clearly shown that no one had the willpower or skill set needed to create (and maintain!) a workable solution, but it seems like that's mostly a matter of going about it the right way, i.e. prioritization and project management (plus obviously a lot of time and dedication)
• While I agree people could fork the existing code and reuse it for some efficiency gains, an ecosystem in which countless forks exist is, in practice, no different from one where multiple parties work on their own handmade projects

In other words, if you want to eliminate the frequent popping up of new projects pursuing a similar goal, you'd need to provide something no one has been able to: A working product and an ecosystem around it that convinces others to join in over making their own version, as well as attract end users, i.e. provide enough value to early adopters to overcome their inertia, doubts, or hesitation. This will help the project reach critical mass, and from then on network effects can take over. For this to happen you need to build something that inspires confidence from both a technological as well as a community standpoint. Clearly, what RoBrowser currently offers just isn't good enough.

Are you able and willing to provide more? Or perhaps you disagree with the premise that the value proposition is currently not in ROB's favor? I'd love to hear a convincing argument. The prospect of saving some time by re-using its code is insufficient as it's only one factor, to be weighed against the many drawbacks I've attempted to outline in this post. After all, you can't force people to adopt it; they genuinely need to feel it's worth it and at this time no one seems to feel that way about any of the existing projects.

[MrAntares]

Thank you for your response! I agree with many things you say. I don't want to promote any single solution. I just want to be efficient. And seeing the history of custom clients I thought I add my own input. When I was on the rA dev team I even proposed of supporting one single custom client as "officially supported" and making a team around it, but noone was interested. My main goal was to get rid of the stupid hacked client which got me so fedup that I haven't updated my server's client since 2012, and instead I started working on improving roBrowser, which at the time was far ahead of everything else and it had superb error tolerance. I support your cause if you think you can achieve a good reliable and easy to maintain product. I just hate to see all the talent and workpower that got lost over the years on the dozen custom client projects. I sincerely hope this will be the one! :)

What I really like in roBrowser is that it is completely independent of everything. You don't need any client files, you don't need a PC, you don't need anything, only a modern browser, and you as a server admin can even update ALL the clients at once if you update the server side client files, which is a huge bonus. This is why I opted for it and it just works perfectly for me. The only thing that is holding it back is all the hardcoded effects and interfaces that are burnt into the original RO Client. But this is the same problem for every other client project. If someone could make an asset pack containing all of these, then it could save a huge amount of hassle maintaining it or even using it in other projects. The other huge problem is the difference between client files and server mechanincs. There are times when the mechanincs of a skill is completely different from what the description actually says in the client files. This is yet another reason why the server should be much more closely bundled with an "official custom client". I hope I can raise some awareness to these problems, because these things cold have been solved at least 10 years ago.

Again, I don't want to take away anyone's mood from developing something, in fact I support it, I just would like to finally see something achieve something and these ages old problems finally getting solved :)

[rdw-software]

Ah, yes, but efficient in what manner? If using an existing client to integrate as-is with athena or Hercules is the goal I'm sure RoBrowser would be a decent enough solution. If your goal is more ambitious you'll quickly run into its limitations, however.

The history of custom clients is one of hobbyists scratching their creative itches. There's nothing wrong with that, it just doesn't lend itself to creating a standard solution anyone can rely on because it's decidedly not goal-oriented. It's the same with any of the other implementations that are still semi-active today and it can't be easily "fixed" (since it's not a problem for the authors).

The server ecosystem is based on some hobbyists doing creative work and usually individual server owners following their own agenda. From it you won't be able to recruit a development team for a single client project until that project is essentially the de-facto standard (or at least not far removed from possibly becoming it) in terms of functionality and compatibility. But you probably already noticed that yourself :)

As far as this project is concerned, I'm not affiliated with it, just giving my opinion as a casual observer of RO-related projects here. Daniel has mentioned he had loftier goals in mind for this, though that's merely a necessary requirement and not on its own sufficient.

Regarding RoBrowser's features:

• It's still reliant on the exact same data that the original client uses. Streaming GRF files may hide this from the user, but that's almost an implementation detail and comparable to the patch system most people are used to. It's nice-to-have but not something I'd consider a major selling point. Definitely not something that will make developers(!) care about and want to work on it, either
• Cross-platform/browser support is basically free when using modern technology, and I think any project made in recent years runs on all major platforms already
• File types can easily be abstracted, but the biggest challenge is keeping up with changes and researching technical details. That is to say, it's an unrelated problem that needs to be worked on by the community, which is the main reason why I created my RagnarokFileFormats repository, independent of any one client project and for everyone's benefit
• Hardcoded effects are similarly a community problem. I currently don't have a good solution to this as I haven't worked with effects very much, but I'd assume a streamlined framework or standardized format could be devised and maintained in the same vein
• In order to keep skill descriptions in sync with server mechanics, there would have to be a shared format and tools to maintain it, with support for it added to all standard client and server implementations. Blizzard's WDB approach might provide some inspiration, but ultimately it's a problem easily solved on a technical level. On a community level, open standards would have to be agreed on, but no one agrees on anything in the RO ecosystem because (understandably) everyone has their own goals in mind 😩

I think all this further supports my point in that it's a question of goals/prioritization/project management (to succeed in creating a viable alternative). The community itself won't be enticed to settle on any standard until such a client is built and working well enough to provide value to anyone who adopts it in earnest. This goes for players as well as server owners and developers.

[drgomesp]

@MrAntares thanks for your question, I really, really appreciate it and also thanks for your interest in this project.

I honestly have nothing more to add and I fell like what @Duckwhale has already expressed mostly aligns with what I believe too.

In terms of this project, my idea is plain and simple: provide a modern, accessible and robust set of technologies around Ragnarok Online which could be used together to form all kinds of new game experiences - or even emulating old RO from 2006. The client is just a part of that project and I honestly don't even think that it's comparable to RoBrowser - IMO RoBrowser has design flaws, it's components have a lot of hard-coded logic and are super hard to reuse, there is no clear separation between engine code and game code, and so on.

In regards to the maintenance of the project and everything related to it, well, it's just another open-source project which has people behind it with private lives to live and other stuff to take care of. That means collaboration is required in order for it to take off. I never really envisioned myself finishing such ambitious thing alone anyway.

Hopefully that clears at least some of the clouds.

[Danil0v3s]

I personally don't see much of a downside of having yet another client. I personally wouldn't work on a Go, F or Js project.

I don't have much to add to what have been already said but I do believe everyone has their own vision of what a ideal project would look like and that's why I believe multiple clients aren't a bad thing, I think the problem is with the community itself... The content creators are scarce and when they have a project they're afraid of sharing and opening because of how the community has grown over the years. You can see what I'm talking about just by looking at the rA and Hercules Discord/Forums.