Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (517)
Games in Android Showcase (123)
games submitted by our members
Games in WIP (577)
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  
  Howdy ?  (Read 3172 times)
0 Members and 1 Guest are viewing this topic.
Offline Amos Wenger

Senior Duke




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


« Posted 2006-08-31 13:24:03 »

Hi, me again  Grin 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.

hawkwind seemed favorable to that :
Quote
Are you considering reworking the Xith project or starting something new friom scratch??
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.

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 ?

"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: 191
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #1 - Posted 2006-08-31 14:43:23 »

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! Smiley

Kev "finished one game ever" Glass

Offline Amos Wenger

Senior Duke




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


« Reply #2 - Posted 2006-08-31 18:23:00 »

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

"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 Marvin Fröhlich

Senior Duke




May the 4th, be with you...


« Reply #3 - Posted 2006-08-31 20:20:22 »

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 Wink.

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
Offline Amos Wenger

Senior Duke




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


« Reply #4 - Posted 2006-09-01 12:12:02 »

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 Wink.

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).
OK. If you have any problems/questions with Joomla!, just ask.

"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 William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #5 - Posted 2006-09-03 14:07:15 »

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

Will.

Offline hawkwind

Junior Duke




Java games rock!


« Reply #6 - Posted 2006-09-03 14:49:51 »

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.
Offline Marvin Fröhlich

Senior Duke




May the 4th, be with you...


« Reply #7 - Posted 2006-09-03 21:09:20 »

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.

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?

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.

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
Offline hawkwind

Junior Duke




Java games rock!


« Reply #8 - Posted 2006-09-04 00:56:25 »

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
Offline Amos Wenger

Senior Duke




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


« Reply #9 - Posted 2006-09-04 12:12:28 »

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

"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 Marvin Fröhlich

Senior Duke




May the 4th, be with you...


« Reply #10 - Posted 2006-09-04 13:07:24 »

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

Cool. Smiley

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

Junior Duke




Java games rock!


« Reply #11 - Posted 2006-09-04 19:34:53 »

How does joode compare with odejava??  Similar functionality??
Offline Marvin Fröhlich

Senior Duke




May the 4th, be with you...


« Reply #12 - Posted 2006-09-04 19:55:43 »

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

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.
Offline Amos Wenger

Senior Duke




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


« Reply #13 - Posted 2006-09-05 14:23:00 »

How does joode compare with odejava??  Similar functionality??
I think Qudus summed it up pretty well. Some parts have been rewritten (C++ version beyond understanding  Cheesy ) 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.

"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 Marvin Fröhlich

Senior Duke




May the 4th, be with you...


« Reply #14 - Posted 2006-09-05 16:29:42 »

@Qudus : yes they are several test cases.

Cool. Do you have a link to the demos? I couldn't find any on https://joode.dev.java.net/.
Offline Amos Wenger

Senior Duke




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


« Reply #15 - Posted 2006-09-06 13:53:38 »

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

"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.

TehJavaDev (34 views)
2014-10-27 03:28:38

TehJavaDev (27 views)
2014-10-27 03:27:51

DarkCart (41 views)
2014-10-26 19:37:11

Luminem (22 views)
2014-10-26 10:17:50

Luminem (27 views)
2014-10-26 10:14:04

theagentd (33 views)
2014-10-25 15:46:29

Longarmx (61 views)
2014-10-17 03:59:02

Norakomi (59 views)
2014-10-16 15:22:06

Norakomi (48 views)
2014-10-16 15:20:20

lcass (43 views)
2014-10-15 16:18:58
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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!