Announcing project TURBU

[Mason Wheeler]

I mentioned this in my "Hi all" thread a few weeks back, but I figured the project should have a more thorough introduction, so here goes:

I've always been interested in computer programming. One day when I was in third grade, my dad brought home an Apple IIe. It took me a few hours to discover Applesoft BASIC, and I thought, "awesome! I can build my own video games!" And it's been an idea that I've been playing around with ever since.

I discovered RPG Maker 2000 soon after it came out, and I've always been pretty good at scripting with it. Pretty early on, I ran into trouble with team development. RPG Maker doesn't seem to understand the concept of multiple contributors, and anyone making changes to the LMT or LDB has to coordinate their work carefully with everyone else so they don't stomp each other's changes. I got fed up with that and decided to see what I could do about it. It took me a couple weeks poking around with Delphi and a hex editor to figure out the file formats, but I came up with The Encapsulator, a tool that allows you to track changes, create patches, email them to other project members and re-integrate them seamlessly on the other end, and they loved it. It really sped up development on the project I was working on. (It's no longer available, though.)

Then one day a few years back, I was working on a different project that needed to do some things that RPG Maker's script format just didn't provide any way to accomplish, and I thought, "I could probably do better than this myself." So I decided to try. I already had code for the file formats, so I started trying to clone the map and script engines, and the TURBU project was born. What I came up with almost worked, but it had some serious problems trying to get scripts to work correctly, and there were a lot of subtle bugs in the graphics system. But it was only intended as a proof-of-concept anyway, and I'd proven I could do it.

I've spent the last few years tinkering with it and building the real TURBU engine and editor, the project I wanted to make all along that would replace RPG Maker 2000/2003 and allow developers to continue their work on a less limited platform, with more powerful scripting and more opportunities for customization.

The project is currently at version 0.9.1, and includes:

• A full project importer, allowing you to convert your existing RPG Maker 2000 or 2003 projects.
• A Battle Global Scripts section, like the standard Global Scripts (my name for Common Events) but for battles. Since the lack of this feature typically leads to widespread duplication of certain scripts across nearly every Monster Party, the importer searches for duplicates and automatically moves them to the Battle Global Scripts section.
• A working map editor with full support for drawing tiles, editing map properties, creating and deleting maps, and creating, placing and deleting map objects.
• A partially-implemented map object editor. Not all features have been implemented yet.
• Music support for a wide variety of formats, including MIDI, OGG, MP3 (currently disabled due to technical issues, will be included soon) WAV, FLAC and any tracked format supported by Modplug.
• The editor is powered by an imbedded instance of the actual map engine, complete with Play and Pause commands. (No more needing to launch an external program to test your maps.)
• Data storage as a Firebird database for much faster access. No more closing the Database window and then waiting for 30 seconds while it saves things.
• A script editor with commands stored by category (no more needing to memorize which page the button for each command you're looking for is on) and the event scripts themselves stored in a collapsible tree view, so you can hide branches you're not interested in at the moment.

Planned features include:

• A full scripting language behind the simpler event scripts to provide more fine-grained access to script functionality. (All event commands will be translated internally to script code and executed by the script engine.)
• Event handlers for various common occurrences. No more need for awkward "Parallel Process: If Hero has Weapon 5 Equipped then Hero Learn Skill 13 else Hero Forget Skill 13" style common events executing endlessly; simply attach a script to Weapon 5's OnEquip event and another one to its OnUnequip event.
• The ability to customize various algorithms with scripts, such as EXP and stat curve generation, battle mechanics, and "number of steps until next encounter." (No more problems with RM2003's EXP curves.)
• A private Switch and an Integer variable built into each map object. (No more need to fill up the globals array with a switch for every single treasure chest!)
• Two new global arrays: strings (no more needing to use fake "hero" slots to hold arbitrary text strings) and Real numbers.
• Built-in support for common battle commands, such as Steal.
• A vehicle editor. Define more than 3 vehicles and customize how they animate, how fast they move, and what terrains they can and can't cross.
• A tileset editor that's not locked to a fixed-size tilesheet. The basic image file is a "tile group" instead, containing a small number of tiles, and each tileset can contain as many or as few tile groups as it needs.
• Likewise, a sprite editor that's not locked to a fixed-size sprite sheet. Sprite files are saved as strips, not grids, and animations are defined by a customizable "action matrix" that can describe any number of different movements.
• Full support for both RM2000- and RM2003-style battle engines. (And I definitely plan to fix the thing where the more enemies there are in a 2003-style battle, the slower the ATB gauge fills!)
• Developed as open-source in the USA, so no English translation issues (name input box comes to mind) or "questionable legality" problems exist. If you build it with TURBU, you can release the project any way you want, including commercially. (Assuming you have the right to use all the artwork and resources used in the project, of course.)

I could go on, but those are the highlights of the project. If you're interested, you can find it at http://turbu-rpg.com. So run your project through the importer and give it a try! Any feedback is welcome.

 

[Sailerius]

Why bother supporting RM2000 or 2003? Aside from being legal to own, XP and VX are far more versatile and better-featured. Also, there's already another engine which supports most of those features ( http://rpgmaker.net/games/2664/blog/5229/ )

 

[Mason Wheeler]

Because VX wasn't around when I started working on this, and XP never really caught my interest. And the newer versions may actually have halfway decent scripting, but in a lot of other areas they're a big step backwards from what you could do in RM 2003.

As for RPG Maker 20XX, I haven't used it, but I just took a look and here's what caught my attention:

• No editor, and IMO I'm more likely to finish up the features I'm missing faster than the author of RPG Maker 20XX can build an editor. (Especially since it's written in Visual C++, which makes GUI design a lot harder than it needs to be.) The engine is the easiest part to write, really.
• There are some new script features implemented with a really arcane "register system" built on top of the existing global variable array, but no real scripting.
• Running on SDL 1.2, which means it will be missing a lot of capabilities that TURBU has that require SDL 1.3. (The version numbering is deceptive, BTW. 1.3 is a major revamp, and upgrading a project from 1.2 to 1.3 is a non-trivial undertaking.)
• Still uses RPG Maker's data file formats, which slows large projects down.

Admittedly, that's just an off-the-cuff assessment based on a quick glance. Feel free to compare the two systems yourself and see which you like better, although at the moment a straight comparison is difficult because he's got an engine and no editor, and I've mostly focused on getting the editor working, with a really minimal engine so far.

 

[Sailerius]

And the newer versions may actually have halfway decent scripting, but in a lot of other areas they're a big step backwards from what you could do in RM 2003.

Such as?

 

[Mason Wheeler]

And the newer versions may actually have halfway decent scripting, but in a lot of other areas they're a big step backwards from what you could do in RM 2003.

Such as?

Well, just off the top of my head, a lot of missing event commands. (And before you say, "yes, but those can be implemented in scripts," that's the whole point. They *have to* be re-implemented in scripts if you want to use them, and if they're implemented two or more different ways by two or more different people, you end up with a bunch of incompatible code bases, which is a real pain if you try to build, distribute and use script libraries.)

Plus, the script engine will bog waaaaaaaaaaaaay down if you run more than a few scripts at once, unless you take some highly unobvious steps in your designing to circumvent this. Ruby may be a lot of things, but performant is not one of them.

 

[Sailerius]

And the newer versions may actually have halfway decent scripting, but in a lot of other areas they're a big step backwards from what you could do in RM 2003.

Such as?

Well, just off the top of my head, a lot of missing event commands. (And before you say, "yes, but those can be implemented in scripts," that's the whole point. They *have to* be re-implemented in scripts if you want to use them, and if they're implemented two or more different ways by two or more different people, you end up with a bunch of incompatible code bases, which is a real pain if you try to build, distribute and use script libraries.)

Plus, the script engine will bog waaaaaaaaaaaaay down if you run more than a few scripts at once, unless you take some highly unobvious steps in your designing to circumvent this. Ruby may be a lot of things, but performant is not one of them.

Only one event command is missing in RMXP: the ability to scroll the panorama. And you make it sound like copy and pasting a single block of text is some laborious chore. There's no incompatible code bases because of the RMXP SDK which specifically protects against that.

And where are you getting this nonsense about the script engine bogging down? I've been scripting for years and the only thing that slows down the engine is events. I have hundreds of scripts running at once and I still get a lightning fast framerate.

 

[Mason Wheeler]

*shrug* Maybe so. It's just that your experiences with RM XP are wildly different from those of just about everyone else on the Web who talks about the differences between RM XP and RM 2003. You asked why I don't support RM XP, and I answered. Not sure what else you're looking for.

Does anyone else have any questions or comments?

 

[ForeverZer0]

Its not Ruby that is slow, its specific scripts that can lag a game. Don't use those, and it won't lag.

Ruby is capable of much higher speeds than what RMXP achieves. The part that slows is down is usually graphics rendering, which is a built in C, which has nothing to do with Ruby other than the class is exposed to it with some interfaces that allow for it to call the functions.

 

[Sailerius]

Poorly-written scripts can cause poor performance. Poorly-made event systems can cause poor performance. It's not a fault of the engine.

It's just that your experiences with RM XP are wildly different from those of just about everyone else on the Web who talks about the differences between RM XP and RM 2003.

Care to back up that claim? That's about the opposite of true in my experience. :V

 

[Mason Wheeler]

I'm sorry, but I really didn't come here to say anything about RMXP one way or the other. It's got nothing to do with my project, which is what I did start this thread to talk about, and if it's all the same to you, I'd really prefer not to have it hopelessly derailed before any actual discussion of my project takes place, y'know?

 

[game_guy]

I'm gonna be an ass and post this here.
http://rmrk.net/index.php/topic,40683.0.html

The project's home page is right here.
http://cherrytree.at/cms/lang/en/projects/ultimate/

 

[Mason Wheeler]

Yeah, I've seen that, and even had a few conversations with Cherry about his work. He's a good guy, and quite good at reverse engineering RPG Maker internals. He's even helped me out with a few file format details, and I've got a lot of respect for his skills.

He's just taking a different approach to improving on the RPG Maker concept than I am. Personally I think that my approach is more flexible and in the end will allow designers to do more because it removes the RPG Maker editor, with all its limitations, from the picture entirely and replaces it with something designed from the ground up to be more powerful, instead of trying to bolt new functionality onto it and work around its limitations.

 

[game_guy]

To top off RPG Ultimate and the RPG 20XX. You need a custom editor AND a custom engine. I think that would truly top both.

 

[Mason Wheeler]

Yes, that's what I'm doing. This isn't a modification to RPG Maker; it's a new system that's intended to replace it, and is able to import existing RM projects.