Page 2 of 2 FirstFirst 12
Results 11 to 20 of 20

Thread: Care for an 80% solution?

  1. #11
    Quote Originally Posted by Mirage View Post
    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.

  2. #12
    Quote Originally Posted by masonwheeler View Post
    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.
    Last edited by User137; 07-05-2014 at 05:13 AM.

  3. #13
    Quote Originally Posted by masonwheeler View Post
    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) 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 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.
    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.

  4. #14
    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.

    Quote Originally Posted by masonwheeler View Post
    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.

    Quote Originally Posted by masonwheeler View Post
    I really hope you're not taking what I said out of context and thinking that I put zero effort into designing the project.
    Out of context? I don't think so. But may be I misunderstood you.

  5. #15
    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.

  6. #16
    PGD Staff code_glitch's Avatar
    Join Date
    Oct 2009
    Location
    UK (England, the bigger bit)
    Posts
    933
    Blog Entries
    45
    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.
    I once tried to change the world. But they wouldn't give me the source code. Damned evil cunning.

  7. #17
    Quote Originally Posted by User137 View Post
    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 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.

  8. #18
    Quote Originally Posted by pitfiend View Post
    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?
    Last edited by masonwheeler; 08-05-2014 at 10:15 PM.

  9. #19
    PGDCE Developer de_jean_7777's Avatar
    Join Date
    Nov 2006
    Location
    Bosnia and Herzegovina (Herzegovina)
    Posts
    287
    Quote Originally Posted by masonwheeler View Post
    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.
    Existence is pain

  10. #20
    PGD Staff code_glitch's Avatar
    Join Date
    Oct 2009
    Location
    UK (England, the bigger bit)
    Posts
    933
    Blog Entries
    45
    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.
    Last edited by code_glitch; 09-05-2014 at 02:58 PM.
    I once tried to change the world. But they wouldn't give me the source code. Damned evil cunning.

Page 2 of 2 FirstFirst 12

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •