Multiple Instances of Editor and Play-Testing

[Rafael_Sol_Maker]

Description of the Feature:

• Allow to *easily* open multiple instances of the editor. Better explained below.
  AND
• Allow multiple instances to be play-tested at the same time.

It's possible to open multiple instances by opening project files directly in Explorer. If a project is open, I can't, for example, create a new one unless closing the current one in the process. I can't use windows shortcuts to open a new instance of RPG Maker as well. (Like Shift+Click or Middle-button Click on the icon on taskbar)

In the game part, well, it doesn't make sense to have only a running instance. Imagine for example I'm trying to run a project at the same time I'm playing something else. Maybe even a game, that I want to stay minimized for a while. Because of this limitation, I simply can't.

It could be limited to different projects, so I won't have a lot of zombies instances (same project, but with some differences) trying to access the same files. How about that?

Code for Implementation:
None possible of my part.

Mockups:
Oh well, it's not like I need to show this, hehe.

Why is this feature good?
This feature is great because of the following:

• For plugin creators like me should be insanely helpful to compare multiple running stuff side by side directly;
• Everyone can benefit of instantly creating a new project without closing the current one.
• For normal users, at least they should be able to start a new instance of MV using normal Windows Shortcuts.
• Et cetera.

Possible issues with this feature?
I can't see any downside to that, it's just an artificial limitation that needs to be removed.

Best regards,

 

[Archeia]

You can open multiple instances of RPG Maker even when a project is open. I can do it by just right clicking the software on the task bar and it will open one. Like this:

Unfortunately your claims here:

• Allow multiple instances to be play-tested at the same time.

Does not make sense and I would like clarification for this. I see a lot of cons about this. It doesn't make sense to keep an older instance of a playtest when you're updating a project.

Unless I misunderstood and you meant that you can playtest two different games at once.

 

[Rafael_Sol_Maker]

I pointed 2 different things here, sorry if it's confusing. Let me try to explain better,

1. Open multiple instances of the editor:

You can open multiple instances of RPG Maker even when a project is open.

Yeah, it does work if you open directly a project file, or use Windows jumplists. I'm talking about keyboard shortcuts. Let me try to show you:
What isn't working are Windows shortcuts for doing so.

2. Open multiple instances of game with different projects:

I see a lot of cons about this. It doesn't make sense to keep an older instance of a playtest when you're updating a project.

I adressed that here:

It could be limited to different projects, so I won't have a lot of zombies instances (same project, but with some differences) trying to access the same files.

As I explained before, the use case is playtesting two different projects at the same time. Like I tried doing here:

(Other possible shortcut I forgot to show in video: WIndows key + Shift + Index position in taskbar)

Hope it helps, right now I'm a bit of hurry, but I can try to explain better later.

 

[Poryg]

I'm voting no.
The usage of cpu is too high for it to be useful. I mean the playtesting part, not the editor part.

For instance, a stock project consumes 53% cpu on my 1.6GHz machine. With the main process taking up my whole main cpu logical thread.
Now imagine what would happen if I launched second instance of an mv project. The main thread will free up the most space for whatever process is currently active, so in a stock project it's no big deal. But imagine a normal mv project with plugins and stuff. Launching two instances of resource demanding projects will not be of any help. And many regular projects are resource demanding.
So I'd say it's too much work for too little gain.

 

[Rafael_Sol_Maker]

I'm voting no.
The usage of cpu is too high for it to be useful. I mean the playtesting part, not the editor part.

For instance, a stock project consumes 53% cpu on my 1.6GHz machine. With the main process taking up my whole main cpu logical thread.
Now imagine what would happen if I launched second instance of an mv project. The main thread will free up the most space for whatever process is currently active, so in a stock project it's no big deal. But imagine a normal mv project with plugins and stuff. Launching two instances of resource demanding projects will not be of any help. And many regular projects are resource demanding.
So I'd say it's too much work for too little gain.

Fair point for the play-testing, the shortcuts won't spend resources at all (just a bit of Windows API, I presume).

Well, I'm on quad-core CPU right now(nothing to brag about, it's a weak CPU, though), and that could be the norm onward. Even on laptops. Am I being elitist and preaching against the lower-core-count? Nope, please notice here that it's just for the sole purpose of playtesting in a specific scenario. It won't impact anyone, even the final user. (I assume that the machine that someone should use to create a game should be way more powerful than the one to play it, not the opposite)

Right now I'm playtesting it in a browser and dude, browsers are the real resource hogs in the equation. I won't disable everything in my browser that I use daily just for the sake of playtesting. I'm still trying to find a better workaround, since browser window consumes so much space anyway.

Back to my suggestion... While it still use lots of resources, I see it being useful for me, that needs to compare working of multiple plugins in different projects for testing compatibility and so. It could be of help for me (and maybe some other guys), so it is useful in some significative manner. I don't think it will be useful for a mapper or someone dealing with database in normal circumstances, but who knows. Once you give the option, people will make good use of it for their own projects.

I just see this as an artificial limitation. Basically it means that looks like it was hard-coded this way, intentionally. They spent work on doing that, all they need is to remove the barriers they created, I suppose, by removing few lines of code. Dude, I'm a programmer... Daily I spent way more work on trying workaround that than they doing that simple job once.

One can have a much better CPU and want to run how many instances he wanted. If you don't want to open more than one instance of Game.exe because of whatever, I'm fine with that, "your computer, your rules" ; but the software impeding me for doing so... Is a bit saddening for me, again, because I'm feeling limited.

Sorry if I'm sounded harsh in some spots, my english is still rough. Best regards,

 

[Poryg]

No offence taken, I see why you request it. However, this is exactly the case when it's something I can't agree on.
The thing is, it's not as easy as you say. Think about the consequences.
You say that it's enough to just delete some code. Which is definitely enough to unlock the barriers, but it means total unlock.
Is total unlock acceptable for the community? The answer is no. Because programmers are a vast minority in the community, let alone those that test their plugins in various environments.
And in the remaining vast majority it is much more likely that someone forgets they are playtesting. I do it all the time and I think I'm not alone. Both in plugin making and in mapping.
So there would need to be a different solution, some that would for example allow for each instance of the editor window to have its own playtest process. I think it was what you suggested initially. Which needs more than just deletion of some code as far as I know. And who would use it? I doubt even 1% of the community would.
So once again, it's too much work for too little gain.

 

[Rafael_Sol_Maker]

No offence taken, I see why you request it. However, this is exactly the case when it's something I can't agree on.
The thing is, it's not as easy as you say. Think about the consequences.
You say that it's enough to just delete some code. Which is definitely enough to unlock the barriers, but it means total unlock.
Is total unlock acceptable for the community? The answer is no. Because programmers are a vast minority in the community, let alone those that test their plugins in various environments.
And in the remaining vast majority it is much more likely that someone forgets they are playtesting. I do it all the time and I think I'm not alone. Both in plugin making and in mapping.
So there would need to be a different solution, some that would for example allow for each instance of the editor window to have its own playtest process. I think it was what you suggested initially. Which needs more than just deletion of some code as far as I know. And who would use it? I doubt even 1% of the community would.
So once again, it's too much work for too little gain.

Well, I just fail to understand what would be the downside of this "total unlock", like it's some bad thing, since I'm only asking just for run more than one instance of the Game.exe (it could even be limited to 2 or 3, and already help me a lot) and not for all the entire software being "totally unlimited", whatever it means.

Yes, the solution you presented (one game.exe instance attached to each project) serves me right for playtesting. It's basically perfect, I just don't know what will be the impact by running the .exe directly in Explorer instead of running it by the the Editor. But whatever, let's move on.

Anyway, thanks for the replies, @Poryg! I think we both presented here our points fairly, I don't have anything else to add, now the guys here will judge and see if it's a fair complaint of mine. I know it's just a minor thing that won't affect a lot of users, probably there's way more important things to them to do first (I also have some suggestions that can positively impact pretty much everyone), but I had to at least register my concern here.

Again, thanks for the replies, @Poryg. Have a wonderful weekend,