Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (109)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Not always reinventing the wheel - Concept  (Read 2096 times)
0 Members and 1 Guest are viewing this topic.
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Posted 2005-11-11 17:38:12 »

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


"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline kevglass

JGO Kernel


Medals: 122
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #1 - Posted 2005-11-11 19:09:09 »

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

<warning>Opinion based observations approaching</warning>

2) 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! (tm) 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 Smiley 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

Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #2 - Posted 2005-11-12 13:42:21 »

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

<warning>Opinion based observations approaching</warning>

2) 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! (tm) 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 Smiley 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..)

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline chaosdeathfish

Junior Member


Projects: 1



« Reply #3 - Posted 2005-11-14 21:00:54 »

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..
Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #4 - Posted 2005-11-15 00:18:43 »

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

Cas, i expect the money in the post tomorrow  Tongue

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #5 - Posted 2005-11-15 09:57:51 »

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..
It's just what I'm doing right now, I just wait having some more material to show..

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CogWheelz (18 views)
2014-07-30 21:08:39

Riven (25 views)
2014-07-29 18:09:19

Riven (15 views)
2014-07-29 18:08:52

Dwinin (12 views)
2014-07-29 10:59:34

E.R. Fleming (33 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (43 views)
2014-07-24 01:59:36

Riven (43 views)
2014-07-23 21:16:32

Riven (30 views)
2014-07-23 21:07:15

Riven (31 views)
2014-07-23 20:56:16
List of Learning Resources
by SilverTiger
2014-07-31 18:29:50

List of Learning Resources
by SilverTiger
2014-07-31 18:26:06

List of Learning Resources
by SilverTiger
2014-07-31 13:54:12

HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!