Ruby to C# -> Unity

[Spirographic]

What I mean when I say that something is commercially viable is not about whether it can sell well. It's been shown that RM games can sell very well with projects like To The Moon.

But what makes RM games remain 'not commercially viable' is the fact that if you were to put an RM game out on market, chances are that it wouldn't sell simply because of its connotation and the restrictions on the tool. The processing of code is too inefficient, the rendering too iffy. Level design too restricted.

Many of these problems can be worked around, but they're never truly resolved, and it makes RM a poor candidate for any would be developer.

You can still produce a good game with RM, and you can still release a commercial success with RM. But in almost any scenario, it is preferable to use another engine, even when it comes to JRPG type games.

I'm not going to degrade the tool and say that it is entirely impossible to succeed with RM. But it is not an optimal venture to try, and using another engine with better options, performance, and easier coding languages will always be preferable.

If you're creating a commercial title in RM, far be it for me or anyone else to tell you it's impossible. But you have to understand that you are limiting both yourself and your customers(resolution options, anyone?) by using this engine.

 

[Galenmereth]

You can still produce a good game with RM, and you can still release a commercial success with RM. But in almost any scenario, it is preferable to use another engine, even when it comes to JRPG type games.

I'm not going to degrade the tool and say that it is entirely impossible to succeed with RM. But it is not an optimal venture to try, and using another engine with better options, performance, and easier coding languages will always be preferable.

But have you shipped a JRPG in any other engine? It is actually not preferable to use another engine if you are shipping a JRPG game with turn based combat, for instance, because the performance issues don't really rear their heads if you use the engine for what it was mainly designed for. It is only when we start pushing outside those limits that we find ourselves also having to work on the limits,

The arguments so far in terms of what is "optimal" and not do not weigh in all the variables; it's not just about the tools, but how long it takes to produce things in the tools. How many resources are available; how easy it is to get artists to produce stuff for it. And for making turn-based JRPG's of a more "retro" style, there is actually no better tool. I've tried a lot of them, and it's why I went with this. The baseline on offer here, combined with the resources available, and all the artists supporting it, make it the best choice.

Of course, subjectivity comes into play too. All engines have their own workflows and quirks; RM's workflow and quirks will not be agreeable to everyone. That's fine. But for a lot of people, it is actually the optimal engine for their game.

 

[Engr. Adiktuzmiko]

What I mean when I say that something is commercially viable is not about whether it can sell well. It's been shown that RM games can sell very well with projects like To The Moon.


But what makes RM games remain 'not commercially viable' is the fact that if you were to put an RM game out on market, chances are that it wouldn't sell simply because of its connotation and the restrictions on the tool. The processing of code is too inefficient, the rendering too iffy. Level design too restricted.

Then why did your example game, To The Moon sold very well? You're telling me that it isn't commercially viable as in it won't sell well, yet you yourself managed to give an example of a commercially viable RM game.

But have you shipped a JRPG in any other engine? It is actually not preferable to use another engine if you are shipping a JRPG game with turn based combat, for instance, because the performance issues don't really rear their heads if you use the engine for what it was mainly designed for. It is only when we start pushing outside those limits that we find ourselves also having to work on the limits,


The arguments so far in terms of what is "optimal" and not do not weigh in all the variables; it's not just about the tools, but how long it takes to produce things in the tools. How many resources are available; how easy it is to get artists to produce stuff for it. And for making turn-based JRPG's of a more "retro" style, there is actually no better tool. I've tried a lot of them, and it's why I went with this. The baseline on offer here, combined with the resources available, and all the artists supporting it, make it the best choice.

Same thing for me. I tried a lot of different engines, even tried to make a game from scratch. But for making 2D, RPGs of a somehow "retro" style, RM for me is the best tool to use. Unless I want to spend months building my own 2D engine or spend months trying to learn to use other engines which aren't optimized for 2D "retro" style RPGs which means I would still need to make lots of adjustments.

 

[Tsukihime]

But what makes RM games remain 'not commercially viable' is the fact that if you were to put an RM game out on market, chances are that it wouldn't sell simply because of its connotation and the restrictions on the tool. The processing of code is too inefficient, the rendering too iffy. Level design too restricted.


Many of these problems can be worked around, but they're never truly resolved, and it makes RM a poor candidate for any would be developer.

None of which are things I am concerned with as an end-user looking for a good game to play.


The only people that care how your game was developed are


1. People that aren't interested in your game and are just looking for reasons to hate it


2. Other devs. Probably also for the same reasons as #1.


It is always ironic when I see comments like "There's no way this game can be made in RPG Maker".

 

[Engr. Adiktuzmiko]

The processing of code is too inefficient, the rendering too iffy. Level design too restricted.

And yet we have commercial games made with engines that are far "superior" if we go by your terms. But among those there are those that run pretty slow, some doesn't have nice renderings and some have bad level design.


Again, it all comes down to how you use the tool. A "not-so-good" engine doesn't equate to a "not-so-good" game, and a "good" engine doesn't equate to a "good" game.

They are not things I am concerned with as an end-user looking for a good game to play.

Yeah, if I'm a player as long as I can play it without major slowdowns or sudden crashes, that is fine and I would be happy to play it.


Most players are looking for a good game to play from an overall aspect, not based on "hidden" things that they don't even know about. Especially for single player games. If we go with multiplayer games, especially online and MMOs, then speed plays a bit more key role IMO so code efficiency could matter a lot. But then what was RM made for again?

 

[Tsukihime]

Again, it all comes down to how you use the tool. A "not-so-good" engine doesn't equate to a "not-so-good" game, and a "good" engine doesn't equate to a "good" game.

No, but a bad tool effectively limits your potential.


RM effectively limits you to Windows. Possibly Mac/Linux. That's the same as Playstation games effectively being limited to Playstation consoles. It sucks. Really limits your audience.


If you natively had export for every platform, then you automatically have a better tool with no extra work required.

 

[Galenmereth]

RM works completely fine on Mac / Linux. The added system requirements are negligible, actually. So with RM, you are limited to Windows / Mac / Linux. This is one immensely huge audience. Even just Windows is huge. I know these days, multiplatform is the king, but really, it's not something you should think about much at all until you have a finished game that people like. When that happens, when you've got an audience and fan base on these main platforms, the possibility to get it ported legally to other systems is probably likely to present itself much more easily.

Except, of course, if you are out to make a mobile f2p clone or something; then you probably shouldn't use RM.

 

[Lemur]

For amusements sake, talking over the design process for something like this in Clojure and getting a few alumni on board. Difference is that I'll make the entire thing open source and a lot more extensible.


Why Clojure? Clojure is a Lisp, and Lisp is known to be a language for creating languages, a metalanguage. I'd wanted to experiment in it for a while on something a bit more meaty. Combine that with the JVM interop, allowing for interface with JRuby and you have a scripting and extensibility engine that can be baked in easily. You can also port that to any desktop platform, and maybe with some love and care, Android.


Current working project name is Labyrinths and Lycaons, though we'll find something else for it later. Call it a tip of that hat to D&D. Ping me if you're interested. This will all be open source on github, circumventing the legality of it. Heck, I could even make it play nice with RTP content.


Always a sucker for an interesting challenge on occasion: https://github.com/baweaver/labyrinths_and_lycaons


It'll probably be slow moving as I don't have an incredible amount of free time currently. Combine that with the fact that I only have a few days worth of Clojure experience and this becomes more interesting.

 

[Galenmereth]

That's a very cool idea. But that's also another reason I chose RMAce: It works right now, right here, and is stable enough to ship games. We can talk about the usefulness of an alternative engine when it's ready to ship games with the support RM has; until then it wouldn't be better than writing my own engine and using a tile editor for maps, which would still limit me extremely in terms of art resources, and take a significant larger amount of time.

Your statements on this topic so far are too theoretical: Shipping a game requires all the practical elements to be in place too.

 

[??????]

...

Current working project name is Labyrinths and Lycaons, though we'll find something else for it later. Call it a tip of that hat to D&D. Ping me if you're interested. This will all be open source on github, circumventing the legality of it. Heck, I could even make it play nice with RTP content.

Always a sucker for an interesting challenge on occasion: https://github.com/baweaver/labyrinths_and_lycaons

I will, for one, be keeping an eye on that. ^_^

I'm always looking for alternate engines that allow the use of ruby code. 

 

[Lemur]

That's a very cool idea. But that's also another reason I chose RMAce: It works right now, right here, and is stable enough to ship games


...


Your statements on this topic so far are too theoretical: Shipping a game requires all the practical elements to be in place too.

...you do realize I just said I was starting this right? I don't know what's possessed you to go on that tirade, but whenever I've very clearly stated that something is a new project that seems pretty asinine to call it not stable enough or theoretical. Of course it's not, it's a new project.

 

[Galenmereth]

...you do realize I just said I was starting this right? I don't know what's possessed you to go on that tirade, but whenever I've very clearly stated that something is a new project that seems pretty asinine to call it not stable enough or theoretical. Of course it's not, it's a new project.

I wasn't referring only to this project. I said "your statemenets on this topic so far", meaning all your statements. And yes, I know it's a new project, and that's why I said it's a cool idea; many have had it before, none of them have yet to finish a functional alternative. I'll keep an eye on it, but it still needs to be said that RM is the only actually functional and stable solution with this degree of resource support.