Also keep in mind that it is very probable that your self-written physics and graphics engine cannot compete with libraries that have been debugged and optimized over years, maybe even developped by large teams.
True. Indeed I'm very sure that the physics which have been recently added to FlexWorld are not as complete as other generalized physics libraries. But the question is: What does the game need?
Like said previously, the initial attempt to add physics was to keep things really simple. We don't plan to have ragdolls, fancy explosions (in terms of physics) or other physics gimmicks that other libraries provide. The reason why we ended up with real-world physics laws is simplicity and authenticity: It's easier to use well-known equations than trying to "fake" motions.
Even if an external library doesn't directly integrate to your project, you can encapsulate it behind your own interfaces.
Yes, and the new component system will always allow to do it in the future, even quite simple. Entities have properties that indirectly define their behaviour, and controllers decide what exactly happens. Whether we use our own controllers or hack in wrappers to other libraries doesn't really matter. I really tend to keep myself the doors open.
Of course it may be fun to do things on your own, but especially for a project like FlexWorld that is going to grow continuously, it is wise to have a solid code base that scales with the application size. Or at least to implement physics and graphics in a modular way, so that an other framework could be employed with small effort.
I played around with graphics engines in the past years a lot, especially Irrlicht (Ogre 3D always was a pain to build for me, at least in Linux). To be honest I didn't like the code design and the way of doing things. This is pure personal taste, and maybe I haven't digged deep enough to be proven otherwise, but that's what I came up with.
On the other side I really love programming, and I tend to know what happens, especially for things that highly impact performance and features. For example if an external 3D engine is missing a needed feature, I have to add it, which means that I also have to learn about the engine: How can it be changed to support my feature? What are the coding guidelines? Do my changes interfere with anything? That takes time, just like writing your own libraries does.
A good and recent example is the GUI library we use in FlexWorld: Initially it was SFGUI, then we switched to libRocket because SFGUI was lacking a lot of features that we needed and we didn't want to spend too much time and effort into maturing SFGUI, to match our needs. libRocket looked nice and provided everything we needed. Then the day came when all the code changes were merged into the master line and our continuous integration service tried to compile it on Windows. Of course, it failed.
We had to apply a lot of workarounds in our own code and some patches in libRocket, just to make it work. We found "_asm {}" blocks and other nasty things. Things nobody talked about, neither on the forums nor somewhere else. We assumed libRocket is of a good quality because we trusted what users said about it.
libRocket is still being used today, but we're already looking out for SFGUI again, because we know how it works, we know how to fix/enhance it and we know that whenever something stupid happens, we will be able to solve the problems.
That's why I'm afraid of relying on 3rd party libraries too much: It requires you to give away control to a certain degree and to hope that everything will go fine. If it does not, the only thing you can hope is that the library is written in proper source code and it will be easy to fix the bug or enhance the library to support a new feature. And to be honest, we already have a shitload of external dependencies, like Boost (utils, ASIO, functional...), Assimp, SFML, Diluculum and many others.
And last, but not least: You are fully right that our own libraries (both graphics and physics) are not as feature-complete as other matured and popular ones, but the assumption that it may be buggy (because it's new and not well tested by many others) is not valid. We're strictly following test-driven development in the development flow, which also applies to those sub-systems. So at least we can give a very high percental value of "Bugfree".
(except in the client, which is not being unittested but mainly acceptance-test-driven -- yeah yeah, it's a big mistake and we *will* change that
)
Okay, this reply got quite long, but I'd like to thank you for your reply, Nexus. It at least forces us to (re)think about several things, something that's always needed to improve. So, thanks!
