Care for an 80% solution?

[masonwheeler]

In the announcement, it says that none of the code has been written yet. How'd you like to change that?

I have a game engine that, over the last several years, I've been working on to accomplish most of the same goals as the stated goals for this project. It's almost complete now, but I've been very busy lately and haven't had too much time to put into it. I'd gladly accept help from the PGD community to bring the project to completion.

Basic information:

• The TURBU engine was originally designed to be a clone of RPG Maker 2000 and 2003, with stronger scripting capabilities to reduce the limitations inherent to RPG Maker's system. It's written in Delphi XE, with backend rendering handled by SDL and OpenGL.
• It uses a plugin system for its basic functionality: the game engine and the battle engines simply implement a defined interface, meaning that other engines could be written for it when the current one is finished.
• Almost all gameplay functionality is working, with the exception of the battle engine and the ability to play movies.
• Scripting is provided by a custom Pascal scripting engine I wrote, but it's not all that good so I'm currently in the process of converting it to DWS. I am a contributor on the DWS project, and several of my contributions have been things designed to make it work better with TURBU.
• The editor can currently create and edit maps and scripts, and import any RPG Maker 2000/2003 project. Database editing panels are still in the works.
• Like the game engine, the editor is a plugin host. It hosts an expanded version of the game engine inside the editor, with additional functionality for editing. This means, among other things, that the developer is able to playtest the game inside the editor.
• The project data is stored in a Firebird database, accessed through DBX.
• TURBU is currently Windows-only, but I'd love to make it able to run on Android as well.
• Sound is provided through Disharmony, a custom sound engine written in Delphi that handles many common wave and music formats, which I modified to hook into libmodplug for extra playback capability. I have the source to it, but I'm not at liberty to share it at the moment. I might be able to change that if I talk with the project maintainer, who has lost most of his interest in continuing to work on Disharmony. This would have to be extensively reworked to make it cross-platform, as Disharmony uses DirectX's sound and music APIs as its backend.
• All code is available on Google Code under MPL 1.1 at http://code.google.com/p/turbu

As you can probably tell, there are still a number of things that would have to be done to make it work cross-platform, such as getting DWS to run on non-Windows systems and coming up with a more portable music player, but most of the basic game engine is already in place. If you guys would like to short-circuit a few years of grunt work, here's one option for you...

Mason

[User137]

I think at this point none of us can be persuaded from starting the engine from scratch It is the only way to ensure we do it right. With all the skillful people combined, we will have no trouble getting things working once settled on design.

[masonwheeler]

I do hope the rest of the community doesn't feel that way. Getting a good design isn't "the hard part, and now it's all easy." I skipped that step entirely--my design was "make a clone of this existing project"--and I still ran into all sort of unknown unknowns and hard work. What I'm offering is a chance for the PGD community to skip a huge amount of *that*.

[User137]

You say it is an engine for making RPG's. A game engine can do anything, 3D first-person-shooter game up to just some fancy mediaplayer. All begins from abstract classes, and specializes to things like certain sound or graphics API. It can support many of them. At the present moment we don't know when or if we'll be adding SDL in the mix, even 2D can be done with OpenGL, using basic or GLSL rendering. Lastly all of the functionality should be crossplatform from the start, and possibly usable on mobile or android platforms. Unless engine was specifically written with all that in mind, it would be difficult to adapt.

[masonwheeler]

You say it is an engine for making RPG's. A game engine can do anything, 3D first-person-shooter game up to just some fancy mediaplayer. All begins from abstract classes, and specializes to things like certain sound or graphics API. It can support many of them.

Every game engine has a focus. The Unreal engine does FPSs, SMBX does Mario-style platformers, OpenZelda does Zelda-style adventures, and so on. With a lot of abuse you can make a game engine do some other style of game, with varying degrees of success, but there's still a basic focus.

Mine is on RPGs, but with the TURBU system being plugin-driven, it wouldn't be too difficult to adapt it to another game style once the first engine is finished.

At the present moment we don't know when or if we'll be adding SDL in the mix, even 2D can be done with OpenGL, using basic or GLSL rendering.

That's part of what I'm offering: those questions have been answered. I've looked at what's available, tried various different choices, and made my pick based on what works, from real experience actually trying to do it.

Lastly all of the functionality should be crossplatform from the start, and possibly usable on mobile or android platforms. Unless engine was specifically written with all that in mind, it would be difficult to adapt.

Why do you say that? The editor is heavily VCL-based, but the vast majority of the engine code is pure Pascal over SDL and wouldn't have much of a problem at all in being adapted to other platforms.

[pitfiend]

Nice offer. It's something to consider, but as User137 said, our goal is more ambitious than an RPG engine. We want to build a definitive engine with solid foundation to use for any kind of game you want to create. We start to talk about modularity design with lots of abstracts to derive from. Anyway it's a team decision we need to discuss.

[User137]

Every game engine has a focus. The Unreal engine does FPSs, SMBX does Mario-style platformers, OpenZelda does Zelda-style adventures, and so on. With a lot of abuse you can make a game engine do some other style of game, with varying degrees of success, but there's still a basic focus.

My nxPascal does not have a focus. https://code.google.com/p/nxpascal/ From the ground up being just a higher "layer" kind of for different API's. It can do all mario-style, FPS games and anything you can imagine. But being a game engine does not come with a statement that it must include editors for all kind of things, some could say they should be developed separately as per game. Each game has different needs for its editors, and i cannot even imagine how something like that could be generalized. Not even for 2D platformer game.

[Super Vegeta]

The TURBU engine was originally designed to be a clone of RPG Maker 2000 and 2003

As I began my career with RPGM, you got me interested. I might want to check it out. Probably the CE with be made from stratch, like User137 said, but if I find TURBU cool enough, I might give you a hand.

[Mirage]

Investigation and understanding some others code is a hard work. Especially if design stage was skipped for this code. And this work is far less fan than creating something from scratch.
Some of PGDCE developers has own projects, including almost complete engines and similar concept-wise to PGDCE.
And some parts of these projects could be partially reused during development of PGDCE. There is one restriction - the code should comply with PGDCE architecture and coding standards. So probably it should be slightly rewritten.
Reusing the whole engine is not suitable in our case.
As of engine focus: I think there should be no focus in a basic framework.
Current games often combine multiple genres and multiple kinds of gameplay.
Still, for certain project a dedicated extension can be used which is not suitable to include in basic framework.

BTW, are you still with us?

[masonwheeler]

Investigation and understanding some others code is a hard work. Especially if design stage was skipped for this code.

I really hope you're not taking what I said out of context and thinking that I put zero effort into designing the project.

And this work is far less fan than creating something from scratch.

Definitely. But historically that's always been one of the biggest failure modes of open-source projects: developers only want to do what's fun (I assume that "fan" was a typo?) and never end up getting the boring-but-important stuff done, and so they end up with something that either doesn't work or technically works but has horrible usability. Approaching PGDCE it from a value system that prioritizes fun for developers will doom the project to failure before it ever gets off the ground. Just saying.

And there's definitely still plenty of fun work to be done on the TURBU project.

Some of PGDCE developers has own projects, including almost complete engines and similar concept-wise to PGDCE.
And some parts of these projects could be partially reused during development of PGDCE. There is one restriction - the code should comply with PGDCE architecture and coding standards. So probably it should be slightly rewritten.
Reusing the whole engine is not suitable in our case.

Why? I'm trying to understand the underlying value system here. What are you valuing, and what are you prioritizing, that makes consciously ignoring existing solutions and building something from scratch (generally considered a Thing You Should Never Do) not only acceptable but The Preferred Solution?

My core priority here is "build something that people will use and enjoy using." The payoff for me isn't fun developing it; it's seeing people make cool stuff with this tool I designed. And so the priorities are "get it finished up quickly" and "get people using it." And those are two completely independent tasks. Even if you get an amazing engine set up, you still need a user base. I've got a ready-made solution to that: appropriate the (still large and healthy) user base of a different, abandoned tool by providing a better option to them. What's the strategy for building a user base for something built from scratch?

As of engine focus: I think there should be no focus in a basic framework.
Current games often combine multiple genres and multiple kinds of gameplay.

Of course. And it's definitely possible to do that. Check out Zero Base sometime: it's an R Type-style shooter built in RPG Maker 2003. Doesn't look anything at all like an RPG. But the scripting that makes it run is a horrendous mess of hackery, because RPG Maker's scripting system is way too restrictive.

Ditto The Tiamat Sacrament. It's a pretty standard console RPG... right up until you start hitting the turn-based strategy minigames! The scripting to those is downright scary, but it exists and it works.

That's one of the things I'm actually trying to accomplish: make creating non-RPG stuff easier by providing better scripting support. A lot of the reason why the script code is so bad in these games that go outside the box is because RPG Maker's script system is horribly primitive. By putting the full power of the DWS engine in front of game designers, it'll enable all sorts of new and innovative creativity. For example, I've already got an idea for how to build a tower defense minigame in TURBU, if I can just implement two fundamentally new script commands that RPG Maker doesn't have...

Still, for certain project a dedicated extension can be used which is not suitable to include in basic framework.

I'm sorry; I have no idea what that means. Would you mind elaborating?

BTW, are you still with us?

I'd like to be, and I don't want to come across as unreasonable or anything, but I know how much work and effort can go into something like this, and I won't throw away years of my life on a project that is doomed to failure before it even starts. Convince me that this one isn't, and I'm with you.