[suggestion] Merge mkxp/mkxp-z in

[pirate486743186]

To understand this suggestion, you need to take a few steps back, and see the big picture.

I'm suggesting you do a scummvm type of strategic maneuver. scummvm grew in part, by slurping other projects and in the process it had a scale effect. The more it grew, the more attention it got and that generated more growth.

easyrpg has nice branding, a website, obs builds.... By absorbing mkxp, you get some more developers, in general more interest from more people, You not only get the existing devs of those projects, you'll get more because of non linear effects. The whole is greater then it's parts.

Maybe they are somewhere projects for older versions of rpg maker? Or even for newer ones?

The comparison with scummvm is appropriate. RPG maker games have become an incredible mess. That will require a large centralized project, allowing for a large number of devs, to make sure their favorite games work. It's far less realistic, to make instead a large number of independent projects. Imagine if scummvm was spread over a large number of projects, if you had to chase around and maintain the separate binaries for the 100 plus games, and how much the users would need to dig around to find them. Instead, you have a single project with all the guesswork build in and many contributors know where to go to contribute.

A similar project, would be yt-dlp (the new youtube-dl). Imagine the mess if you had 100+ projects instead of one.

If the strategy is successful, the project could go full scummvm and start eating other non rpg maker engines, including stand alone rpg games. scummvm has become so big, that it has even successfully got the original source code of some games. What's the probability of getting now, the source code of the original rpg maker from 1992 versus a much larger rpg project?

And the name is nice and neutral "easyrpg". Instead scummvm and youtube-dl names became stupid fossils over time.

yea, i've seen those #2445 #2615

You just need a good dose of megalomania....

[carstene1ns]

mkxp and our Player are totally different. You would need to start one engine from scratch to make this happen. mkxp is not meant to be pointed at any game and just work(what our Player does), so you would need to adapt the engine and game to gain compatibility. This is also a huge task. mkxp uses a Ruby interpreter that can work with the game scripts, there are language differences between different versions, that make this difficult, some game scripts behave differently, our Player has a "clean room" reimplementation of the scripting "language" used, so we do not have this problem.

The general idea is not bad, but we cannot work on such a task.

Maybe an external game launcher could be made, that lists games and launches either mkxp or Player.

[pirate486743186]

Maybe this should get a more general input then just you? Reopen it and tag it RFC? kernel developers trying to design a gui. What can possibly go wrong?

The implementation details are up for discussion. How does scummvm do it? For them it goes from minor variations of the scumm engine to totally different 3D engines. Obviously they aren't treated the same way internally. I'm sure you can have a lot of debates on how to properly design the internals.

Probably there should be a common gui, cli interface, some common libraries.... The common branding is more important then you realize, just look at the successes of scummvm and youtube-dl. It's non linear, the sum is greater then the parts.

You aren't meant to immediately have a perfect product. Instead of thinking inside a narrow box, you should consider the number of games that the project supports. scummvm has a list of games it handles, it never said, we'll support all scumm games or none, it didn't start with the goal of supporting all scumm games. mkxp already supports out of the box a few games. Individual tweaks can be added over time in a smart manner to handle more games. The point is, that you'll attract contributors that care for this or that game. For example in scummvm there's support for an obscure russian game, that probably was part of a devs childhood. There's also support for an absolutely terrible game, that probably was done because some dev thought it would be funny. Immediately you'll be getting the devs and contributors of mkxp and forks.

There's also the 80/20 rule. In general, going to 80% is the easy part, the final 20% is exponentially more difficult. Adding engines allows increasing the number of supported games faster the trying to go 100% on a single engine.

What you are describing is indeed that it's a complete mess of compatibility. The correct strategy is going with a list of supported games and a generic method. Not trying to be perfect. You should support games, not engines. You do this of course in a smart manner so that you don't get crushed by the complexity.

scummvm did it, this is proof that it can be done. If you are about to say X can't be done. Just have a look at scummvm and see their strategy. The original goal of scummvm was to simply run monkey island.... then feature creep slowly went "out of control" and it was very successful.

[Ghabry]

tl;dr: This doesn't really fit in this repository, maybe a fork that reuses the core components would be better. The amount of code-sharing between 2k and XP is close to 0.

---

The current project goals are:

• A player/engine compatible with 2k/2k3 games and EasyRPG games
• A editor to create your own games running in our engine (not very advanced yet)
• A collection of free assets similar to the RTP

So we kinda diverged from the initial "run all 2k games" to "an engine to make classic RPG Maker-like games".

There are also already the first games out that are powered by our engine.

We also lack time to do anything more.

---

Adding support for XP/VX would add lots of unrelated code to the codebase that would confuse the users of our engine.

For any amount of relevant compatibility with popular XP/VX games one would need a gigantic amount of WinApi emulation and reimplementing of DLLs. mkxp and mkxp-z (well the last one a bit) do not care about this stuff so most of the mkxp would be (no offense) useless. The only part we can take is maybe the ruby bindings and the rest must be written from scratch anyway.

So I'm not sure if taking anything from mkxp would be even worth it.

---

I totally understand your intention and if I would have more time I would consider this a side-project. I also documented many parts of RPG Maker 95 already as this engine also lacks a reimplementation yet. (and XP/VX also needs one as mkxp is not focusing on compatibility)

Though this work should be done in a fork. The core API can be reused. When it looks feasible it can still move in a different repository under the EasyRPG umbrella.

[fdelapena]

If all workarounds from mkxp-z and even the almost game specific patches from JoiPlay, that could work, however this needs some effort, Ruby experience to handle the workaround mess and handle with care end of life ruby versions for potential vulnerabilities.

Clarify how licensing stuff is going on first (regarding internal and RGSS API), also EasyRPG Player was planning a GPL exception allowing engine linking with SDKs to be allowed on game stores, but that won't be possible with MKXP, likely, so this has concerns regarding which engines are allowed and adding clarifications.

Because this needs quite some work, in case of volunteers interested on getting MKXP working out of the box for most games and packaging, I think it could be simpler a "distro" effort first, making MKXP easy to build, port and run (just by placing a Game.exe replacement). Once this is done, providing a launcher would be more feasible.

Regarding design about potential editor features, abstracting liblcf and an equivalent for RGSS data would prevent code duplication for data manipulation. Events behave different between engines, so in case of supporting commands in a merged way somehow, the wouldn't behave the same when running, and there would be argument differences anyways being backwards incompatible. Current editor interface is tightly bonded with liblcf, so interested parties should make a major revamp or considering an editor fork to manage RGSS data, assuming a liblcf compatibility layer when the API is not stable yet is likely hard.

[pirate486743186]

Before saying X can't be done, look at how scummvm did it.

scumvm has plenty of completely different engines. Practically all scumm games have slight variations in the engine, doesn't that sound familiar? mkxp was written by a mad man? Add it in as an engine and leave it like that until some one shows up that cares enough to fix it. You don't have to contribute to that part of the project, if you don't care. Allowing a multitude of engines have nonlinear effects by attracting more attention. You should definitely support the common parts and internal library subdivision.

You tell users you support these games and that they are generic methods that may or may not work. You tell them the generic rm 2000/2003 has something like... 80 % compat and the generic XP/VX something like 10%. A bit like how wine compatibility is communicated to users. Don't insist on 100% or 0%. You need to adopt the scummvm attitude. You support games, not engines (you do this intelligently internally). People play games, not engines, a lot of them don't even know what's a game engine.

I'm talking about a full merger with the other projects, not forking their stuff. It means these devs join the new easyrpg project. You'll need to negotiate with them. scummvm slurped many projects( including their devs), it can be done.

The editor remains as is, until some one wants to expand it. It's like the weird scummvm games, some one cared about supporting these games. There was a debate in scummvm if some thing like land of lore should be supported. That was very different from the usual games they supported, but it was reusing the kyrandia engine. The point is, someone cared and did it. 3D was an other controversial move.

About licensing, you could have a compile flag to exclude it on compile time. Or decide something else given the new circumstances.

You should support games, not engines and don't be perfectionists. You should also seek advice from scummvm devs for the general strategy to adopt. Their experience should be applicable here.

The original goal of scummvm was to run monkey island. That was it. You conquer the world, one step at a time, not in one leap. The wine project is what? 25? It still not perfect, is it a failure?

[Fishaphrodite]

Disclaimer : I'm not a dev of easyrpg-player, I follow since a little while however. People more aware may correct me on what I'm saying if it happens to be innacurate.

There are several things that don't really work with the scope of easyrpg and this suggestion, the first one being : Easyrpg isn't meant to be just a player for rpg maker 2k/2k3 games, it intents to one day expand on it, the editor is currently developed as well (although far from being finished https://github.com/EasyRPG/Editor/ ), retrocompatibility was more meant as an added bonus, and also to avoid being "yet another RPG engine that may simply not be interesting compared to other that exist".

Second point, ScummVM's approach is actually quite nicely done, however it basically reproduces specific games, a "limited set of games" per engine I believe (This info isn't fully accurate I believe, as it also supports AGS games nowadays, although this may be a direct implementation of said engine?), that doesn't seem like a big point, but RPG Maker games are made by people which sometimes do the most random uses of it to make stuff happens, by fixing one game, you can break several, and it is far from being obvious which ones to privilege compared to other.

But I think what you are asking (which may not be accurate, it just is how it feels) is for easyrpg to just absorb other, smaller projects, and unite them all under one branding, which not only could be problematic if something troublesome happens to one of them (thinking back to https://gist.github.com/Ancurio/fc568571eaf7dd62c550dc3a08c0d08f as mkxp was mentionned), but also seem to not be the only way to tackle it : as carstene1ns mentioned, making a separate launcher that is able to launch easyrpg compatible games as well as other engines should be doable (there are actually retrogaming OSes that do just that, I'd imagine frontends usually would also be able to handle this, but we could also imagine even smaller applications being able to do this, perhaps even just pointing to a game, try to identify the structure, and use the most probable engine; sure it is work, but it seems far less troublesome than both other approaches, especially since, while scummVM runs really popular titles in its list, older rpg maker titles are not as… popular I'd say).

It occurred to me that having an implementation of easyrpg-player in scummVM itself isn't that much different from your original suggestion, and is actually more in line with what you describe, I doubt this is doable easily (I assume it's not a simple matter at all), but it's probably out of their scope as well so I doubt it'd happen either.

[pirate486743186]

can some one reopen this and label it RFC? Thank you.

engines in commercial games have generally custom changes, making them slightly different from each other. Practically all classic scumm games were done this way, this is why scummvm has supported them one at a time. You basically have the same problem with XP/VX.

AGS was open sourced then ported to scummvm. For these type of engines you get the problem that you need to reproduce the original bugs to reach 100% compat. These are comparable to wine.

There's a very good technical argument in favor of going the scummvm way. Long term maintainability. The engines depend on internal scummvm APIs that offer an abstraction layer to the outside world. As external libraries change, you just need to fix the abstraction layer, not all your engines one by one. If you have 100 different engines that you want to maintain for 100 years, you should do it this way and not with simple launchers. This is in addition to all the social benefits you get from having a larger project.

Popular? They are some obscure weird stuff in scummvm that are not popular at all. Some dev supported an obscure russian game, probably part of his childhood. An other one supported an absolutely horrendous game, because he thought it would be funny to do it.(it's "plumbers don't wear ties" if you want to enjoy the -5 star quality work XD )

lol... joining scummvm is also a perfectly reasonable possibility. I'm perfectly serious here. They will complain a LOT though. They resisted 3D games.... Feature creep won several times already with great success. This might need a few more APIs in scummvm. It's amazing that no one mentioned systemd yet.

[Ghabry]

can some one reopen this and label it RFC? Thank you.

No.

This is not a discussion platform. Please continue in the Forum (https://community.easyrpg.org/). Thank you.

The engines depend on internal scummvm APIs that offer an abstraction layer to the outside world

Well yes this is how to do it. We already use abstractions for portability. Which still means that we would need to rewrite half of mkxp to use our API.

[pirate486743186]

I know that trick, go hang your proposal in the basement behind the door with the sign "beware the tiger". I don't think you even read 10% of what i said.

You are forgetting the people that wrote those in the first place. By merge, i mean you take in the devs too. You are not meant to fork it. mkxp will seas to exist as an independent project. You are meant to negotiate with them. They actually care about mkxp, you don't. They'll port it. For that, you need to decide on a stable API that is fixed in stone.

You will have more devs, having to maintain the common parts. These devs will not care about rm2000/2003 and will not contribute much to it, they will be there because they care about their pet engines.

You are also forgetting all the social positive effects. Various economies of scale.

Yes, it will not be cost free. But the costs are worth it in comparison to the benefits. If you are too selfish you'll miss out on the benefits.

And you are not meant to stop with mkxp.

Can anyone reasonably argue, that scummvm is better of splitting into 50-100 tiny independent projects? If you can't, you can apply the same reasoning in reverse, as to why easyrpg is better of fully absorbing other projects.

[pirate486743186]

Now i have a more grandiose plan.... :P

Technically it would have been fine to just join scummvm. However that would cause a lot of drama there. So a viable alternative is to split scummvm into libraries, so that other projects can use. The scummvm common parts is mature 20 year old code with extreme multiplatform support and extreme long term support. Technically, it's simply considerably better, then anything you guys will produce in 10 years.

This part of the project would include you, scummvm devs(~50) and devs from a bunch of other smaller rpg projects. That could be mkxp and forks, zelda classic, exult.... maybe more (zelda ocarina of time decompilation project?).

Once this is done, you and the above small projects, port their engines to these scummvm libs. All that, plus eye of the beholder 1&2 and land of lore from scummvm, will form the new easyrpg. For porting, the easiest way to do it, is with a wrapper. The performance hit will be minor. Additionally, new easyrpg will be a little sister project of scummvm and there will be a link to easyrpg website from scummvm website.

A lot of negotiation will be needed between all these projects to hammer out the details. Yes, it will require some extra effort, but it's totally worth it. They are important positive non linear effects in doing it this way.

Yes, i can't contribute with programming. My brain is simply not wired for that. I think what i'm proposing is a very good strategy.

[Ghabry]

Honestly I'm not sure if you are trolling or serious but this sounds more like the first.

I'm locking this issue now. This is a milestone in the history of EasyRPG Project because that is the first time we use this button.

The next troll/bait post will get you banned. Thanks.

---

The ScummVM discussion already happened in 2017 btw (#1310). They achieve there high possibility with restrictions such as "No C++ Standard library (STL)" which means that we would need to rewrite half of our code first.