Not always reinventing the wheel - Concept

Okay, it’s been a while since the first time I thought about it : What a wasting of time, everybody’s writing utilities, tools, libs for they own need, forgotting to :

  • reuse what have been already made
  • share their work in a generic and system-independant way
    So, one negative example :
  • how many OBJ loaders (in Java) have been written since OpenGL bindings for Java first appeared ? 2 for Xith, almost 1 for jME, I don’t know how many house-mades, 1 generic but not shared (see subject about OBJ loading in this section)
    And one positivie example (not Java, but a good ex.) :
  • Cal3D, the famous C++ character animation library is entirely generic, you can use it with OpenGL directly, or different SceneGraphs, or DirectX
    So here’s the situation as I see it, say, what is correctly “open & generic & shared”, and what is constantly rewritten :
  • ODEJava is independant from graphic system, this is good, we will do so with JOODE.
  • Vecmath is completely independant, but not maintained… and e.g. jME uses its own math library

  • Loaders for graphic file formats (OBJ, 3DS, MD2, MD3, MD5, OFF, COLLADA, and whatever you want…) are always dependant
  • Complex data structures, used to store e.g. Mesh(es) or Sample(s) are different for each system

As you may know, I started a project many months ago named Gamma, whose purpose was approximately (because not very well-defined) to “link” all best game libs together, so the average game programmer just need to mind about a unique system. This system proved not to be the best, and now I’m working on a slightly different concept :

  • The basic purpose is always to have as many features as possible (but a feature you don’t use shouldn’t slow the app) with extern libs why not, but based on a general “data system” that consist of a set of data classes (DInteger, DBoolean, DFloat, DVector3f, …) that is used to communicate between libs
  • The ultimate goal is to (re-)develop these libs entirely based on the data system for efficiency. This would avoid the “always converting data structs” problem.

This is a pretty ambitious project, and can be seen, in a way, as reinventing the wheel (one more time ! talking of the “re-develop libs” part), but I think if we succeed to organize the wh… oh, well maybe not the whole but the major part of the community and… :

  • All develop on the same basis : the data system
  • Make libs for pretty everything : Loading, Graphics, Behavioring, AI, Physics, Editing (<- generic and very customizable level editor e.g.), etc.
    … then it would be a great profit for all developers.
    What do you think about that ?
    Would you mind about contributing to a project like that ? What would you change ? What are the problems ? Why is it not already made ?
    Looking forward for answers,

BlueSky

  1. In principle I totally agree. Its a great ideal and one that we should strive towards.

Opinion based observations approaching

  1. Practicality-wise it doesn’t work (and it has been tried, plenty of times). Note, most of these are observations :-

a) Developers like to learn by doing, I for instance often rewrite things I’ve written before just to try it as different way - if its a hobby for you (rather than a business decision) you have more than the justification to do this.

b) Often people are in a hurry, they want it done now! ™ and that sometimes means sacrificing doing things in a data / view decoupled manner.

c) Now and again the solution tied to the renderer and/or platform is more efficient - and we all know how games developers are obsessed with performance.

d) Style/Convience/Correctness - there are lots of reusable components out there. Many of which would get used except they’re not written how the potential user would write them. Maybe the style of the API isn’t natural to them. Maybe the library is buggy. Maybe the developer just prefers to work with code that they implicitly understand since they wrote it. None of these things stop the developer technically using the library - but they slow people down - and thats enough to stop people using it.

e) Applicability - you can’t just assume that everything everywhere can be wrapped up into an reusable API that works out of the box. AI for instance is such a fuzzy area frameworks are notourious hard to build and make useful. Editing agreed - infact I’m working on an Eclipse plugin for tilemaps as we speak - however generic editors tend to be cumbersome.

The end of the day the things that become libraries that are useful has to be sufficinet complex to justify it. For instance, model loaders. OBJ infact is a great example. If you’ve already got a rendering method (be in Java2D, DirectX, Scenegraph or OpenGL) writing the loader for the pure data and rendering is trivial. “So!?” you say “you could still reuse it!” - well yes you could, or you could spend a couple hours writing your own that you know works, know the code to fix it and feel the API is comfortable to use.

All of that said, I’d applaud any effort in this direction :slight_smile: If you manage to get enough agreement on enough areas you could have a great goer on your hands. As I said, I’m working on some editing tools at the moment.

Kev

Structured answer :

  1. Okay, I think many people think so, they just aren’t ready to do so.

  2. Oh, yes maybe, but it’s a risk to be taken, isn’t it ?

a) How true it is, I precisely have rewritten Gamma 4 or 5 times since I first started it… However, rewritting certain parts of these “shared libraries” couldn’t have a negative effect…

b) It’s also true, and I already had a thought about that : one can do his game in a completely specific way, and then when all is working, either he or other motivated people can split the “generic” and “specific” parts of his work. If we follow this way, we will arrive at a point where there is no longer generic part in everybody’s work (excepted new techonologies) and, say, it will look like good news.

c) Performances are a lesser and lesser important problem, as the harware evolves… but it’s true anyway. So for example with an OBJ loader, there is a generic data structure that can be converted when the model loads and then it’s fully optimized because in the native format of the SG. For animations it’s a little bit harder, because we have to update data each frame (and compute inter-frames…), we should implement things in the SG/renderer itself, so it’s using directly the generic structure.

d) Oh, here’s a problem I can’t fix… I can’t tell other programmers how they should do (in fact, I should find for myself how to do that…)

e) It’s sure you always have specific parts in a game, and for generic AI is maybe no the better example, I agree… And for Editing I have some great ideas just waiting to be re-implemented. I didn’t thought exactly of a “generic level editor” but of a “set of components you can use to easily build your own level editor”, you see ?

Seeing the numbers of answers to my post… I don’t think I will gain much support soon, so what I have to do is go, go, go and program as much as I can, and to prove my approach is the better… (could be the worst too…)

I agree with what Kev said - I was going to write a reply but didn’t have time.

Why not write the framework yourself, and flesh it out over time? You might get more interest if you’ve got something concrete to show people…

SPGL is a proof of concept…written over time and fleshed out…

Cas, i expect the money in the post tomorrow :stuck_out_tongue:

It’s just what I’m doing right now, I just wait having some more material to show…