Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (492)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (556)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2 3
  ignore  |  Print  
  Community Space Trader technical detail  (Read 31230 times)
0 Members and 1 Guest are viewing this topic.
Offline SimonH
« Posted 2009-01-20 17:28:04 »

Ok, new tech thread to save clutter on the main thread.

Story so far: Physics looks to be pretty much under control, but we need to find the best solution for software rendering.

Suggestions so far;
1. Off the shelf: Pros: Tried and tested, easy(ish) to implement. Cons: Maybe too generalised or too bloated.
2. Custom renderer: Pros: bespoke visuals & specialFX, compact code. Cons: Technically difficult to do well, time consuming.

So how do we get the most bang for our bucks? Is raytracing the way to go?

EDIT: Title spelling corrected *ahem*

People make games and games make people
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #1 - Posted 2009-01-20 17:34:33 »

My vote is off the shelf ray-tracer (research needed). I think bloat can be managed with tools. If bloat is such a massive issue we can fork an external project.   

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
smith
Guest
« Reply #2 - Posted 2009-01-20 18:41:52 »

I think ray-tracing performance isn't quite there yet. May be a possibility by the time we are actually finished.

Note from the Quake3 Raytraced:
  # runs faster with more computers (about 20 fps@36 GHz in 512x512 with 4xFSAA)

512x512 20fps requires 36GHz!

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline kevglass

JGO Kernel


Medals: 159
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #3 - Posted 2009-01-20 18:55:12 »

JPCT is the best bet. No bloat, tried and tested and ready to go.

Kev

Offline moogie

JGO Knight


Medals: 12
Projects: 6
Exp: 10 years


Java games rock!


« Reply #4 - Posted 2009-01-20 21:11:37 »

I think ray-tracing performance isn't quite there yet.

true, however modern raytracers are a bit better, here is a game using a ray tracing engine I is playable on a laptop using a core 1.3 ghz cpu at lower resoultions.
Offline ShannonSmith
« Reply #5 - Posted 2009-01-20 22:10:43 »

I would like to put my hand up for working on the planetary body generation/rendering side of things. I spent quite a bit of time doing planetary rendering when I was working on this.

Maybe a vote is required but the options I see are:

Custom RayTraced
Custom Scanline
JPCT
LWJGL
Ardor3D/JME

I reckon it would be pretty cool to be one of the first big projects using Ardor3D.
Offline kevglass

JGO Kernel


Medals: 159
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #6 - Posted 2009-01-20 22:28:28 »

One of things that was part of the aim early on was providing a software only version of the game for casual players (i.e. no security pain dialog applets). LWJGL stop that, but of course we could have two versions of the client.

However, JPCT would give this abstraction of rendering without any effort. Should the focus be the game and not the renderer?

Kev

Offline moogie

JGO Knight


Medals: 12
Projects: 6
Exp: 10 years


Java games rock!


« Reply #7 - Posted 2009-01-20 23:01:08 »

yeah,

perhaps we should do the tried and true rendering and focus on game design and game play. As most 2d games show... if the game play is great, graphics can be not the best. e.g. Liero.

or if we abstract the render we can plug in different renders if some one wants to write a different 3d render... hehe someone could create a 3d ASCII render as a joke.
Offline SimonH
« Reply #8 - Posted 2009-01-21 01:22:30 »

Should the focus be the game and not the renderer?
Why do red sports cars sell x2 compared to black ones?
Of course the game is vital, but so is the look. Can't we have both? I'm kinda resigning myself to using jPCT as I know it well, it's free and it's stable, but I think at this early stage it's worth investigating the alternatives to see if we can't get that 'wow' factor. I want people impressed as soon as they see the game, when they've played it I want them to be REALLY impressed! If we aren't going for top-drawer then why bother at all?

People make games and games make people
Offline moogie

JGO Knight


Medals: 12
Projects: 6
Exp: 10 years


Java games rock!


« Reply #9 - Posted 2009-01-21 03:04:23 »

Perhaps we should have two parallel rendering development streams with one using jPCT to allow the development of the game and one experimental render stream.

The experimental render stream should only have minimal people assigned so that its development has no impact to the other aspects of the game.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline kevglass

JGO Kernel


Medals: 159
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #10 - Posted 2009-01-21 08:49:57 »

Quote
Why do red sports cars sell x2 compared to black ones?
Of course the game is vital, but so is the look.

Absolutely agreed, but that has very little to do with the renderer (since most renderers produce similar results intentionally, since thats what the player expects) and far more to do with the art content being consistant, professional and impressive.

Kev

Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #11 - Posted 2009-01-21 15:03:02 »

Quote
if we can't get that 'wow' factor.

What technical graphical features provide wow? Dynamic lighting (JCPT has)? Reflections (dunno)? particles (JCPT has).
While a space game is probably the best scenario for ray traceing,  I don't think there are any suitable off the shelf ray tracers. I think rolling our will be too large a task. Compare the features list of JCPT with rings http://j3d.sourceforge.net/, WE would have to fill that gap.

Yeah I totally agree that the gameplay and actual graphics is more important than the rendering technology. However, you can't code a thing until you know what form of data you will be working on. JCPT implies MD2 for example. I think JCPT is a great option if just for the turn on/turn off openGL acceleration. It seems to support *alot* of extra features we will need as well.

With rendering and physics decision made, a subset of functionality can be developed independently of thematic story (e.g. moving a ship around, shooting, crashing it into another and drawing it). Those operations are not trivial, particularly non-convex poly-poly collision checks. I'll have to split the polys into convex pieces no doubt. All my initial time will be swallowed by getting those tasks working correctly, so its better I get on with that ASAP. It doesn't matter with those tasks whether the game contains RPG stats or not. I need to know what model format the graphics will be in so I can ensure the physics ends loads the meshes correctly. I'll assume MD2.

Tom












Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline kevglass

JGO Kernel


Medals: 159
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #12 - Posted 2009-01-21 15:46:24 »

JPCT loads 3DS also I think, might make more sense for a space trader:

Quote
loads 3DS, MD2, ASC and XML files

Probably pretty easy to port one of the model loaders from another scenegraph if it becomes a problem.

Kev

Offline Jackal von ÖRF

Junior Member





« Reply #13 - Posted 2009-01-21 19:24:43 »

Would there be point in using voxel graphics?

Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #14 - Posted 2009-01-22 13:23:21 »

Dunno what voxel graphics are in the context of games. I have used them for medical imaging, but thats so you can take slices of objects.

3DS format you think is best. OK.

Yeah I am just thinking about collision stuff now. I have been going over the Bullet/JBullt JDK and yeah, its way better collision detection than ODE/JOODE. So with that in mind I am gonna seperate out the current collision library from JOODE (its kinda designed for that anyway) and plug in JBullets (which is also what the ODE community have done). Ooooooh sexy collision routines between smooth objects! That work will be done in JOODEs repository so I can just get on with that. ETA 2 weeks? (8 hours, maybe thats optimistic, I'll keep you updated on Sundays).

Tom


 




Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline SimonH
« Reply #15 - Posted 2009-01-22 15:20:39 »

Quick feasability test of JPCT.
NB JPCT also supports collision detection. For some strange reason the +Y axis goes down...

People make games and games make people
Offline Addictman

Senior Member


Medals: 3
Projects: 1


Java games rock!


« Reply #16 - Posted 2009-01-22 15:56:52 »

Nice test. Good work Smiley
Offline Jackal von ÖRF

Junior Member





« Reply #17 - Posted 2009-01-22 17:31:57 »

Dunno what voxel graphics are in the context of games. I have used them for medical imaging, but thats so you can take slices of objects.

For example Outcast used them for outdoor landscapes,  C&C: Tiberian Sun and Red Alert 2 used them for most vehicles, Crysis uses them for its terrain system (see this video at 4:30). Some more are mentioned here: http://en.wikipedia.org/wiki/Voxel#Computer_gaming

I don't know about the performance requirements or technical details of using voxels. I just know that not too many games use them, so they would at least be something different, whether in good or in bad.

Offline bienator

Senior Member




OutOfCoffeeException


« Reply #18 - Posted 2009-01-22 18:07:17 »

crysis uses voxels only in the terrain editing tool. The end result is a triangulated mesh of the voxel representation. Voxels are often used for destroyable terrain experiments but they make many things difficult compared to regular heightmaps (like texturing, some engines use only voxel coloring since realtime triangulation and texturing is expansive).

Outcast is the only game I know which used a voxel terrain engine at runtime. But AFAIR they had no terrain textures too only colored voxels.

anyway voxels would produce a unique look of the game, maybe its even a good decision to try something different.

Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #19 - Posted 2009-01-22 20:45:52 »

JCPT or whatever the acronym only supports poly - primitive tests. If it did support poly-poly (which it doesn't but few gfx engines do) it would only be convex convex polygons.

cool demo.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline dishmoth
« Reply #20 - Posted 2009-01-22 23:26:36 »

Yeah I am just thinking about collision stuff now. I have been going over the Bullet/JBullt JDK and yeah, its way better collision detection than ODE/JOODE. So with that in mind I am gonna seperate out the current collision library from JOODE (its kinda designed for that anyway) and plug in JBullets (which is also what the ODE community have done). Ooooooh sexy collision routines between smooth objects!

I know next to nothing about Physics Engines, hence the following question:  What are the advantages of using a Physics Engine in a space game?

Naively I'd assume that in a space game everything's so far apart and so fast moving that you could just use bounding spheres for collisions.  What sort of cool stuff am I missing?  Is there anything the Physics Engine allows you to do that could become the 'unique selling point' of this game?

Cheers,
Simon

Offline SimonH
« Reply #21 - Posted 2009-01-23 02:30:35 »

you could just use bounding spheres for collisions... What sort of cool stuff am I missing?
You're in a 10m fighter attacking a 1km long transport ship - you could be inside the transport's bounding sphere before you're even in effective laser range!

People make games and games make people
Offline Addictman

Senior Member


Medals: 3
Projects: 1


Java games rock!


« Reply #22 - Posted 2009-01-23 06:33:58 »

Duh, the transport ship got energy shields of course, which happens to be its bounding box.  Grin
Offline dishmoth
« Reply #23 - Posted 2009-01-23 08:31:23 »

You're in a 10m fighter attacking a 1km long transport ship - you could be inside the transport's bounding sphere before you're even in effective laser range!

Ah... Star Destroyers  Grin

Offline renanse

Junior Member




Intelligence is light to a dark world.


« Reply #24 - Posted 2009-01-23 14:29:35 »

I reckon it would be pretty cool to be one of the first big projects using Ardor3D.

Too late to be first (that would be either GeoCraft or NASA's Verve/Viz I guess.)  But "one of the first" as you say, is still available.  hehe Smiley  Sounds like jPCT is the choice already though, which should also be fun.

Renanse  (ruh-NON-say)
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #25 - Posted 2009-01-23 15:53:02 »

Quote
What are the advantages of using a Physics Engine in a space game?

If you think of a fighter like an x wing, then unless you support non-convex polygon intersections, the open space between the wings becomes occupied, and all lasers etc. hit it. As a player you would notice your lasers hitting open space when near missing shots against combat opponents.

Quote
Is there anything the Physics Engine allows you to do that could become the 'unique selling point' of this game?

There would be no unique selling point about supporting non-convex polygons, because every space sim supports them (actually I think the original elite ships were all convex including the space stations. Even so, elite did support convex polygon checks, nothing as crude as bounding boxes).

Still, physics engines are not really about collision checks, thats an annoying feature you need to get them to work. Its more about forces and stuff, but thats bits very straight forward for space sims (i.e. the complicated situations of calculating non-penetration and friction forces when 10 bodies are all touching
doesn't really occur).

We could add joints to our ships. But thats an unnecessary complication. We will have have to have turrets, but I think thats gonna be the only actuated component of a ship, and that does not need to be controlled at the dynamics level.

Quote
Naively I'd assume that in a space game everything is so far apart and so fast moving that you could just use bounding spheres for collisions.
In implementation you do do that. You first wrap up all your polygons in loose fitting spheres. So that you can quickly find out if two ships are defiantly not touching. (if they might be touching, go do the expensive poly-poly collision check)




 

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline dishmoth
« Reply #26 - Posted 2009-01-23 23:15:26 »

If you think of a fighter like an x wing, then unless you support non-convex polygon intersections, the open space between the wings becomes occupied, and all lasers etc. hit it. As a player you would notice your lasers hitting open space when near missing shots against combat opponents.
Agreed, lasers need accurate collision detection.  But that's a simple special case (raycasting), not by itself motivation for a physics engine.

Quote
Even so, elite did support convex polygon checks, nothing as crude as bounding boxes).
Hmm, I wonder if that's true...  I'd imagine that collisions with the player's ship would be modelled as a sphere-on-sphere since the player has no real sense of how big their ship is.  The only exception to that would be during docking with a space station, but that seems like a simple special case.  Lasers would be handled as above.  Missiles (targetting enemies, not the player) would be trickier, but there's a chance you could get away with just testing the tip of the missile against an approximating sphere for the enemy, or at worst the tip of the missile against the convex hull of the enemy.  I can't think of any other kinds of collision in Elite, but then it's many years since I played it.

Anyway, sorry, that was a bit of a digression. Roll Eyes This project isn't required to use 1980's technology, so if the code's there for non-convex poly-on-poly it might as well be used.

What about explosions?  Does the physics engine lend itself to making objects break apart in interesting ways?

Simon

Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #27 - Posted 2009-01-23 23:45:41 »

Quote
What about explosions?  Does the physics engine lend itself to making objects break apart in interesting ways?

Well only if there is a predetermined substructure to be broken down to. (e.g. configurable ships = deformable damage + less 3d graphics work  Roll Eyes). Of course havoc can generate the substructure dynamically, but they can afford to spend loads of time getting people to build materials libraries in order to make poly's break in a realistic fashion (thought in my opinion most of the deformable materials in the tech demo look pretty sh*t).

EDIT//
Quote
Agreed, lasers need accurate collision detection.  But that's a simple special case (raycasting), not by itself motivation for a physics engine.


Myeah, I would agree with you there if and only if inter-ship collisions never occurred out of first person and only between player and computer. Missile collisions could be implemented as (inaccurate) pre-impact explosions.   

I don't think we wanna go down that route though because you can't fly around DS9.




Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #28 - Posted 2009-01-25 23:39:32 »

Well I am working on getting JBullet to play with JOODE. I've put in my hours this week. I hope to get convex-convex tested and done by the end of Sunday next week. Oh wait, it might take a little longer because I'll have to write a new renderer binding. As the new JBullet stuff won't play with Xith anyway, I might as well write this one for JPCT.

I am doing this inside JOODE's svn repository in a separate subdirectory. (I have not committed anything yet so you can't see it, there is no point until it is working unless anyone states otherwise).

Err when we are ready to actually start the core code, might I suggest we make a convention that everybody sets up a root folder named anything, and have separate svn TRUNK checkouts with specific names for all the open source projects we are likely to integrate heavily with. Thus the main build.xml of the main project can operate knowing the other source folders are in sibling directories. i.e.
root folder SPACE_GAME_DEV (specific name irrelevant) has the following subdirectories:-
1 directory SPACE_GAME which is the snv checkout trunk of our project svn directory
2 directory JOODE which is the snv checkout trunk of JOODE
3 directory openMali which is the svn checkout of openMali
4 directory JPCT which is the svn checkout of JPCT

That way we can keep sync with other projects and even contribute bug fixes relatively easily. It does mean all devs will have to setup their root directory properly (but we do that surely?) as they won't be able to checkout the root directory. (PS this is just a workaround for not being able to nest svn repositories, correct me if there is a better way. This workaround will make branching the repository's difficult)

Tom









Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline SimonH
« Reply #29 - Posted 2009-01-26 01:10:31 »

Oh wait, it might take a little longer because I'll have to write a new renderer binding. As the new JBullet stuff won't play with Xith anyway, I might as well write this one for JPCT.

Cool, but don't lose sight of the objective, which is ease of use - a big problem is assets: If we encourage devs to use textured 3DS models we'll get massive asset issues: 'I've done a 2000 poly fully textured deathstar!' means: 'I've just raised the load time by 10 mins & made the renderer drop to 1 fps'. In software mode JPCT can't really go over 2000 textured polys total. Plus we'd need to manage the assets (versioning, server space &c). This is why I favour a procedural approach (eg, that JPCT test applet had no art assets).
A 2000 poly/frame world is very different from a 40000 poly/frame world - the physics and renderer need to be tight.

People make games and games make people
Pages: [1] 2 3
  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.

Nickropheliac (15 views)
2014-08-31 22:59:12

TehJavaDev (23 views)
2014-08-28 18:26:30

CopyableCougar4 (33 views)
2014-08-22 19:31:30

atombrot (41 views)
2014-08-19 09:29:53

Tekkerue (40 views)
2014-08-16 06:45:27

Tekkerue (35 views)
2014-08-16 06:22:17

Tekkerue (25 views)
2014-08-16 06:20:21

Tekkerue (37 views)
2014-08-16 06:12:11

Rayexar (72 views)
2014-08-11 02:49:23

BurntPizza (49 views)
2014-08-09 21:09:32
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

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

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!