Care for an 80% solution?

[pitfiend]

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.

[masonwheeler]

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]

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]

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.