I have spent my 4 hours today working out how to compress libraries. We are gonna have to choose a renderer and other libs, and one selection criteria people have all ready mentioned is bloat. Anyway, I thought there should be a way of trimming libraries based on the subset of functionality you were actually using. I kinda expected that to be a pretty done deal, but as it turns out IBM's JAX was the only real contender and that has been moved from alphaworks to websphere and you can't download it anymore. I found this cool academic library http://www.cs.purdue.edu/homes/hosking/bloat/ and have been trying to work out if I can configure it to trim methods and classes that are unnecessary. To cut a long story short YES YOU CAN! I have successfully removed redundant methods from a program and ran the remaining mess to get the same output. Its far to early to say anything about the robustness or scalability of the methodology, but I think I should defiantly try and wrap up what I am trying to achieve in an ANT task. As such a tool has plenty of uses I'll give it its own project on google code or something. That is unless anyone knows a (free) library that all ready does this functionality (please please speak up so I don't waste time, I'll cross post in Tools discussion).

Tom

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

I like as well, however I would like to push the date of the disaster to further in the future? that way technology is sufficently advanced to believe that mankind was able to escape the planet. This would also mean that "relics" of the "first golden age" can be found through out the universe.. (e.g power ups, missions/quests, etc)

What model format? Content authors will need to be able to define the visuals. define the stats of ship/stations (inc. weapon points, engine locations). Oh I suppose if this framework is really reflection heavy then it can all be done procedurally in the concrete ship subclasses... in which case we just need to decide what the engine makes an effort to support. Still, choice of renderer is a massive open decision.

Tom

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

Galactic map. How are players planets and stations gonna get on the map with the relevant info? Does the player know the relevant info at the beginning.Does the player know all locations in the galaxy at the beginning? Is the galactic map fixed, or can events change it? Can the player annotate it?(Personal opinion: let loaded code modify the map. Use this functionality to open and close parts of the galaxy as part of questing. We need to ensure querying high level stats of space stations and ships does not force us to load the graphics. StationFactory and ShipFactory are what contributors actually write and are the entry points for dynamic loading. I would prefer it if the player got all useful information onto the galactic map as they learn it. e.g. trade information gets added for a space station as soon as the player lands on the station or scans it with a trade scanner, but this could be too fidly).

Could we use the player plotting a hyperspace destination as a cue for loading graphics?

Nervous thoughts on implementation;The data should be simple enough (x,y,z dx,dy,dz) if the game is zoned (ie not too much data per zone), the critical bit here is rendering!JPCT is a brilliant engine but I suspect it's too generalised for what's required here, it's not good at rapidly changing data and not very well geared up for procedural textures (argue with me Egon! You know I want to use it!). I think the join between the Renderer and the Physics needs to be pretty tight. In an ideal scenario the phys could avoid a lot of duplicated calculation by feeding render with 'easy' data.

Train of thought: Objects are in an octree. The Phys moves all objects, checks collisions and feeds 'ticked' objects with proximity lists for the AI. It also feeds the renderer with a culled list, maybe not as tight as individual polys (but the phys will need these for collision checks anyway) but pretty tight. The renderer would then need to call the relevant objects with a getColour(textureID, u, v) call if procedural textures are used. Certainly with software rendering there won't be CPU enough to feed both phys & render with raw data.Speculative question: Can we build a Physrenderer? Code which can take raw model data, move it and render it in one fell swoop?

Galactic map. How are players planets and stations gonna get on the map with the relevant info? Does the player know the relevant info at the beginning.Does the player know all locations in the galaxy at the beginning?

We could say that the player ships are outfittet with some kind of communication device that could pick up on short range broadcasts.There's bound to be individual requirements here, but lets take a zone that's a "public / open / well known". Upon the player's first time arrival in a zone,the "capital" planet could for instance broadcast information about the zone, which will pop up in player's ship hud to read, and will afterwards store itselfin the galactic map.

The same galactic map could perhaps allow personal notes as well, so that more "explore for treasure" zones that do not broadcast this "Welcome to our zone, this is our menu ..." remains forgotten until the player makes his own note about it in the map.

The date 20th May 2012 was simply picked because 2012 is prophecized to be when armageddon comes, according to nostradamus, the mayans, etc.

How about something more original, for example:

On 19 January 2038 there were still some legacy 32-bit UNIX systems in use. One of these was a chemical research plant on Earth's orbit. The administrators had though, that since nothing too bad happened on year 2000, the year 2038 would neither cause problems. But that day, at 03:14:07 UTC, the engines of the plant's rocket engines went haywire. As the plant fell into Earth's atmosphere, the chemicals were burning and forming dangerous compounds. The fumes spread over the clouds and eventually fell on earth with rain. The chemicals disturbed the function of chloroplasts so that the photosynthesis of Earth's vegetation worked at only 20% efficiency. There came to be too much CO2 and living things began to die away. Those people living in rich countries were able to use devices producing oxygen artificially, but even then it was clear that they would need to leave the planet within 30-50 years, because the fumes in the air were preventing human reproduction. It would take some over 300 years for Earth's ecosystem to fix itself, so the human population would need to find a way to survive the next couple of hundred years away from their home planet.

how about they finally turn on the large hadron collider and promptly cause 7 parallel universes and earths to share the same space/time. The earth now with 42 billion people to feed, let alone 7 versions of everyone getting fed up with each other, lead to the exodus from earth to eventually found separate civilizations and only now has contact of been re-established between 6 of these civilizations.

Sure i am not a good story writer, but some interesting concepts can be made from this idea. e.g. each parallel universe is slightly different ( space steam punk , N.A.Z.Is IN SPACE, buddist ruled... you get the idea.

In an ideal scenario the phys could avoid a lot of duplicated calculation by feeding render with 'easy' data.

Train of thought: Objects are in an octree. The Phys moves all objects, checks collisions and feeds 'ticked' objects with proximity lists for the AI. It also feeds the renderer with a culled list, maybe not as tight as individual polys (but the phys will need these for collision checks anyway) but pretty tight. The renderer would then need to call the relevant objects with a getColour(textureID, u, v) call if procedural textures are used. Certainly with software rendering there won't be CPU enough to feed both phys & render with raw data.Speculative question: Can we build a Physrenderer? Code which can take raw model data, move it and render it in one fell swoop?

Hmmm. I am not sure. Most of the time during play, poly-poly collision is not neccissary becuase very few near collisions actually occur (except docked ships = turn off check). Every rendering frame though, a subset of ships / parts of ships need to be selected based on the user's camera position. So you need fast approximate fustum culling added to the post collision pipeline. This results in a list of ship posisions within the camera angle BUT probably not their mesh ordinates in absolute space because the collision checks probably didn't calculate them. Even when the poly-poly collision check runs it only checks a subset of all the mesh ordinates. The physics engine uses mesh data totally different to how the gfx does. So all you save is the memory, not calculations except in very rare circumstances. I say get a renderer off the self. There must be an almost infinite scope for us to slow down graphics processing through a custom implementation. e.g. bad fustrum culling, inability to split meshes up according to fustrum, innefficient checking the polygon is facing toward the camera etc.

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

How about something more original, for example:On 19 January 2038 there were still some legacy 32-bit UNIX systems in use. One of these was a chemical research plant on Earth's orbit....

More realistic scenario: ...The system administrator intern of one of the largest orbital research plants caused a extraordinary long STW garbage collection in the main flight control computers zetabyte file system. He used an arcane 32bit browser draggable java plugin for remote debuging on his yPhone? which caused a buffer overflow in the ultra low pause "garbage first" garbage collector. The emergency system (don't panic MARK II) initiated a course correction to the last known maintenance safe point: CERN the current location of the system administrator intern. The last known log message on the interns yPhone? was "Full GC: promotion failed" short before the research satellite crashed directly into

the large hadron collider and promptly cause 7 parallel universes and earths to share the same space/time.

6 of 7 of all incarnations of the company "Orange" (TM in parallel universe 1) released almost immediate after "the day on which the intern died" security updates for all 32 bit draggable java plugins right before all 32bit systems where prohibited by law...

I say get a renderer off the self. There must be an almost infinite scope for us to slow down graphics processing through a custom implementation. e.g. bad fustrum culling, inability to split meshes up according to fustrum, innefficient checking the polygon is facing toward the camera etc.

I'm not convinced... Frustrum culling et al are all well-known and fairly simple operations (+no far plane!). We surely have the talent to write an efficient software renderer tailored to the specific scenario of space, don't we?After all, if we want to impress people we need to impress them. The game's got to look amazing in software rendered - and that's a problem we got to solve...

Depending on the target view port size a real time ray tracing render is probably viable for web resolutions.

With a real time ray tracer it is pretty easy to implement impressive features without adding much complexity and since such a render's embarrassingly parallel nature it can easily use the extra horse power of multicore processers.

I like the LHC idea, the game could be called something bold like "The Higgs Boson". Keep the creative stuff going its cool.

Quote

I'm not convinced... Frustrum culling et al are all well-known and fairly Roll Eyes simple operations (+no far plane!). We surely have the talent to write an efficient software renderer tailored to the specific scenario of space, don't we?After all, if we want to impress people we need to impress them. The game's got to look amazing in software rendered - and that's a problem we got to solve...

We might have the talent but we might not have the time or the patience of the commitment.

Anyway, all I was saying is that you don't gain much in calculation times by linking the renderer with the physics because poly-poly collision checks use a subset of mesh points which will almost 99% of the time will not be the same mesh points you need to render. You havn't negated that point.

Whether we build a tailored software renderer or find one is a different decision. What we lose in 0.5% of performance by not having the physics strongly linked to to the renderer we gain by all the time another group have people have spent optimizing their gfx engine (hopefully).

Quote

(+no far plane!)

If you get rid of a far plane (good idea) you better have a stratergy for turning a high polygon procedurally generated capitol ship into a lower polgygon model inversely proportional to distance (squared). Otherwise when a ship hyperspaces into a system, and looks in the direction of the space port, all ships + station + docked stations must be rendered at the same time and the system grounds to a halt.

Oh yeah, ray tracing does indeed solve this kinda thing. Maybe I am thinking too openGL. I forget how ray tracing works exactly. You shoot a ray for each pixel on the screen. See who it collides with first and where for a lookup on the texture. If you want shadows and lighting then you need to join that collision point with every possible light source in the scene (or sample based on distance) to work out the final color?

I suppose in a space game 70% of the screen the rays will collide with nothing. The worst case would be approaching a space station for docking where 100% of the rays collide with a ship and need lookups. Hmmm. In that case most of the rays will collide with the same polygons and use similar light resources so perhaps you can save alot of time then as well. Dunno. Well if anyone is a ray tracing pro then maybe its fine doing this. I have no experience.

The physics engine should be happy to do the ray tracing collision detection. We don't need fustrum culling in that case for the first stage of sending out rays. Culling light sources by a spatial sphere is easy by physics engine for the second stage. All the clever stuff to prevent aliasing and produce soft shadows in a reasonable time through intelligent sampling is alot of work though for someone to do.

Tom

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

All this talk about rendering.... Perhaps we can decide what the game should be about, and what should and shouldn't be in the gameplay scope first? I really don't care what method of rendering is chosen as long as the end product is fun.

All this talk about rendering.... Perhaps we can decide what the game should be about, and what should and shouldn't be in the gameplay scope first? I really don't care what method of rendering is chosen as long as the end product is fun.

Yeah, maybe we're getting a bit technical - there won't be a game without visuals though! I'll branch the tech stuff off onto another thread.

@LHC:Could it not have created a black hole (that grew over time) and thus swallowed the world?

Would give justification for:* accelerated space research* everyone leaving the planet (with all the possible factions)* no earth (thus not having to model how the earth would look like in xhundred years)

Perhaps we should start with a style/theme we would like to go for. I think it is very important to get this sorted up front and try to stick to it as much as possible. Here are a few sliders for people to consider:

I would personally vote for a dark/fantastic universe and visually highly stylized. Most space traders out there are of the realistic variety and it would be cool to do something a bit different and less boaring.

Perhaps we should start with a style/theme we would like to go for. I think it is very important to get this sorted up front and try to stick to it as much as possible.

I tend to think that sticking to only one style for an entire game gets quite boring... e.g. quake 2. Having areas of different styles makes the game feel fresh for the entire game. e.g. half-life original.

So why not have all styles represented but have them segregated into different areas.

One style, "Fantastic" (Star Wars) is hardly restrictive though, so why should it get boring! :-) But I see the point. There is no reason not to combine different thematical themes though. Different worlds, different stories.

However, visually, it would would be good to decide on a single concept imho. (And no, not talking about which renderer!!).

And last but not least, it should all seamlessly fit together somehow. I'd hate to go from system A to system B, and feel that I moved from one game to another. There needs to be some herring.

I like dark/gritty fantastic too. Also when thinking about developing a sector I was thinking about uylesses 31. The 80s cartoon retelling the story of the Greek hero Uylesses's adventures -- set in space! It was an awesome cartoon. Zeus would appear as a mildy transparent enormous bust in the spacedrop and say "Uylesses! you have angered the gods! You are banished to the kingdom of Hades for all eternity! which was just a sector of uncharted space" And each episode was Uylesses running into a planet and meeting other people who were punished by the gods. Of particular note was Cisiphus. He was found on a desert planet that was shaped like a funnel. He had to roll boulders down the funnel. When Uylesses arrived, ciciphus tricked him into doing his punishment for him. Uylesses prompty fell over and fell down the hole at the center of the planet. Here the boulders were crushed up by enormous hi tech equipment (cue uylesses dodging the crushing equipment). Then the rubbish from the boulders were put into a boulder mold, and then transported back upto the plannets surface! Haha. So much of the gods powers were mearly technological manifestations. Damn cool though.

Back on topic... I started writing a strip of history in relation to plot and story. If I twist my head and come up with some backstory for earth that's a little more original (that seemed to be the general consensus I think), do you want me to do it?

If you do, I ill definitely do it. However, this implies that what gets written is written in ... clay(?). Not as permanent as written in stone, but harder to erase than on paper. The point is, if I take the time to write up more documentation, I'd like there to be some threshold to "overthrowing" it afterwards. I would try to split the writing, so that individual, less universal stories can/must be written for the different systems.

If you don't, then that's fine too, but someone needs to pick up the ball in this case. New 5-liner ideas from everyone isn't going to write itself into anything

Yeah, we should work out how creative decisions are made. There is nothing worse than someone putting in time inventing great idea + fleshing them out into dialog for people just to decide that we don't like the idea anymore. Maybe we should call a vote for the proposed high level human race contexts (inc. a none of the above option if we decide we need more time to think). I think whoever puts forward an idea for the vote, should then be responsible for managing the production of story boards and history etc. if it is chosen (so Greek mythology is not a genuine suggestions unless anyone else wants to champion it). I think the creative manager's job would be organizing a wiki of creative contents and/or launching votes.

Once that vote is finalized then thats that. So we should not rush to get the vote up or anything.

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

I'm not too sure about the wiki - why put stuff in a hard-to-get-to place? (to join this wiki first get a gmail address, then email that to &c, who'll then &c) I'm also worried about all the (obviously newbie) posts on the wiki saying 'let me join! I've got a CV to invent!'

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