Whilst BT - yet again - fail to provide the service I am paying for, I decided to take some time to reflect the current State of Dominium, from a development & feature point of view.[/font][/color][color=rgb(58,58,58)][font=Arial]
"Why?" you may ask... "A recent blog did this already did it not?"[/font][/color][color=rgb(58,58,58)][font=Arial]
Well, yes. But I thought I'd go through in my own head and think of the technology Dom will require and highlight some of the work done so far...[/font][/color][color=rgb(58,58,58)][font=Arial]
Dom's core is - quite broadly defined - a free-roaming space flight game, which ultimately will allow you to roam around your own ship, every space station, base, city and planet in the entire game universe, seamlessly - no loading screens, no convenient smoke-screens allowing stuff to pop in or pop out. Some challenge for one part-time guy, right?[/font][/color][color=rgb(58,58,58)][font=Arial]
So after two calendar years+ of development (though only probably 3 man-months of actual elapsed development time), what has actually been achieved that heads toward the above mega-goal?[/font][/color][color=rgb(58,58,58)][font=Arial]
Let's start small and build up. By the way - here I define 'Chains' - chains are something that is holding me back, or will be holding me back in that particular area.[/font][/color] Graphics Pipeline[color=rgb(58,58,58)][font=Arial]
Ok, this is a bit broad I guess - but here I want to concentrate on the vessel/station models. Shaders are in use which provide all the typical toys expected in a AAA game these days (and also now pretty much any Indie game to boot). Normal mapping, detail mapping, self-shadowing etc. On top of that is the dynamic lighting solution, Polylux for special effects. Geometry is not yet optimised, right now it's a triangle soup thrown at the GPU. I have to rewrite the tri-stripping system to optimise the geometry, but I always use the rule 'optimise when you need to'. Right now I don't need to. Later, when I want 1,000 ships in combat, I'll need to.
The materials system from 666 (my underlying engine) allows pretty much any material meta-data to be added to a model easily, or swap shaders, or change shader values. It's totally extensible, so no worries there going forward.
Level of Detail is supported, but most (99%) of the models I am using at the moment don't have LOD's. Because I don't have time to make them
[/font][/color][color=rgb(58,58,58)][font=Arial]Chains : Artists - or lack of. I can't hire 'em, and none I know of can do stuff for free. I'm aiming for AAA here, so there has to be a standard to meet, and that ain't happening for free.[/font][/color]
Right now, all models can be assigned markup for lights, weapon mounts, docking points and engine effects. The game engine then produces collision geometry programatically at the moment (though eventually authored volumes will contribute as well). There is still a lot to do here - like docking volumes, safe paths into station interiors, etc.
Chains : Time, Artists, Designers - same as above really. Collision System
Dom can efficiently pinpoint collisions between a point particle or a ray and a specific triangle on a model. The bare minimum requirement. Above that, all manner of geometric primitives can be tested, each providing points of collision/interaction and the resolution of each collision. Physics doesn't yet come into play, because most of the technology at play in the game universe can control inertia. However, those systems can fail or be destroyed by enemy fire, so physics will play an important part eventually. Collisions are all queued up, and handed back to the objects involved for them to resolve what happens for each one - such as a shield effect, or weapon impact, or explosion, etc.
Chains : Time - I need to perfect the system and get it working for all cases. Visibility System
Every scene has an octree to control visibility, nothing new here.
Chains : None, tis done! Content Special Effects
Particles, beams, solar 'glare' and procedural tailored engine flares are all present and correct. Again, there's a lot more to do, but I'm trying to convince myself to avoid doing any more until there is some definable gameplay up and running.
Chains : Artists/Designers Vessel, space station & building interiors
Dom currently has procedural 'level' generation - so I can slice any model up into layers, each becoming a deck, or a level in a space station/base, or a floor in a building. This means I can produce a unique layout for any level, for any model, wherever it's used in the game universe, or establish patterns which are common to the model in use.
Now - I'm no AAA studio with mega-funding - so forgive me for having to rely on certain trade-offs. Here the big trade-off is that these interiors will be made from pre-fab models which can fit into the tilemap based level the procedural generator squirts out. That instills a certain rigidity, and also uniformity. But, the aim is to have variety based on a style of interior associated with the civilisation which built the interior. Initially, pretty much everything will look the same I'm afraid. But if Dom takes off, it'll be a doddle to slot more styles and variety into the mix and broaden the players experience.
This is all done and in place in the wings, ready to be integrated, and allows the player to literally go anywhere in Dominium. Repetition will be the biggest concern here.
Chains : Artists, Designers Derelicts
Any model can be broken up into chunks and blown apart, leaving a derelict behind which can be persisted pretty much for as long as I choose. This can be a satellite, all the way up to a major space station. Derelicts will be 'raidable' for remaining cargo, equipment and supplies, or data. I'd love to be able to board them and roam around, which should be possible with a few tweaks to the PCG level system.
Chains : None, it's done! Planets
All planets, planetoids, major asteroids - anything large enough to land on - will be procedurally generated. Right now Maggy can produce a very rough planetary scale surface suitable to walk around on, or fly around, and let you travel up to orbit and beyond seamlessly. But there's no hiding it needs a lot of work to be acceptable. And then it will need procedural flora/fauna/settlement placement.
Planets can have procedurally generated ring systems - each unique to the planet it orbits. Flying into a ring system then produces debris fields (of ice chunks) again, each unique to the ring system, and their density determined by the ring system bands. If you drop a tag onto an ice chunk and then fly across the galaxy, you can return to the same ice chunk at any time and it'll be as you left it... unless someone else has mined/collected/destroyed it, that is
Chains : Time, and eventually (a way down the road) Artists/Designers Scene Management
Right now - it's a bit clunky around the edges - but you can fly from a docking point in a station, through a ring system full of chunks of ice, around a planet, past it's satellites, across a star system, around a star, and then out into interstellar space across the galactic cluster to another star, and back all the way down to dock with another station. All without pause, loading screen, or smoke-screen to hide transitions. Ithankyou.
It's not all rosy though. I still have technical issues - largely to do with the Autopilot and course plotting. Technical wrinkles to iron out. Also, I have yet to address larger feature issues that impinge on 'local space'. Ie. Planetary orbital rings, which you should be able to undock from and then fly along _all the way around the entire planet_. Likewise, you could fly along a ring system through the debris fields all the way around the planet. Asteroid fields will orbit stars. Comets with trails hundreds of thousands of kilometers long. Nebula's which you can fly into and out of. It's a long list.
Chains : Time, and eventually (a way down the road) Artists/Designers Game Universe
The entire galactic cluster can be generated procedurally, using rules derived from current astrophysical thinking for star distribution, makeup, goldilock zones defining habitable worlds, planetary variety from molten lava, rock worlds, gas giants, and ice chunks. Civilisations and empires are also defined procedurally. Once the game is ready for a defined content set, I'll bake all this into a persistent game database. I'm doing this instead of just procedurally whipping one up dynamically whenever you play, because eventually the universe will be the same as the intended MMO game, and that universe _will_ change... I can say no more
But, this may change if I come up with some cunning plan to avoid creating a huge database of every planet around every star!Chains : Time, Artists/Designers Lore
I won't mention the book, I promise
Lore is definitely a work in progress, from technology, to races, to back stories. But the kernel is in place now, and being expanded as I go.Chains : Time, Designers Platform Support
Windows/PC. Right now, I'm developing solely for Windows on PC. Though 666 supports OSX, iOS and Linux. Though each platform could do with a refresh by now, but there's no point yet. If I do that now, by the time I get to release Dom, I'd need to do it again as each platform will have advanced yet again in the mean time. So cross-platform support is on the 'Pragmatic Todo List'. Summary
Phew! Not an exhaustive list perhaps, but certainly big enough for now
You can see a clear pattern there of course... I clearly need extra resources if I'm ever going to deliver Dom as I intended. And absolutely no disrespect at all to PixelDad, Sol and Mr. T who have helped me loads with Dom so far, nor those spreading the word behind the scenes either, such as Cornflakes, Pinback, DarkOne, and not forgetting Geraldine!
All I can do in the mean time is whittle away as much 'Time' and code/feature development as I possibly can to get something tangible, that people can pick up, poke holes in, and perhaps raise a ruckus about. When I get to that point, then maybe, just maybe, the magic will happen.
<>
