*Experienced* Java 3D programmer needed

Business and Project Management Discussions Jobs and Resumes
#1

I’m in need of an experienced J3D programmer for contract work on a game prototype. This is a paid contract position with the possibility of moving to full-time.

The location is Austin, TX, but remote work is possible. The game is an unannounced next-gen (non-fantasy, non-science fiction) MMP game.

In terms of experience, this position requires several years industrial experience with Java, strong software engineering skills, and the ability to demonstrate complete familiarity with Java 3D.

If interested, please contact me at j o b s [at] onlinealchemy.com (obfuscated to try to defeat online spiders :slight_smile: ). Please include a resume (text, Word, or PDF) and if possible pointers to online examples of your java and J3D work.

Thanks.

#2

Curious…
Why did you choose J3D as opposed to one of the other alternatives such as jGL. Java3D is kind of brutal when it comes to game development. There are much better alternatives I think. Again, just curious.

#3

I’m looking at J3D mostly based on the recommendations of Java people whom I respect – and, as much as I hate to admit this, ignorance. I’m not familiar with jGL, but know of and a bit about J3D.

If you have pointers to this or other viable, industrial alternative solutions, please feel free to post them here or email to me.

FWIW, the current prototype is written in Java 1.3 on top of a fairly heavily modified beanshell, which gives us both compiled and interpreted capabilities – this is what I’m looking to graft a quasi-3D client onto.

#4

This has been discussed here some times. Actually there are NO alternatives. All other API around are merely pure rendering APIs, no 3D engines.

Brutal?

But I’d really be interested in better alternatives as well.

#5

No alternatives? Well, you could write a complete scene graph on top of jGL bespoke, hell how long could that take huh? :wink:

I think Zane is refering to relatively simple 3d games. As soon as you hit anything non-trivial with a planned life time of more than a few months then Java3D really is the option to aim at…

Kev

#6

Not if there’s money at stake you don’t. As a company director with technical savvy I’d veto the use of Java 3D based on its track record alone and keep the scenegraph in-house. It’s risky enough using Java right now if you don’t know what you’re doing. Expect a world of pain.

Cas :slight_smile:

#7

[quote]Not if there’s money at stake you don’t. As a company director with technical savvy I’d veto the use of Java 3D based on its track record alone and keep the scenegraph in-house.
[/quote]
I wouldn’t make sweeping statements like this without a better understanding of what type of game they’re making. Right now, all we know is that it’s Java, 3D, and not SciFi or Fantasy. That leaves a huge field open for what it might be. Now if it’s an arcade style game, I’d agree with you. If it’s an RPG like Final Fantasy, then Java3D may be a better choice.

Remember Cas, technology is only one piece of the puzzle. Time to market and ease of development are also large factors. :slight_smile:

#8

I think it’s the juxtaposition of the words “game” and “Java3D” that have me worried, not the kind of game they’re making.

Here’s some of the business risks:

  1. Bugs you can’t fix or workaround. You really can’t. There’s nothing you can do to fix a J3D bug. At all.
  2. Experienced Java3D programmers are even rarer than experienced Java programmers.
  3. The performance of the end product will almost certainly be unacceptable on the majority of machines in existence today. Now before you try and tell me Java3D is fast, I know it’s pretty fast - for a generic scenegraph renderer, with a shitload of RAM, on a half-decent CPU. Rather unlike the majority of paying punters’ machines.

Spending a few months writing your own specialised scenegraph on top of a more widely understood rendering APU will:

  1. Allow you to fix and workaround bugs
  2. Allow you to buy in the talents of experienced OpenGL or DirectX programmers, of which there are far more than Java3D programmers
  3. Allow you to write a scenegraph system that fits nicely within the constraints of your target market systems, which, if you want to make any money, will have to cope with a 32Mb machine and a TNT with a 400Mhz processor or so. Which you will find a Java3D application… doesn’t.

Furthermore if you’re hoping to make a downloadable demo of the game I’d pretty much forget it as the 99% of users without broadband are going to find it pretty cheesy waiting for a 10MB JRE, and then having to wait for a 10MB scenegraph engine, and then having to wait for your demo to download.

Cas :slight_smile:

#9

But Cas, you wouldn’t be slightly bias here would you? ::slight_smile:

Kev

#10

Oh, I won’t argue that there are a lot of advantages to the do it yourself route. Personally, that would be my preference as well. However, businesses need cash flows and if the circumstances are right (i.e. A shrink-wrapped game that with non-realtime gameplay) the tradeoffs may be worth it.

[quote]Allow you to buy in the talents of experienced OpenGL or DirectX programmers, of which there are far more than Java3D programmers
[/quote]
This is true. Experienced J3D programmers are few and far between. It’s not like J3D is hard to pick up for a 3D programmer tho. It’s just another scenegraph.

[quote] 3) Allow you to write a scenegraph system that fits nicely within the constraints of your target market systems, which, if you want to make any money, will have to cope with a 32Mb machine and a TNT with a 400Mhz processor or so. Which you will find a Java3D application… doesn’t.
[/quote]
Again, this depends on the market. The current mainstream system targets are 700Mhz machines with 128MB of RAM and a GeForce2MX. This of course, targets the serious game player (12-28 yr old range) and not the casual gamer who really uses their systems for Word Processing and Email.

#11

It also depends on the type of game and if you are trying to show lots of little animations, etc, or if you are trying to visualize a lot of information in a slower-paced fashion.

It also makes a difference what the game asset pipeline is, and whether you have enough programmers to write all the tools that you would need to support non-programmers using your custom scenegraph API (model loaders, etc).

Java3D, despite some flaws, still has a lot going for it in addition to the API. There’s overlay systems, particle systems, loaders, etc. that have been created by third-parties. You would have to create all this stuff in-house if you had your own scenegraph system.

#12

Interesting discussion guys. FWIW, the work I need done is for a game prototype as I said in my first message, so a lot of what’s been said doesn’t entirely apply. We’re using Java right now because it is a good “get things done” language, with a lower cost and faster ramp-up (in my experience) than C++. Whether we’ll stick with this past a “first playable” is an entirely different question. That is when the questions of buy-vs-build, time to market, engineering availability, art pipeline, target machine capabilities, etc. come directly into play. There’s a lot of things I really like about using Java for client-server game development, but I won’t know about the 3D part of the puzzle until we actually try it – or any other available solutions that would come more highly recommended.

#13

Simply usingj3d is simple enough for the most part. Actually milking good performance and using it correctly is much more difficult. Coupled with the fact that theres very little info on correct use, even from Sun itself.

A prototype on the other hand, is something its perfectly suited for. And if the performance happens to be good enough, or tweakable to be acceptable then thats an added bonus :slight_smile:

#14

One thing to consider is whether Java3D has to interact with other APIs in your application. Does the prototype need to play cutscenes or other video clips with JMF? In that case, my experience tells me that you will run into a lot of trouble using sound in your 3D-application.

Java3D seems to work ok on its own, but its built-in sound API does not play well with other APIs such as JMF and its multi-threaded rendering API does not seem to play well with other sound APIs (including JMF and Java Sound). This means that you might not be able to get around the sound problem by just replacing Sun’s sound APIs with your own custom API without having problems with your Java3D graphics rendering, unless you write that API to work well with Java3Ds multi-threaded architecture.

This is just my experience with the API though, but it might be something to consider when deciding whether to use Java3D for your prototype, do you need it to interact with other media APIs than Java3D?

#15

ahem http://www.magicosm.net/

They may not be shipping, but I think they demoed last year at Java One… so they obviously have a Java3D game engine working to some degree.

I’ll be the first to admit that I haven’t done anything serious with Java3D or OpenGL… but my first instinct for the type of game described would be to try Java3D first. I base that mainly on the scrren shots of Magicosm and what I have read about it, along with some ancient rumours of games made be Fullsail (first-person shooter and F1 racer) that have only been seen be a select few, sadly.

#16

The lack of games developed to a full scale in Java3D might be to do with something Cas (?) brought up earlier… the lack of experienced Java 3D programmers…

But then, I suppose you could compare that to the speed of take up of OpenGL when the majority of programmers knew how to write their own engines and didn’t know anything about GL…

Kev

#17

Now, I have nothing but respect for the Magicosm guys for doing what they’ve done and persevering for years with J3D to get where they are today.

But I have to very painfully point out that on my own I managed to come up with a terrain renderer inside two months that’s still unbeaten in terms of speed and beauty and features. It took me about a month to write a complete windowed GUI system with a full complement of standard widgets. My particle system took, ooh, about a week.

Now it might sound like I’m just telling you all how brilliant I am but a quick reality check tells me that I’m a very normal programmer. The terrain demo was the first 3d application I ever wrote in my life and it wasn’t quite so hard as people like to think. Alien Flux is my first game and it’s only taken 7 months of coding on my own. And I’ll say it again: I’m not a genius, I’m just hardworking and diligent. Actually I’m not even hardworking - I spend all my bloody time posting on these forums and avoiding work at all costs.

So where’s all these advantages in Java3D? Really? Are they just repeated parrot-like? It’s the same old “somebody’s written library X therefore you are mad to try doing it yourself, you’re wasting so much time” - followed 6 months later by “we used library X but spend a year figuring it out and a year working round performance problems and trying to make it do what we want” and at the end of the day all you’ve got is a prototype that you have to scrap! I’d have a finished game out by then!

Sigh. Rant over.

Cas :slight_smile:

#18

I agree with Cas that it probably pays off in really long run to use another API than Java3D for big projects, because of the immaturities in that API right now. However, Java3D is great for prototypes and applications that need to be built on a tight schedule. LWJGL and GL4Java are often not alternatives for such applications since just implementing basic functionality, like model loaders, tend to take longer than the project’s allocated time.

I spent nine weeks on building my project Nevermore and most of that time went into constructing the physical interface, modeling the world in Maya, writing and recording cutscenes and dialogue. I think the benefit of using Java3D is clear when one considers that it took me at most two weeks of full time work to build the whole software application while Cas worked two months (maybe that amounts to two weeks of full time work too?) on just implementing a terrain renderer (albeit a fast one).

What you really need to do when selecting the API is to have a good idea of what the requirements of your application are. If top-performance on minimal hardware is a priority, then clearly Java3D is not the best choice. If you need really quick development and you just need it to run ok on typical developer hardware, then it might be (especially if you don’t need to do certain problematic API mixes, like JMF/JavaSound and Java3D rendering).

#19

Cas: Just curious, but how many hours a week do you spend on Alien Flux?

#20

60-80-odd right now. But that’s my fault for getting released at JavaOne. I wasn’t planning on being ready until the end of the month; suddenly our deadline’s 3 weeks sooner.

We’re in that “last 10%” of the project which takes the 90% of the time.

Cas :slight_smile: