I've been tossing around the idea to built a new RMXP engine. I don't yet have the whole idea formulated as of yet, but I have been doing some brainstorming and have even began some coding.
Here's the idea:
C# application with embedded Ruby Interpreter
The loose plan is to built the editor with C# and embed an IronRuby interpreter. I have already managed to embed the interpreter and manage to execute some Ruby code using C#, so it is not nearly as difficult as I imagined. I am slightly leary of IronRuby since I have not worked with it before, but I think I will explore it some more for its compatibility with the .NET Framework and ease of use passing data back and forth between the languages.
Ruby 1.9.1
Now this may not seem like such a big deal to those who aren't scripters, but 1.9.1 is far superior to the 1.8 version of Ruby that RMXP uses by default. In addition to being faster, one addition that a 1.9.1 will add is the WINOLE library, which allows for MUCH easier ways to access and manipluate external programs through a script. One example of where this would have been handy is the screenshot.dll that many scripters use. With WINOLE, you would not need any external .dll, and it could have been easily done in maybe 25 lines of code (although that specific feature will likely be a built in feature with my engine). There are far more advantages than mentioned here, as I am sure most Ruby scripters who are familiar with 1.9.1 can attest to.
RubyGems
Gems are add-ons that can basically be added to the Ruby source code. There are thousands of them with a wide array of uses, ranging from added functionality to existing classes, to complex ones like WxRuby that allow you to make Windows forms, which Game_Guy and I were experimenting around with a an idea to re-write the database. This is one of the main reasons I was second-guessing the idea of using IronRuby. Although Gems can be used with IronRuby, not all the bugs have yet been worked smoothed out, and some Gems simply don't work. This will allow for even more ability to scripter to take advantage of Ruby's full potential, which is hampered down in the existing RMXP.
Extensibility
I plan to have the editor be fully extensible, and allow for the use of plugins for the editor. This feature has not been fully thought through yet, but will definitely be a there. What this will do is allow for you to simply copy-paste a .dll that someone created to the "Plug-Ins" folder, and when you run the editor, there will be new tab pages for editting of custom scripts you may have. For example, think of the BABS configuration or the CCTS configuration I just wrote. The plug-in feature would allow for similar things to be written as a .dll and embedded right into the main editor for a one-stop place to edit your game.
Totally Revamped Editor
I plan to re-code the editor to allow for more features. Many of the built in limits will be eliminated, such as a max level of 999, any stats, number of characters, enemies, etc., etc. It will be easier to use, have many minor improvements, and I also plan to not make it modulas. This will allow you to have the map editor, script editor, and database all open at the same time and not having to close one to use the other. It always irritated me that you couldn't do that. All of them will be resizeable and can also be opened during playtesting. This is the part that I will be coding first, and I will likely release it before the whole engine so that people can begin to take advantage of it.
Open Source
I will leave the engine open source so that it can be editted by anyone with the ability to do so.
Compatibility
One of the greatest things about this engine is that any and all existing RMXP projects will be able to work with it.
I will continue to keep you all posted on progress, but as of the moment it is mainly a bit of a side-project that I do as a hobby to challenge myself. Needless to say, even an approximate release date is not even possible at this time, but I would love to hear anyone's thoughts and feedback.
when RMPY reaches a complete stable state I was planning to do the same thing. I would extend RMPY as an editor for a new engine. the difference was I was going to build it in python with OpenGL. one thing to be wary of. Iron ruby is slower than C ruby. if fact I wouldn't be surprised if your proposed engine ended up slower than RMXP.
Wasn't aware of that. I'll be checking that out.
If thats the case I'll just use the interpreter from Ruby 1.9.1 and devise my own methods to exxhange the data. It won't be quite as easy, but with how buggy I know IronRuby can be with Gems and if its slower, it will be well worth the extra effort. I'm really just trying to use this whole project as a learning experience, so I'm sure there will be many more ideas I'm gonna need to rethink.
Thanks for the tip. ;)
I take that back. apparently newer versions of iron ruby are on equal ground with 1.9 and in some cases faster. that was a surprise. as a counter balance it is considerably more buggy. *dose some more research.*
from the looks of things python is close to 3 times faster than even ruby 1.9 :P
So liek, I herd you liek plugins.
Class Tools Source with the Plugin System used in Class Tools (http://dl.dropbox.com/u/20224394/ClassTools.rar)
Tell me when you have downloaded it so I can take it down.
EDIT: Python is faster because Python isn't actually a scripting language. It's a programming language that runs on a virtual machine, just like Java or C#. I think that only entry point files scripts run directly because all files that are "imported" get turned into files with pyc extension. Naturally it is significantly faster than Ruby.
actually ruby 1.9 is a VM thats why it's like 30x faster than 1.8
Awesome! :O
Too bad 1.9 wasn't used for RMXP >_>
---Feature Request---
Since you're making an actual engine, could you try and make it possible to have multiple layers?
That was planned. :D
I want to make so that the user can define how many layers are in a map, and have a built in option to set the resolution. Resizeable windows will likely be included, though the actual resolution won't be changed, it will allow the user to alter the size in a windowed mode.
I will have create a "conversion" method to translate the existing way maps are drawn to the new way, which won't be to difficult once the resolution method is in place. A rewrite to the Tilemap class may cause a few compatibility issues, but since so few scripts affect this, I doubt it will be too much of a problem. I can probably use a lot of stuff from my Custom Resolution script, though I'm sure there will be some modifications. I would also like to do away with "hidden" classes and have them open.
I will keep you all posted on some plans I have. There are probably going to be instances where I have to sacrifice compatibility with the current system to add new features, and even have to re-write a few standard classes/methods that currently exist. All your feedback can help me determine what's more important in these circumstances.
@blizz: Downloaded the file. Gonna check it out later, thank you!
Quote from: ForeverZer0 on March 03, 2011, 12:08:44 pm
I want to make so that the user can define how many layers are in a map, and have a built in option to set the resolution.
Awesome, you little genius. Also, I'd like to be able to select a battle system. It might be too hard to implement, but I'd love it!
Finally, I think we should try and make an rtp for this, it'd be a good community thing.
Guys, I have an idea. I already thought through a completely new RPG Maker engine a few times and I think it would be a really good idea if we put all of this stuff together instead of making separate projects. Ryex is making a new editor for RMXP, but this isn't a full fledged engine like this. I was thinking of a new full RPG Maker engine and editor, based on C++ with multiplatform support and all that stuff. I already have a a good general structure in my mind and if you are up for it, we could make this a featured project, put together an SVN repository and really make a good RPG Maker that eradicates RMXP's problems. In fact, I think Zer0 Division Engine as a name for the base engine sounds cool. This would be ARC (Advanced RPG Creator).
Some of my ideas for ARC include a smart importer and organizer of scripts and a plugin system that allows you to create your own event commands (create event command, export into special command definition, other users import it). This new subscripting system would be a revolution that allows you to combine eventing and scripting in completely new ways. We would write a more powerful set of base scripts and a special compatibility script that allows you to use RMXP's scripts instead of the ARC base scripts. That would allow you to literally import your RMXP project into ARC with all the scripts you have and everything would work. ARC is a revolution compared to RMXP.
The best thing about ARC is that we already have a base engine: April. I will post more info on this if people want this to happen.
EDIT: I have several reasons why I am suggesting this idea. For one I don't really have time to do it all on my own. Secondly the amount of experience that it required for this kind of project to make it really well is huge and I am fairly confident that I possess this kind of experience. If I give you a structure which you can implement, you will progress a lot faster and a lot easier than without this kind of knowledge. Keep in mind that I have designed and redesigned parts of April (pretty all the libraries around April but never the April library itself xD).
I'd totally be up for it. just one question. are you suggesting that support for the Zer0 Division engine be developed in RMPY too? cause that would be awesome. I would finish out RMXP support and work on Zero Division Engine. if we do combine the projects Zer0 I feel that a name change for RMPY is necessary.
also I suggest git over SVN.
I'm all for it. This sounds great! :D
I will have to practice up on C++ a little, but I know enough of it to know that I can learn more at a pretty fast pace. Visual Studio will help a lot with the syntatical stuff.
Well, the idea was that it is completely done in C++. This will allow high performance and high portability. Imagine ARC for Windows, Mac, Linux, iOS, Android. We can have them all.
the editor would be done in c++ too? I really don't see the point. as it is just the editor power isn't needed that badly and python can be ported to just about any platform that it would be practical to run the editor on. if we wanted to build an editor for android we would need to use a different windowing library anyway.
I'm all for developing the engine in C++ but I see no reason not to use a higher level, easier to program in, language for the editor. that way we could edit the editor faster and it would be really easy for people to extend the editor. RMPY has been designed as a multi platform, multi engine, extend able, and reconfigurable on the fly, editor from the start and it already has all the infrastructure to support rapid development of an editor interface for a new engine.
I see your point. Aren't there libraries and systems for C++ like wxwidgets?
I project that I'm interested in. Not that I'm not liking Remoxes and all but...:<
*moves topic*
F0, you have been give moderator privileges for the new section for ARC.
I will post more info on everything on Saturday, I'm completely booked tomorrow. Let us create something glorious! :)
@Ryex: I think that under these circumstances and your given arguments, Python is definitely a better choice for the editor itself. Just be aware the regardless of the code you wrote for RMPY, it is very likely that the ARC editor will be a lot different from RMPY and a restructured a lot.
Time to learn python!
oh I'm fine with that. that was bound to happen if more than one coder worked on the project anyway. I would like to propose the the RMPY topic be moved here too.
as for the code already written for RMPY. I don't mind if the back end works differently but I would like to develop ARC in the same vain as RMPY in that we strive for a modular, plugin/component based system.
Plugin based development is a must. xD
I will move the topic now.
EDIT: Actually wait. Are you going to finish RMPY? If yes, then the topic should stay there.
It'd be really cool if I worked on this.
It'd give me a lot of experience and stuff, since this is what I wanna study in college...
But... I don't know what I'd be able to provide to the team.
So... D:
You can still provide a lot. If you are given a structure, you can code by that structure. :)
oh I was thinking RMPY could merge with ARC. I would finish the RMXP mode still but if you don't the RMXP mode thats fine and I'll keep RMPY separate.
Well, ARC would be a separate engine and editor. The "RMXP mode" is something that would be done solely through scripts. Basically you get rid of the ARC scripts, insert the RTP scripts and add the RMXP compatibility script and that's that.
I do have one question now that his is a collaborative project and the original concept has changed slightly.
Is this still going to be built on a .NET framework with IronRuby, or we solely using C++ with normal Ruby 1.9 embedded? I realize that we are still in the pre-planning stages, but I know myself and many others in the group are already familiar with .NET, not that any of us are incapable of learning it.
I know we plan to maintain cross-platform comapatibility, and I have heard that .NET is capable of running on any platform, though I have yet to see it myself. If not, there are other similar options such as Mono-Project (http://www.mono-project.com/Main_Page) that may be worth looking into as a viable option.
If we use .NET and C#, we will have to implement everything ourselves. If we go with C++ and April, we already have a lot of problems solved. That's why I suggest C++ and April with embedded Ruby 1.9.x. I'm not sure how well Mono is going, but I do know that you have to pay for Mono for iOS. Also, we could probably forget Android in that case.
When you see the topic about April (I'll post it tomorrow), you will have a better overview of our options.
Okay, that makes sense.
I'll check out April and start brushing up on some C++ tonight... :P
ARC. Our school has that. Academic Resource Center. I'm forced to go. Its a study hall of hell. Except it disguises itself as a heaven with everyone in there being an angle. There is no FREEDOM at all.
If I may, I'd like to suggest lua for the scripting language, as it's easy to use and pretty much the fastest out there.
I know that. What about RMXP backwards compatibility?
Oh okay I was so confused. >.< I thought we were removing ruby period. Just so I understand, we are building the engine in C++ but using Ruby as well correct? And will this make converting RMXP scripts easier?
The plan is a base engine in C++. Then we will make our own set of scripts for the game logic. We will also make a special set for compatibility with RMXP. In that case you have the remove the default ARC scripts, add the compatibility scripts and add RMXP's default scripts. Basically you are running RMXP's game logic on the Zer0 Division engine.
If we decided to go with Lua instead, we would probably have to abandon RMXP compatibility and that wouldn't be such a good idea because the plan is to use RMXP's popularity and vast amount of resources and scripts in order to gain popularity among RMXP users.
Sounds like a plan.
I think abandoning Ruby should be out of the question. Although there are likely other scripting languages that may even be better suited for this, by changing it you will lose a great portion of our target users. Basically what Blizz said.
So what happens if I want to help? o.o
I'm pretty much aspiring to major in Computer Science when I graduate High School, so I think this will give me heaps of experience. I've played with Turning for a year, and just finished my Grade 11 Java course with a 95 final mark, so in terms of programming, I know quite a bit. If we're going to be coding in C++, I think I can get used to it very quickly, since it's mostly new syntaxes. I'm new to the whole concept of .NET and such, so I think this'll be a nice learning process, especially if it's a highly organized and structured project.
If one of you guys wants to talk about this with me and explain to me what needs to be done, email: painshop@hotmail.com and if you have Windows Live Messenger, just add me. I'm actually pretty intrigued with the project, since I noticed that using RMXP for so long, it got really boring and I couldn't commit to a lot of projects. But once I started actually programming, I've had a lot of determination so far, so let's get this thing rolling! :)
we're not using .net just c++ with embedded ruby. other that that just fallow the instructions in the SVN thread and you should be able to take part.
Not sure if this is the best thread to ask in... but meh...
Will this use "real"-world physics?
If so, I think I'd have programming that XD
What do you mean by real-world physics? Like if a character jumps, they accelerate with a certain velocity and then decellerate due to gravity?
Also, I just opened Visual C++ 2010 Express. Damn, the interface looks really sleek. I've been using Netbeans for Java, but I'm really going to start practicing with VC++ while there's no real work to be done for ARC.
Technically RMXP already uses a proper formula for gravity.
Ew, Netbeans. I had my share of that one. xD
I say that we don't need any physics. There simply is no need for it.
I think the physics of the game should just be defined by the creator. If he wants his characters to fly and jump super high, he'll just make them do that. If he wants real physics, he'll implement them. I think including real physics would just restrict the users. Just my thoughts.