Sorry, but this project has been postponed for a little while while I experiment with different game development ideas. This project is not dead, but is taking a backseat indefinitely.OpenRPG Project (and RGame)
Introduction
A while back, I decided that RMXP was inadequate. That's not to say it's not good; it and RGSS are some of the best RAD tools I've seen, easiest to use, and well-implemented. However, there are a lot of shortcomings to it -- among these are the lack of extensibility and basic functions in RGSS (such as gradients), very few filetypes supported, no embedded video, no 3D support, etc. In addition, it's Windows-only -- something I can't stand, since I love messing around with RGSS, but I also love only using Linux or Mac OS X.
So, what to do? It's not like there are any decent alternatives to it that actually replicate all of the features, let alone have compatibility. Well, how about this:
I rewrite it. As open source software. And thus, the concept for OpenRPG (and RGame) was born.
Note that this project is only for UNIX-buffs, devs and those interested in making feature suggestions and submitting ideas. If that doesn't include, please get out, and avoid saying anything negative, no matter who you are.
DetailsOpenRPG
Let's start with OpenRPG, which is a replacement for RMXP (and possibly VX later on.) I've decided that it will not be a program itself; it will be an open source project, with libraries and official editors based on these. I've divided the project into the following sections so far:
OpenRPG-Core: This handles all of the core functionality that is needed for things like opening/editing OpenRPG-supported files, using markup-style formats for it, and certain technology that no editor or engine can possibly go without. It's library will be lib-openrpg-core, and will be the first implemented.
OpenRPG-Auxillary: Holds supplements to the core; this will probably include things such as RMXP Marshal support. Library is lib-openrpg-aux.
OpenRPG-Extending: Extension stuff. Library is lib-openrpg-ext.
The default format will be XML + Zlib deflation; for example, here is a mockup of how a script archive would look inflated:
The First Ever Script Archive (Now in Convenient XML Format!): ShowHide
<archive type="scripts">
<script>
<name>Blah, The First Script I decided to write as a boy</name>
<version>1.00</version>
<author>Dennis M. Ritchie</author>
<about>I wrote this at the age of 8; soon, I was discovered by a small phone company in the Northeastern US and drafted by them to be a developer.</about>
<content>
STDOUT.print("Well, uhh... BLAH.")
</content>
</script>
</archive>
It would then be compressed using Zlib (http://zlib.com/, I believe).
RGame
This is the main project I've been working on, and I've rewritten it around four times now (I'm not that good at C++ dev yet). It is meant to be a replacement for RGSS1, implementing embedded Ruby with full API compatibility. For now, it is based on SDL (http://libsdl.org/ (http://libsdl.org/)), and will be fully cross platform.
Code Excerpts
/*
* register.h
* RGame
*
* Created by Collin Wright on 2/26/09.
* Copyright 2009 Collin Wright. All rights reserved.
*
*/
#include <stdexcept>
#include <vector>
class Register {
private:
std::vector<void *> ptrs; // array of pointers; core of class
int seek // finds the index of the first pointer
// in the array that can be used
()
{
// iterates through array and checks for NULL
for ( int i = 0; i < ptrs.size(); ++i ) { if ( ptrs.at(i) == NULL ) return i; }
return -1; // returns -1 if there is no available pointer
}
public:
int assign // stores a pointer in the first available slot;
// if no room, resizes array to accomodate
( void *ptr )
{
int i = seek(); // finds the index of the first avaible space
// if there is space, store and return index; if there isn't,
// then it resizes and calls itself recursively.
if ( i != -1 ) {
ptrs.at(i) = ptr;
return i;
} else {
ptrs.resize( ptrs.size() + (ptrs.size() * .1) );
return assign(ptr);
}
}
void free // techincally doesn't "free" anything; it just sets an index back to NULL
// this should be called after actually freeing the pointer
( int loc )
{
try {
ptrs.at(loc) == NULL; // set to NULL
} catch (std::out_of_range o) {
std::cout << "!" << "\t" << "::" << "\t" << "Oops: " << o.what() << std::endl;
}
}
void *refer // gets the ponter stored at loc
( int loc )
{
try {
return ptrs.at(loc); // return pointer at loc
} catch (std::out_of_range o) {
std::cout << "!" << "\t" << "::" << "\t" << "Oops: " << o.what() << std::endl;
return NULL; // ensure that NULL is returned
}
}
Register
(int s = 32)
{
ptrs.resize(s); // set the array to proper size and initialize
}
~Register
()
{
}
};
i don't get it.
Don't worry. This isn't finished. Nor is it plain English. Nor is it non-technical.
In summary: I'm making a free replacement for RMXP. If you have any suggestions, post them.
I like the idea and I'd definitely help (since I know you well enough to see you're serious about it), but I've got NO experience or knowledge whatsoever when it comes to making UNIX-based applications.
Suggestions and ideas... Have you planned the core elements and the nature of the games that this program is supposed to make? For example, pixel-based or grid-based movement? If it is pixel based, deciding the Z for parts of graphics is going to be an issue.
My idea for that is that when you import a graphic into the program, the user should be able to define the Z priorities and passability by literally drawing them. So providing tools like straight lines and polygons is recommended.
Next, databases. Instead of a fixed type of database, there should be an interface for the regular user to define their own data structures. I''m talking about the RPG:: classes defined for RMXP. Of course, a set example is provided to the users so they don't get scared away.
Remember to allow extensibiliby but still maintain the simplicity of RMXP. If you make an RM where you have to define absolutely everything yourself like RPG::X classes, you have pretty much wasted a majority of your time. Giving the users too many possibilities will confuse them.
XML has way better compressors than ZLib. I've seen compressors that can easily reduce the size by over 95% of XML files if filesize is your concern.
Another thing to mention is that you should use Ruby libraries rather than implementing Marshal yourself and/or creating an interpreter for Ruby. Also, Marshal is actually most simple data serialization that is dumped into a file.
Regardless of how much you hate Windows and Microsoft, in C# you can serialize an object and all referenced objects in 3 lines of code. I'm pretty sure C++ in VS supports this feature as well, you just need the right library and reflection.
Also keep in mind that an XML format like you described is not very conventient because each time you run the script, you need to remove the leading and trailing XML tags. -_-
There are many ways how this can be implemented and most of them suck. Think things through very thorougly before you make a decision about how your will solve a problem.
@fantasist:
For the most part, Unix development is very similar to on Win, especially when you use cross-platform libraries like SDL. The only main differences are compiler ones.
Thanks for the suggestions. I really hope that this project can be community run, with users deciding on features more. The map and stuff like that is one of the main points I could use help with.
As for the database, here is what I was thinking: Each config "tab" is a ConfigPlatform, which has its own file in ./Data and for which small extensions can easily be written so that new features (like weather effects of something like ATES, for example) can be configured by just popping open the "System" tab of the editor and navigating to the right setting.
@blizzard:
Thanks for the support. Yep, simplicity of the interface is one of the main things I was worried about--that, and avoiding becoming like Firefox with the extensions (for those reading who don't know, Fx is commonly criticized for extension-related bloat). As for the compression algorithms, are there any available with the same level of portability and simplicity as Zlib, and with a copyleft-style license? If there are, I'd go for that.
Sadly, I can't use the Ruby libraries for Marshal; they're tied too deeply with Ruby's object system.
I don't get what you mean about not being convenient. Due to the abstraction I plan on using, it'll be no different that running the same from a Marshal archive, as I'd just iterate through each <content> tag in the file.
Once again, I thank you both for actually giving a care ;)
I'm not entirely sure, but I think they are easy enough that you can implement them yourself or at least get the library and simply use it as part. I haven't informed myself on that matter yet. Google around a bit. In worst case you can always use Zlib, though.
I thought that you could use the entire Ruby system as part of OpenRM. Or you could base it on Python, it's a very similar language.
I meant that the scripts should be separated from the XML. If you meant to organize is that way so each script is internally just plain text with a few extra fields for author, version, etc. which you then translate into XML when saving the script and people need to distribute their scripts by distributing the file, then it's alright. As I said, I meant that XML is good for saving the scripts into a file after entering into the editor, but you shouldn't let the scripter mess around with XML, but simply parse the script only from the XML file when executing the script in the engine.
dude, that sounds really cool. Making it open source would open up all sorts of possibilities. I think you should program an addon system, sort of like what we have for firefox, so that people can use multiple new engine features others come up with.
@blizz: Ah, I see. That clear's it up, thanks
@legblad: As far as the editor, I'm not too sure how it should be done. I'm not exactly experienced at implementing add-on/plugin systems. But for the engine, I though I could use Ruby'y built in extension system, which would make it easy for C devs to code the Ruby-side API and the backend at the same time.
*BUMP*
Working on this
Blizz, the spoiler code is messed up. It doesn't work in WebKit and it adds wierd scrollbars in Gecko 0_o
It works normally in the usual browsers (Opera, Firefox, IE, Google Chrome, Safari (just guessing)).
Safari 4's behavior is probably a bug, but I still get a scroll bar out of nowhere in Fx3. So somethings non-compliant with the code somewhere (screw IE and making compliance optional >:()
Hmm, interesting, unfortunately I know little to nothing about ruby scripting and most other programming languages. However, I am full of creativity, and fresh ideas.
This sounds like a great idea, I'm just not sure of how you would get it to work and exactly what you are going for.
From what I have read, my understanding is that you want to make RMXP but... an open source version, you want to make it from scratch, more customisable, and yet many of the feautures hard to acess in rmxp you want to make easy?
Well the first thing that I think is wrong with RMXP is that it only supports ruby programming, very few serious programmers learn ruby, perhaps a more common or simpler lang (python was suggested I believe.)
If it gets to the point where you want resources I can give sound resources a shot....
IMO Ruby is slightly simplier than Python and less strict.
I discussed with WcW what was wrong with RMXP. Sure, it's good, but there are things that were simple done wrong (i.e. it lags too much).
I'm not knowledgeable in creating programs at all, but just to let you know I support you in this, 100%. This has great potential. I would love to offer my services but I don't think you'd find a need for any. ;_;
*powers up*
Crap. C++/Ruby is annoying the CRAP out of me. I can't get Ruby extended because os some bullcrap and I just don't get inheritance in C++ 0_o So I won't have an RGame demo out for a while, and even then I won't have it compiled for Windows (the code should be fully compatible, though). I'm gonna get basic Graphics and full Input implemented before I release the code and start of OpenRPG, so yeah...
EDIT:
Alright, so to compensate for Ruby's unfriendliness with RGame (and to boost modularity as a side effect), I've come up with a plan. I've already got it divided with a main.c file linking to main.cpp file and calling a CPPmain function so that it compiles right, so I could just do the bulk of the engines main components in C++ and use C externals to provide an API for Ruby to build upon. and extend/embed. Is this too screwy of an idea?
And thanks to everyone for their support, this is no small undertaking for a n00b like me :p
I think that RGSS is pretty much embedded Ruby. So it might or might not be a good idea.
I can't get Ruby and C++ to agree over here. I can embed and extend Ruby fine in C, but it doesn't like C++ too much. :(
That, I can't see any easy way to get RGSS's easy embed feature without doing the sprite class in Ruby X( There's no way to attach values to the objects when they're initialized, which sucks.
Why not? Just make the variables public or make setters/getters.
Well, take this example.
On the Ruby side, to update Graphics all you have to call is Graphics.update, and all sprites are drawn to screen. This means that on the C++ side, I have to keep a vector of all Sprites, and each time the update method is called from Ruby I have to call a function that draws all sprites in the vector. This works fine if you just want to initialize a Sprite on the Ruby side and leave it alone; however, you edit attributes in the Ruby side, too, so that object has to have a reference to its respective Sprite object on the C++ side in the vector so that it can edit the values, which is impossible so far as I can tell without really clumsy stuff like storing the array index in an instance variable.
The alternative is to define a Ruby object using the ruby API and simply operate on Ruby stuff from within C++. The problem is that Ruby doesn't agree with C++ and won't compile when I try to define methods X(
My idea was to simply have main.c load main.cpp, which has an API for C to extend it. For instance, each "sprite" would look like this:
typedef struct {
int type;
void *ptr;
}
and there would be a function to set a function for handling sprites of a certain type, a function to push a struct to the vector, etc. This is the main problem I've had, everything else has worked fine -- this one problem is just so obstinate.
If I get you right, you have two versions of a sprite, a C++ and a Ruby version. Why else would the Ruby version need a reference to the C++ version?
Also you shouldn't use void pointers. Program properly, it will prevent bugs. C++ is a typesafe language, make use of it.
Nevermind, I'll just shutup and do it, I just realized how dumb I was being... *sigh* I hate low-level.
You're not dumb. I chased a bug today for like 10 minutes. I put "self.nextScene" instead of "ogre.scene.nextScene". *smacks head agianst wall*
Also, making an automated updater like you are trying to do isn't easy.
No, it's not 0-o I haven't even gotten to scaling the final thing down to 60fps and implementing Tileset, either :O
Well weather or not you say it's difficult,from the looks of things You gotten a TON of work done on this, whits is quite an accomplishment. I can't wait to see the demo!
Okay, anyone wanna look at the source code yet? :P
I've rewritten this thing so many times I can't count -- my skills have been progressing a lot though, at least I hope. I have full Input, working on video and Ruby embedding. Anyone wanna see it? I can upload it to SF/GH/RF any time :|
However, I can't guarantee you'll have an easy time compiling in Win (except for Fant, who as I understand it already has some Cygwin experience).
Sure! Can't wait to get my hands on it (but I'll have to get back to you in 10-12 hrs, gonna sleep now).
lol. Quote-worthy. ;)
Alright, I'll see if my OpenRM is still open on RubyForge :P
EDIT:
RGame (http://rubyforge.org/frs/?group_id=7150)
Went there, and clicked RGame.zip (http://files.rubyforge.mmmultiworks.com/openrm/RGame.zip), link appears to be broken...
Heh. Works now.
EDIT:
Also, I've added a lot of functionality to the Graphics system now, and I'm working on Ruby (I should have Input and basic Graphics functionality available on the Ruby side tonight).
Quote from: WcW on January 19, 2009, 11:00:48 pm
Sorry, but this project has been postponed for a little while while I experiment with different game development ideas. This project is not dead, but is taking a backseat indefinitely.
so.. its in a coma?
That's there to ward off people.
Now, *shoo*
WcW, I don't know how to compile it ._.
You'll probably need to
1) Set up VS with SDL (relatively easy, http://libsdl.org/)
2) Get the Ruby source code set up (Google? You just need the headers set up so that you can embed)
3) Possibly g++ or whatever Ruby/SDL need to compile, not hard for you since you have cygwin
4) Might have to mess with the headers in main.c, main.cpp, and rb/ruby.cpp