PDA

View Full Version : Care for an 80% solution?



masonwheeler
05-05-2014, 09:22 PM
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 (http://code.google.com/p/turbu) 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
06-05-2014, 12:27 AM
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
06-05-2014, 01:44 AM
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
06-05-2014, 03:23 AM
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
06-05-2014, 04:27 AM
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
06-05-2014, 04:56 AM
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
06-05-2014, 05:26 AM
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
06-05-2014, 06:23 AM
The TURBU engine was originally designed to be a clone of RPG Maker 2000 and 2003As 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
06-05-2014, 01:03 PM
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
06-05-2014, 09:02 PM
My nxPascal does not have a focus.
And is anyone using it?

That's not intended as snark or as an insult, just an honest question. Do you have a user base? Because that's the other thing my project can bring to the table: a strong community of RPG Maker developers who would like nothing more than to ditch an old, outdated system that has not been updated in over 10 years in favor of something that's backwards-compatible but more powerful, flexible and customizable.

If we build an engine from the ground up, even when it's ready we will then need to build a community from the ground up or all that work ends up being meaningless.

masonwheeler
06-05-2014, 11:43 PM
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. :P


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 (http://www.joelonsoftware.com/articles/fog0000000069.html)) 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 (http://rpgmaker.net/games/2972/) 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. (http://rpgmaker.net/games/1295/) 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.

User137
07-05-2014, 05:10 AM
And is anyone using it?

That's not intended as snark or as an insult, just an honest question. Do you have a user base? Because that's the other thing my project can bring to the table: a strong community of RPG Maker developers who would like nothing more than to ditch an old, outdated system that has not been updated in over 10 years in favor of something that's backwards-compatible but more powerful, flexible and customizable.

If we build an engine from the ground up, even when it's ready we will then need to build a community from the ground up or all that work ends up being meaningless.
It gets couple hundred downloads every now and then, but that's about it. I blame the smallness of pascal gaming community ::) I know some things of RPG maker myself, and been scripting something for it on someone elses project.

RPG Maker is software very clearly, not an engine. If we build community engine, it could be used to make a new RPG maker-kind of software package, but in my opinion it shouldn't be part of the main engine. I don't personally have much interest for Zelda type 2D-games, but i know many do. I wouldn't want to restrict the engine to anything at least. I think RTS genre made 3D and things like that can have potential still, but there are many more types. Most exciting ones are propably the ones nobody has thought before.

pitfiend
07-05-2014, 05:51 AM
And there's definitely still plenty of fun work to be done on the TURBU project.

Don't take me wrong, but your engine is to focused for our plans. As we told you, we plan to have an open engine without a specific focus to avoid extreme hackery. The purpose of the framework is to bring tools to develop games as you build a vcl or firemonkey app, obviously we are not planning to use visual components but classes, just to not follow the path of glscene, that I consider a complete mess and I think it's abandoned right now (correct me if I'm wrong).


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 (http://www.joelonsoftware.com/articles/fog0000000069.html)) 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?

Of course we can reuse previously tested and functional code, but you must understand and accept the fact that we are dealing with some kind of license, then if that code exists under a license uncompatible with ours (not yet fully defined), unfortunately we can not use it as it is, some rewrite will be needed, unless the coder donate it to the community changing it's license. The main reason we are working from scratch. And this applies to anyone who wants to contribute with their code, not just you.


Of course. And it's definitely possible to do that. Check out Zero Base (http://rpgmaker.net/games/2972/) 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. (http://rpgmaker.net/games/1295/) 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.

This is the kind of things we don't want to happen. The framework must be friendly enough for any kind of project you want to do. Here comes the modularity we want to implement, the one that allows you to add certain features you need for the project, it could be anything, from multimedia, HUD/GUI/window system, network, database, local/cloud storage, scripting, to anything else your heart calls because the design will allow you to create your own classes based on our API. Even the render system is planned to be modular, so you can choose DirectX, OpenGL (for instance the prefered), SDL or GDI+ if you want.


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.

We are putting all of our efforts and knowledge to build a solid framework as a team, that's why we are taking some time to define standards and design based on our experience. In the meantime, we also learn from what is been building in the framework. As you may know, many here have build their one engine/framework, with some success or failure, but as a solo coder. And we all agree that at some point many promising projects go on hold, because it happens that one coder is not enough to complete the project, some times the lack of knowledge to progress or the most common thing, we run out of motivation. Then to avoid wasting that talent, we decide to create a team to finaly build the ultimate game framework for pascal developers, well documented and able to compete pear-to-pear with comercial engines.

Mirage
07-05-2014, 02:26 PM
My point is that fun (or interest) is very important for an open source project as it gives motivation, including to get "the boring-but-important stuff" done. Without fun it's doomed indeed.

Our goal is similar to what you are writing: build an engine which other people will use.
And we are not ignoring existing solutions. We'll use many of them.


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

Sure. PGDCE will have modular design and will provide many extension points. This allows to add any specialized functionality if a project needs it.


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

Out of context? I don't think so. But may be I misunderstood you.

Dennis
08-05-2014, 07:39 AM
I think it is not a good idea trying to extend an existing engine that at first only the origin developer knows how to handle. Mason, your engine is very very valuable and I think you should just add parts of your engine sources to the PGDCE engine where reasonable. This helps growing the new engine with features but keeps it independent.

code_glitch
08-05-2014, 09:31 PM
Mason, I see where you're coming from but as explained I think the PGDCE project would be inherently incompatible/very klud-ey (sorry for the english there).

That said - I agree with Dennis on the value of an engine such as yours. And although we're not settled on a licence, the jist of things so far would mean you could incorporate elements of the PGDCE engine to extend your own engine or at least speed up development and allow for targeting extra platforms.

On a slightly different note, there also isnt anything preventing you from creating a component that would plug into PGDCE (and its architecture, once its all decided) that would allow programs written from your engine to be run from inside the PGDCE or something of the sorts. Like an RPG SDK/environment one could load into the PGDCE for those types of games. This is just one of the benefits the modular architecture bring to the PGDCE.

masonwheeler
08-05-2014, 09:58 PM
It gets couple hundred downloads every now and then, but that's about it. I blame the smallness of pascal gaming community ::) I know some things of RPG maker myself, and been scripting something for it on someone elses project.

RPG Maker is software very clearly, not an engine.

I was confused when you said that. Then I looked at your nxPascal project, and I realize we have a terminology confusion issue.

As I understand the terminology, what you have is "very clearly not an engine;" it's a library for game development. A game engine (http://tvtropes.org/pmwiki/pmwiki.php/Main/GameEngine) is a program that takes game data and interprets it in order to play a game, in which the basic content of the game is determined by the data and not by the program.


If we build community engine, it could be used to make a new RPG maker-kind of software package, but in my opinion it shouldn't be part of the main engine. I don't personally have much interest for Zelda type 2D-games, but i know many do. I wouldn't want to restrict the engine to anything at least. I think RTS genre made 3D and things like that can have potential still, but there are many more types. Most exciting ones are propably the ones nobody has thought before.

Yeah. You're thinking of building a library. That's something very, very different.

masonwheeler
08-05-2014, 10:10 PM
Don't take me wrong, but your engine is to focused for our plans. As we told you, we plan to have an open engine without a specific focus to avoid extreme hackery. The purpose of the framework is to bring tools to develop games as you build a vcl or firemonkey app, obviously we are not planning to use visual components but classes, just to not follow the path of glscene, that I consider a complete mess and I think it's abandoned right now (correct me if I'm wrong).

This appears to be more of the same terminology confusion. Can we clear things up a little? Are you planning on building an engine, or a library?

If the distinction is unclear, here's a simple rule of thumb: If Joe The Game Developer needs a copy of Delphi or FPC to build a game with the product, it's a library. If he can use the product itself to build a game, it's an engine and an editor.


Of course we can reuse previously tested and functional code, but you must understand and accept the fact that we are dealing with some kind of license, then if that code exists under a license uncompatible with ours (not yet fully defined), unfortunately we can not use it as it is, some rewrite will be needed, unless the coder donate it to the community changing it's license.

My project is MPL-licensed, which is pretty much the de facto standard for Object Pascal open-source projects. So there shouldn't be any problems.


This is the kind of things we don't want to happen. The framework must be friendly enough for any kind of project you want to do. Here comes the modularity we want to implement, the one that allows you to add certain features you need for the project, it could be anything, from multimedia, HUD/GUI/window system, network, database, local/cloud storage, scripting, to anything else your heart calls because the design will allow you to create your own classes based on our API.

Yeah, this is sounding more and more like a library.


Even the render system is planned to be modular, so you can choose DirectX, OpenGL (for instance the prefered), SDL or GDI+ if you want.

*cringe*

Two problems there. First, why would you want to choose between DirectX, OpenGL and SDL, specifically, seeing as how SDL is an abstraction layer that has DirectX and OpenGL backends?

Second, doing any non-trivial visual effects these days requires shaders. Offering a choice between DirectX and OpenGL means that you just doubled the work your users have to do, since they use incompatible shader languages.


We are putting all of our efforts and knowledge to build a solid framework as a team, that's why we are taking some time to define standards and design based on our experience. In the meantime, we also learn from what is been building in the framework. As you may know, many here have build their one engine/framework, with some success or failure, but as a solo coder. And we all agree that at some point many promising projects go on hold, because it happens that one coder is not enough to complete the project, some times the lack of knowledge to progress or the most common thing, we run out of motivation. Then to avoid wasting that talent, we decide to create a team to finaly build the ultimate game framework for pascal developers, well documented and able to compete pear-to-pear with commercial engines.

So you do want to build something that's a market-grade engine? Then you have to play by their rules. Have you ever seen a commercial game engine that can do "any kind of game"? I can't think of any. The successful ones focus on one genre and do it well, and if you want a different kind of game, you use a different engine. Can you think of any examples to the contrary?

de_jean_7777
09-05-2014, 10:02 AM
Can you think of any examples to the contrary?
Unity3D and the Unreal Engine. Afaik, the variety of games I've seen made with these is large. An engine is an engine, regardless if it comes in the form of a library or just compiled into your project (which is most likely course for pgdce), or if it comes with a nice editor for everything. Also, your solution is not an 80% solution, or even close to that. Starting from scratch will make it easier to make the engine cross-platform and modular (being able to use different rendering/audio systems and what not), instead of having to do major refactoring to an existing project. Which in my opinion will end up as more work.

As for why anyone would want to choose between DX and OpenGL, because it gives choice. Also, even if there is no DX support, making the rendering system modular is still a wise decision.

code_glitch
09-05-2014, 02:55 PM
First, why would you want to choose between DirectX, OpenGL and SDL, specifically, seeing as how SDL is an abstraction layer that has DirectX and OpenGL backends?

Because it can run in software for systems with non-compliant GPUs or with faulty drivers and the like. Because its a stable constant across all platforms. Because its high level, someone implementing a new renderer for, say, Mantle, can look at it and understand it easily without having to know D3D/OGL (bad example there I admit) but the point stands. SDL is the go-to library for many new programmers and is well supported and is stable across a great many platforms. Perhaps someone wants a game to run on a new platform that doesnt yet have complete OpenGL/D3D support implemented and wants to test the ui/controls/gameplay and such. SDL can run in software - and it fills that void.

As for the library I thing, I agree with you - it SOUNDS like a library (or many small library-like components) but if you look at the larger picture, its a library with a standard interface between the components so they can be used together in a more efficient manner. And due to its modular nature one could implement a higher level runtime which provides exactly the functionality you were talking about.

Basically, its not necessarily meant to be AN game engine but THE engine. One could make a game, or flight control software, or another engine. Using the modular design lets it fit into as many possible design scenarios as possible - and no matter how you look at it thats a very good thing. Especially when it reduces overhead that you would otherwise have if you wrote your application against an entire library that shipped functionality you didnt use/need.