Howdy ?

Engines, Libraries and Tools Xith3D Forums
#1

Hi, me again ;D OK I’m know I’m painful but really I have to get your opinion here.

I have an ambitious project and I just can’t afford a graphic lib switching. So no jME-Java3D-Xith3D flame here please. I’m gonna finish my game with Xith3D, or stop programming. (Huh, maybe not ^^).

I’m just getting abit tired of this codebase… just can’t change a single thing without getting weeks of debates on this forum… and that’s just natural but annoying.

I can understand users need backward compatibility : always changing one’s code to conform to the latest changes is not comfortable. But on another hand, we do need sometime to change a bit the architecture for design reasons… This seems to me almost impossible to do with Xith3D.

As I said to Qudus,

[quote]I’d really like to have a library which I’m an owner and I can change whatever for design reasons. An SVN project where we would be working together (for our game projects) would be just fine to me. No wide phantom user base, no compatibility issues (we just have to state that you can’t complain if you use that) and no crappy half-buggy forgotten code somwhere in the hidden repository.
[/quote]
hawkwind seemed favorable to that :

[quote]Are you considering reworking the Xith project or starting something new friom scratch??
[/quote]
Well, working from scratch is not what I like the most… I’m not a software engineer… But just keeping the global architecture of Xith3D but arranging abit the API just to be more convenient sounded good to me.

But, voice of reason then talked (WillDenniss) :

[quote]Amos, regarding your comment - I would suggest not forking Xith3D. You can gain valuable experiance (and exposure) by maintaining a public API and helping its userbase. Sure it’s easier when you’re not answerable to other users of your API, but unless you plan never to work in a larger group it’s worthwhile to get experiance with this. Also, a public API can have new people contributing new ideas and work which you can benifit from if you’re still using it.
[/quote]
Now what to do ? Will I agree about experience and whatever else but hey there’s a moment you should say wait wait I’m doing what I’m thinking about, come back in one month or you can’t work ? Don’t you think so ? Some things are definitely good for gaming but are not backward compatible so I’m/we’re obliged to fork… Hey that’s sad but unless users are willing to provide a huge effort of following API evolutions I don’t see how this can’t be done…

What’d you think ?

#2

Pick a code base (Xith or Java3D or JME, makes no odds really) and stick to it. If you can’t afford to be graphic lib switching you certainly can’t afford to try to be maintaining and updating the graphics lib while writing your game.

If you want to finish the game - focus on the game - and not Xith3D, JOODE or introducing new projects. If you have a problem relating to your game with the engine, raise the issue and then work round it in your game until you can afford the time to come back and contribute. If you’re already comfortable with Xith, stick with that since you’re more likely to know how to work round issues.

As a side issue, once you have a “nearly” full game written using the rendering layer, and you’ve worked around any issues you might have found, you’ll be in a much better position to fix the issues you’ve seen - since you’ll have real life use cases to show the problems and justify your solutions.

If you want to finish your game - you need to focus on your game! :slight_smile:

Kev “finished one game ever” Glass

#3

Thanks kev, great advice :slight_smile: So if I want to be reasonable my clean-APIs dreams will have to wait :smiley:

#4

Sometimes I think we really need to fork to get a really clean API. But I believe it can be done in xith, too, which would be of much more value (see Will’s reasons which I totally agree with)

We definitely need a more or less complete list of people who’re using xith. Then we should make a plan what should be cleaned up and what it would mean for these people. Most changes will probably be refactorings which can be solved by eclipse 3.2 (recoreded refactorings). So the users won’t have too much trouble with it. Since very most people seem to use eclipse, this should be possible. Then we need some speed ups to not be the slowest API in the world ;).

I think this would do the trick well enough.

Next week I’ll start to do some things on xith.org including an updated list of features and a plan for the future with milestone points or something like that so that we can get a view of what must be done (till 1.0 or so).

Marvin

#5

OK. If you have any problems/questions with Joomla!, just ask.

#6

Kev’s advise is good. It can be easy to lose focus on actually creating games…

Will.

#7

This is a GREAST TRUTH. My game is using a back dated Xith version because I had a truely difficult time tracking the engine and tracking my own development. My version of Xith has an actual working collision system from the early releases. I know this died somewhere along the way.

I purposely choose to “stay with Xith release X” so when I did upgrade it would be easier to determine where I was to tighly coupled…these are the places that will required additional coding to sync up with the current version. The magnitude of rework will tell me whether or not I have adequately abstracted things or not…

It is hard to narrow down your focus when your just a brimming with ideas. My first major effort was a civilization clone using genetic algo’s for civilization and a Xith based landscape engine…man it was a beutiful map, rivers, convulted terrain, choke point to insure there were map location of great value for civilization competion, I research cultural development, warfare etc. Examined numerous landscape alog’s. After a year of period development…I had nothing…pretty landscape and many partial ides…painful.

I think the best approach is to stick with your game, abstract design so you can insert new features or Xith improvements. Release a version, keeping in mind what you want to do next and then enhance Xith in between functionality improvements to support future capabilities.

#8

Maybe we should scrap the collision system and write an abstraction layer for physics engines and an implementation of it linking joode with xith. Unfortunately I don’t have too much knowledge of physics engines. So I cannot do it without investing very much time. Amos, you’re one of the joode developers, aren’t you? Could you do that? Working physics is an important point on the (coming) development plan which is desperately missing in xith.

Since the collision system is broken and nobody uses/can use it in the current state and since it was always very basic and could only be used for simple games there’s no reason keeping it while there’re such nice things out there like joode. Am I right?

Certainly it is due to my unsufficient english knowledge, but I don’t really understand, what you want to say. Could you please explain it in other words?

Marvin

#9

My english bites and its my native tongue. Basically the advice i got when i first started working was “you eat an apple one bite at a time.” Instead of driving continuous Xith changes be sure to spend some caring and feeding your own game/project. Periodically update Xith to support a specific need of your project. Wandering from UI to Physics to cleaning up APIs may be spreading oneself to thin. This is in no way a critisism just my general approach

#10

Qudus, joode devs (I don’t work actively on it anymore) uses Xith3D for testing so no need to link or somewhat else… it’s already plain functional

#11

[quote="<MagicSpark.org [ BlueSky ]>,post:10,topic:28227"]
Qudus, joode devs (I don’t work actively on it anymore) uses Xith3D for testing so no need to link or somewhat else… it’s already plain functional
[/quote]
Cool. :slight_smile:

Are there any test cases out there to demonstrate the thing?

#12

How does joode compare with odejava?? Similar functionality??

#13

It was planned to be a pure java implementation on ode (a port). But as far as I read the forums it has become more java style. But it is comparable in functionality. Of course it is not complete and stil in an early state.

#14

I think Qudus summed it up pretty well. Some parts have been rewritten (C++ version beyond understanding :smiley: ) to be clearer, either more efficient. Some parts are new (not present in ODE). Sources are pretty clean, you may take a look at it ^^

@Qudus : yes they are several test cases.

#15

[quote="<MagicSpark.org [ BlueSky ]>,post:14,topic:28227"]
@Qudus : yes they are several test cases.
[/quote]
Cool. Do you have a link to the demos? I couldn’t find any on https://joode.dev.java.net/.

#16

Maybe because they’re on Sourceforge ;D (dev.java.net has been dropped a few months ago).
http://joode.sourceforge.net/