I really hope you're not taking what I said out of context and thinking that I put zero effort into designing the project.
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 this work is far less fan than creating something from scratch.
And there's definitely still plenty of fun work to be done on the TURBU project.
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?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.
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. 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.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.
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...
I'm sorry; I have no idea what that means. Would you mind elaborating?Still, for certain project a dedicated extension can be used which is not suitable to include in basic framework.
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.BTW, are you still with us?
Bookmarks