• Advertisement
  • entries
  • comments
  • views

About this blog

The Trials and Tribulations of going Indie...

Entries in this blog

Rather than copy/paste this time, I thought I'd knock up some more pre-amble...


It's quite interesting to see the impact of things that have been left by the wayside for some considerable time, as they aren't really 'important techwise'... such as the names of things. I remember a Designer friend telling me to generate names for stars and planets in the last Kickstarter campaign, but I was reluctant as it meant 'doing things right' and producing an algorithm of meaningful and consistent / pronounceable names. I didn't want to 'name that thing' so early, as chances are things will change, move around the cluster, and so on. The Cluster isn't final - at the moment it's a 10,000 star globular cluster, and the aim is to get to 200,000 stars for the final. Different civilisations name things differently, and so on.

But, that said, the plan all along was to deterministically generate the cluster and then patch in 'known systems' on top. Book One of When Stars Fall (Insurmountable Odds) sets out quite a chunk of the Cluster with names and locations, and they need to be honoured in the game as well.

Simply naming the (small) set of commodities has grounded that aspect of the game, trading has taken on 'form' now that I can buy 12t of Bio-tech, instead of 12t of 'Commodity-04'

Looks like I'll be naming those 'known systems' sooner rather than later ;)

In part due to my long term absence from these hallowed halls, and in part because hopefully starting this blog series will force me to keep up the development momentum :) I give you my first attempt to do some 'playing of the game' in Dominium at long last... warts and all...

(Lifted directly from http://dominium.maksw.com/2016/10/06/the-great-journey-begins/ - feel free to sign up for the Dominium Observer newsletter!)
(PS. Apologies for the crappy formatting... despite adding newlines / whitespace, this Journal posting wossname keeps stripping them back out again :( )

[color=rgb(58,58,58)][font=Arial]Yes, you read right. Finally.[/font][/color]
[color=rgb(58,58,58)][font=Arial]I am turning my efforts to gameplay. This series of blog posts (and hopefully video blog posts!) probably won't particularly read gameplay-ish, but trust me it is.[/font][/color]
[color=rgb(58,58,58)][font=Arial]I have chosen a task to complete within Dominium itself, the game universe. An epic task, a monumental chore of gargantuan proportion.[/font][/color]
[color=rgb(58,58,58)][font=Arial]I must trade my way around several systems, and turn 1,200 SIS (Sulranian Imperial Sovereign) into 100,000 or more.[/font][/color]

[color=rgb(58,58,58)][font=Arial]Ok, not so big - I grant you :) But, given the state Dom is in - purdy darned huge :D[/font][/color]

[color=rgb(58,58,58)][font=Arial]No combat, though there are NPC's, and I can 'kill' them with a single shot atm - but they don't fight back. The aim of this epic quest is simple, to iron out kinks with the initial UI, trading, cargo/inventory, flight mechanics, navigation, autopilot, map and control systems.[/font][/color]

[color=rgb(58,58,58)][font=Arial]In other words, pretty much the entire game core.[/font][/color]

[color=rgb(58,58,58)][font=Arial]The raw materials are all in place, and now I have to 'test drive' them to see if they stay together for an epic win, or fall apart in an epic fail! I know there will be catastrophic 'blockers' en route, so this is a 'warts-et-al' blog :) Don't be disheartened if the video suddenly disappears, it was probably just a crash :)[/font][/color]

[color=rgb(58,58,58)][font=Arial]My journey begins at Star-7786, Planetoid-53095, GStation-1, with my purchasing 1,183 SIS worth of 'Commodity-05' - yes, exciting names![/font][/color]


State of Dominium

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 frownie.png[/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 1f609.png
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 simple-smile.pngBut, 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 1f609.png 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 simple-smile.png
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.

Only time will tell! Onwaaaaaaaaaaaaaaaaaaaaaaaaard!

Weekly Roundup #54(ish)

Alas I've missed the past month of weekly roundups - though have dropped some posts to keep things ticking along, so a no score draw there![/font][/color][color=rgb(58,58,58)][font=Arial]
I'm having a bit of a rant in this post - as I'm entirely fed up with this country's (the UK) cowcrap about supporting the games industry.[/font][/color][color=rgb(58,58,58)][font=Arial]
Of late, I've been quietly sniffing about two of the 'wonderful' schemes the UK Government have set up to 'help'. Particularly to 'help' small dev's / game startups.[/font][/color][color=rgb(58,58,58)][font=Arial]
Video Games Tax Relief (VGTR)[/font][/color][color=rgb(58,58,58)][font=Arial]
With this, a games company can claim tax relief on all their expenditure toward a game projects development. It has to be on a per-project basis. It has some interesting 'criteria' to fulfil... most of the key one's are that the game, it's subject matter, and/or characters have to be 'British'... now, don't get me wrong - I'm happy to 'be British' (usually), but how does this help me with a space game set 20,000 years in the future in another galaxy?[/font][/color][color=rgb(58,58,58)][font=Arial]
UK Video Games Funding.[/font][/color][color=rgb(58,58,58)][font=Arial]
With this, I could get GBP25,000 GBP to help develop Dominium. Great! But, wait... I need to have GBP100k stashed in an account already, I need GBP25k to match the GBP25k, and the game must be 'innovative'... now again, don't get me wrong. I can see the value of these criteria, of course, and it's quite common for 'GBP1 for GBP1' matched funding, but it's the fact that this (and the VGTR) are sold as 'helping to grow small/startups' that grates on my nerve because they clearly don't help me. All I can see are two 'schemes' which help the big boys get bigger. As usual in this country, the little guy is left out in the cold.[/font][/color][color=rgb(58,58,58)][font=Arial]
Anyway - bitterness left behind simple-smile.png Getting funding is never easy, for anything. Especially when you've got nothing but your own time to invest![/font][/color][color=rgb(58,58,58)][font=Arial]
After the advances made on the Polylux Lighting, I've finally knuckled down to sorting out the scene management system once (and hopefully) for all. And yes, I'm refactoring yet again. All the scene management is maintained within (IMHO) well designed classes, and the 'master observer' (being the object viewing the scene) can be any game object. Not just your vessel, but you can view from a waypoint, weapon turret, station, or even a star.[/font][/color][color=rgb(58,58,58)][font=Arial]
That said, the slow - shall we say acretion - of code to do with moving that 'master observer' has become tightly embedded with the Vessel and Autopilot objects. As such, the code for flying around the galaxy is a little fragmented and it's now starting to crack apart at the seams. I've now restructured the code to properly page scene objects in/out around the master observers position, and finally entire star systems will now happily destroy themselves (and everything within them) when I use a wormhole to jump to another one. Figuratively speaking, of course! All the game objects used to portray them are cleaned up and given back to their various factories for reuse by the next star system.[/font][/color][color=rgb(58,58,58)][font=Arial]
But, there's a but simple-smile.png As ever.[/font][/color][color=rgb(58,58,58)][font=Arial]
Using 'linear' drive systems is as big a challenge as ever. Accelerating away from a station should have it recede into the distance and vanish realistically. You can then stop, turn around and then fly back to it, seeing it reappear in the far distance. You should only start seeing movement relative to the planet you are orbiting as you gain an incredible amount of speed compared to that station, and then movement relative to the star system at even higher speeds, and so on. But what if I'm in a ring system? I want to fly through it, see 'rocks' fly past me, but also eventually see myself moving around the planet/rings themselves (perhaps from the night side into the day side). What if I'm near an orbital planetary ring station? I want to fly along it, and make my way around the planet, so what if it will take hours of real time play?[/font][/color][color=rgb(58,58,58)][font=Arial]
All of the fundamentals for this are already in Dom. And theoretically all I have to do is wire them all up in the right way. I have this strong requirement for 'seamless' transitions, and now it's time to crack this nut once and for all...[/font][/color][color=rgb(58,58,58)][font=Arial]
Let's hope - anyway simple-smile.png[/font][/color]

Polylux Part Ducks

Sorry, couldn't resist it 1f609.png
Here I conclude (for now) the work being done on the Polylux Lighting System - as it's nearly production ready, and fairly efficient as it stands.
Enjoy the video blog!

It's about time for another journal entry methinks smile.png

Of late I've been of a mind to do some of the 'eye candy' I want to get working in Dominium, for special effects et al. I've lond had in mind a solution for the 'multiple light source' problem, especially with shaders in mind.

Now, I know about deferred rendering, and static/dynamic light-mapping, and so on - and hence the title of this journal entry smile.png I have little time to work on my pet project, and have to work with what a) I have and b) is attainable realistically in short bursts of development.

So, 'polylux' is my system for allowing multiple light sources, per object (in fact, per material/mesh). It works with the gl_LightSource state parameters, and hence is typically limited to 8 simultaneous light sources. I chose this route as a 'starter', but it'll probably also be a comfortable base line going forward - until the demand for more rears its ugly head.

It works by abstracting the 'data' for a light away from the actual OpenGL 'light' - so I can have hundreds (theoretically unlimited) light sources whizzing around the scene, being animated and so on. But, when it comes to render time, only the 8 most 'important' light sources are considered by the shader when its used to render the model itself.

As it's 'per material' (and there is always only ever one multi-stage material for any particular mesh in the 666 engine) then that means a single model could be lit by far more light sources if it's authored in the right way. ie. a single model with 4 meshes, could be 'lit' by 4 x 8 lights, with each mesh being lit by its nearest 'most important' light sources.

A simple geometry pass is used to determine the nearest lights that could possibly contribute light to a mesh, and light sources can be prioritised to always be included (i.e. the sun). Directional lights are more important than beam lights, beam lights more important than spot lights, spot lights more important than point lights. Larger light-sources are also then weighed in the balance, as a single huge point source (explosion) would then supercede a beam, or even a directional light.

As Dominium is a free flight space sim, all the lights will exist as 'colliders' within the collision octree, and thus I can leverage off that system to determine which light caster volumes interact with a models 'light receiver' volume. So initially there is a broad-phase pass to remove light-sources which do not contribute light, followed by a narrow-phase pass of direct collision testing, and finally a sorting/prioritisation cull which reduces the number of sources down to 8 at most for a given mesh.

I could support more than 8 of course, by simply providing an array of light source data to the shader directly, and bypassing the OpenGL state objects. But ultimately, the limit will be how many times the GPU can process light contributions to a single pixel. I may experiment with that later as time permits.

The shader aspect is fairly simple - it simply loops over 8 lights, and checks if a light is enabled or not before computing the contribution with the appropriate shader code for that light type. With shader branching concerns, that's probably a false optimisation - but I'm not at the 'make it optimal' stage yet anyway. Eventually there would be 8 variants of the shader, one for each additional active light source and other possible tweaks as they arise.

So - what use? Explosions (as mentioned), weapon effects, huge ship-slicing energy beams, engine effects, sunlight, reflected planetary light, reflected ring-system light, glows from nebula's, pretty much anything luminous really!

Anyway, enough waffle - enjoy the video, hopefully!... smile.png

My work on the Engine Flare effects left me stuck with an issue. I want a nice 'glow' of the engine core as it starts kicking out energy. The core will glow as it fires up, pulse as the engine flare picks up, and then once the engine is turned off, it will cool down and fade out. This glow will also affect the surrounding engine cowling (if present) - an affect I was intending to achieve using simple light-maps.
But I want that 'glow' to also illuminate nearby geometry on the ship (and indeed, any other object stupid enough to be nearby).
It was time to unleash Polylux! (StupidNameTM).
So far, I've only dabbled with up to two lights in the scene - the main star light-caster (which at the moment is the resultant of all stars, ie. in a binary system), and then the reflected light from any nearby planet/satellite.
The demands for 'teh shiny' are high these days, and Dom will be no exception. Although I am still intending there to be the 'realistic' and 'pretty' modes of course. Regardless, Dom will need a lot of lights in a scene, especially when it hits the fan and everything kicks off into a space battle.
So, my remit for Polylux is as follows;

  • Theoretically unlimited number of lights in a scene*
  • Support for various light types

    • Directional (infinite source)
    • Point lights (localised)
    • Light beams (localised)
    • Spotlights (localised)

    • Configurable parameters
    • Animatable parameters
    • Integrates with the current shader pipeline
    • Scalable support
    • Material bound**

      *Theoretically - in other words limited by the hardware, not the code
      **Lights per material, not per scene, allowing for finer control and fidelity overall
      So while none of this is 'amazing' when compared to other AAA engines, I'm still fairly pleased with the results!
      PS. I am aware of Deferred Rendering & Lighting, which would let me have thousands of lights in the scene. I have it on the radar but right now it would mean such a massive change to the rendering pipeline it would stop all the (part-time-adhoc) work on Dom for over a year!

It's occurred to me that some may (quite justifiably) be thinking that 'Dom dev' is being side-lined in favour of writing the trilogy, because surely that must be taking much more effort/time/life to achieve... writing a book is no mean feat, and engaging in a trilogy is 5.2 times as complicated...
You may notice that another project has been added to the roster - Book 2 - House of Thoraz, and you may now be thinking the above even if you weren't already...
Time management, pure and simple. Along with throwing as much personal time as I can get away with without leading to a divorce, my working day gives me a reasonably heft commute (4.5 hours) and 2 of those are nice, quiet 'do my stuff' time. Back in the day of the original kickstarters, my commute was 5 hours plus, 1.5 hours of that was on the tube which I used to write the original draft of Insurmountable Odds on my phone, along with a goodly wedge of the second book, and 2 hours was on the train used to do Dom-dev. Now I only get that 2 hours of train time, which has been (largely) for Dom-dev, so there's little time for the book at the moment.
So, now, to work on Book two - I will have to split some of my dev-time up, but the majority will still be on Dom-dev. It's going to be an interesting challenge for sure - but rest assured that I won't be parking Dom as a game project, and it is definitely, categorically, priority number one on my list!
As a general checkup on progress overall, well in my own brutally honest opinion, it's way, way, way, way too slow.
But, that's a given (given the above) and not being able to dedicate full time effort to the project whilst paying the bills. A problem everyone has simple-smile.png However, there is a weird 'silver lining' to the dev effort... short, sharp, concentrated blocks of dev time mean getting the most out of each. All the time in-between I can think, ruminate on and cogitate on choices and options for solving many of the technical challenges of a vast, seamless, open-play space game.
I have solutions (in my head) to many of the things which cause problems, procedural levels to walk around, cities on planets you can walk in, decks on ships, space stations, your own bases, populating all that with flora/fauna/characters, character/ship histories, atmospherics, flying into gas giants, even stars... time will tell if these solutions are worth anything of course! Sadly for me(us) they just have to wait until I can get to them.
I can't speed up the dev process without funding - not only for myself to dedicate more time, but to be able to hire others to add content, take up the code-slack from myself, etc. And I can't get funding without having more to show to encourage funding. That's why I'm more than happy to encourage funding on other worthy projects (like Infinity Battlescape), which are far further ahead and deserve to get funded.
Ah well! Onward!

It's no secret (perhaps) that Fabien's Infinity encouraged me to finally get off my backside and do something about the space game I'd always dreamed of. His superb grasp of the GPU and stunning planetary scale terrains are still awe inspiring even today.
Now that he has a crew behind him, they've finally (about time!) launched a crowdfunding campaign that must surely get funded, and I encourage any followers of Dom to go take a Kickstarter : Infinity Battlescape!


A little 'Flare'...

Ah dear - another disappointingly huge gap since my last journal post I'm afraid! However, work progresses on the leviathan game project that is Dominium.

I've been tinkering mostly with all the behind-the-scenes stuff that makes a game tick. So for a brain-break, I turned to some eye candy :)

In my head (the perfect programming location where nothing goes wrong and everything works as you think it should) I have a volumetric shader that is struggling to be born. I will solve it one day, but so far it has eluded my GLSL skillz. For now, I must be content with the normal 'sprite' based systems which most have seen before. But, I couldn't leave it there. So I added procedural noise to get that random flame-like effect, and I'm fairly chuffed with the results!

As ever, it's a lot better in action - so if you can stand the drone of my voice, please check out the video!

Weekly Roundup #50

The scene reworking is done, and a lot more logical to work with. But there's a but... whilst things now page themselves into the scenes beautifully, they don't really like leaving. This is something that has long been an issue with the implementation, and I've made numerous attempts to resolve it with only partial success. Sadly every attempt has led to loads of if,else,if,else,if,else,if,else,if,else, and so on ad nauseum. Lots of logical testing for various conditions which ultimately leads to a spaghetti mess that's not only hard to follow, but stupidly hard to debug. Making changes is a nightmare, and it's fragile to say the least.
So, it's time to kill it and do it properly. As usual when facing major changes, or monumental problems, my standard approach is to step away from it, and let the old sub-conscious kick it about for a while while I work on something else.
I've turned to some 'eye-candy' - and returned to the long shelved engine flare system. For anyone with a long memory, I parked this as I have a technique in mind that I couldn't get anywhere with. To rest the neurons, I decided to go for the traditional approach and have knocked up a flexible flare system that - if I do say so myself - definitely ticks the boxes. It's nothing radical, but the end result is definitely 'good enough' for now at least. I've got some tweaking/polish/changes to make, and then it will be ready for a video which I hope to get to over the next few weeks.
And, after that distraction, a solution to the scene paging problems has presented it self simple-smile.png I'm glad I don't have to hire my sub-conscious! 1f609.png


Weekly Roundup #49

Dev news wise, another dull week from your perspective - most likely! simple-smile.png
I've been refactoring again, and by now you'll probably be thinking "This guy really likes redoing stuff he's already done, what about new/cool stuff?"
Well, as much as I do enjoy the fruits of my refactoring endeavours - refactoring ain't all fun! You have to take something that works and break it good and proper, 99% of the time nothing works afterwards until you've fixed it all up again. That can be a daunting task, and often leads to thoughts of "Why did I do this? It'll take ages to fix this back up..."
In this instance, the recent work on Scene Paging led me to think of a tidier way to handle objects as they ingress/egress the various scenes. That then lead on to tidying up the 'huge' logic blocks that get invoked per object as they ingress/egress. For instance, a vessel has to say 'ok, i'm in the local scene now, so I need a model to render, weapons on the model, loads of assets, a presence in the scene, shields, etc. etc. etc.'. Then when it leaves, it has to say 'Ok, done with this lot!' and then detach them, get rid of everything it created when entering the scene. It has to do this nicely, so if another vessel enters the local scene, it can efficiently recycle any/all of this stuff to avoid recreating objects all the while, as that really fragments memory, and takes time, so results in a performance hit.
So, after a week of coding, Dom looks no different, but the engine code is a lot tidier and far easier to debug. And trust me when I say "That's a good thing"! Also, as and when anyone out there gets to be able to Mod this beast, they will be much happier I did this.
All this work on the Scene system is very important. It's the core of the entire game engine system, and allows me to portray a scene from anywhere in the game universe and isn't dependent on any preset concerns, like the players position. Why? you may well ask...
1) Observers. Observers (if you haven't read Insurmountable Odds, why not? simple-smile.png ) are weeny punctures in space-time that allow you to observe anything through them, a bit like a wormhole. A vessel equipped with Observers can drop or project these handy little doobries anywhere they like, and then keep an eye on things from the other side of the Cluster if they so choose. Their use is limited though - the power drain is huge, and they decay over time, but they are excellent for short term surveillance. (Like watching a station for a vessel departure, whilst lurking behind an asteroid on it's route waiting to ambush it...)
2) Wormholes. Whether from a constructed gate-station, or generated by a Wormhole Drive, these much larger spherical punctures in space-time will show you the volume of space on the other side of the wormhole at the terminus point. From any angle. Likewise, once you've transited the wormhole, you can still see the scene of your departure point until the wormhole closes.
So, to support those two systems, I have to be able to instantiate an entire scene at a specific point in space, at any time, so they can be rendered along with the scene from your current location. I can't wait to actually get to implement this simple-smile.png


Insurmountable Odds

More awesome, than a whole bucketful of awesomeness... a picture says a thousand words. My thousand are all 'Awesome'...
Via CreateSpace I now have print editions of Insurmountable Odds!
I can't tell you how it feels to hold a print copy of your own work in your own hands. It's worth every minute of the effort!
This first proof is a duffer - too late, I spotted I'd been banjaxed by Word altering the fonts - so some chapters have totally different fonts to others! Also, the book size (6? x 9?) is huge! And the font size needs reducing. So, round two will probably keep the book size, and reduce the font (and fix the fonts up). And I may try a smaller page footprint so it's more in line with traditional books. Not sure yet... still thinking. Also, due to the distribution system - the purchase is very high, and gives very little in royalties... so it's not a great option for the end customer, or getting revenue for Dom... but what the heck, it's free to set up simple-smile.png
Of course, once done - I will be offering some copies as a prize for an as yet to be announced competition simple-smile.png


Weekly Roundup #48

Ok, so not quite 'weekly'... simple-smile.png
I just thought I should reassure all that it isn't entirely 'all about the book'!
The PR machine for IO (Insurmountable Odds) is underway, probably not as much as I should be / could be doing, but certainly as much as I can be doing!
In the mean time, I have been doing some actual coding on Dom simple-smile.png
Having been working on the Scene Context Manager, I then turned to the Scene Paging system. I noted I've somehow broke it, so when you leave the current local space volume, it all kind of stopped working, and presumed you were flying in interplanetary space which led to interesting other problems. That's now all tidied up, so as you fly 'out', all local scene objects are relocated correctly, and anything that is no longer in your volume gets removed. Next is to sort out paging objects that aren't present into the scene when they should appear.
I've also come up with an idea for rendering volumetric clouds - probably nothing new, but the idea has promise. I've also tinkered (in my head) with realising scenes where you are inside a station/vessel/base and how to render the external scene where you look out a viewing area. Of course, the challenge is to avoid doing anything with either of these thoughts, so I can concentrate on the work I should be doing!
In other news, despite Intel refusing to support their crashing graphics driver in Windows 10 - lo and behold, I have just installed the latest version of their driver, from their site and amaze-balls, no more crashing! Who would have thought? I'm really impressed that Intel chose to fix the problem for someone else. Not!
That's it for this week simple-smile.png

I've long put this off, because if I ever got to integrating Planetary Landings into Dominium, I wanted to do it well and do it 'full on'... (flora, fauna, cities, people, all procedurally crafted). But after two years of spare-time work on the 'behemoth' project... I can no longer resist having a play at least!

There's nothing 'new' here to those who tread the hallowed halls of GameDev, just my take on existing techniques and the resulting trials and tribulations. I found myself with a full working 'day' to dev with, so decided a little video capture to show progress over the day was in order.

The prototype uses the 'make a sphere from a cube' approach - where I split up a patch plane into quads, and then tessellate each until it needs subdividing again, and so on. Then the patches are 'inflated' to form the sphere necessary for the desired planet.

As yet, it's fairly naive - nowhere near a final product. Visibiity and LOD is done (for now), but patch skirts have to go in to close seams, and height values are needed of course. This is all being done on CPU as well - and I've already found with my early noise function trials that I'll have to go GPU to get anything near the results I want.

Still - for a days coding I'm fairly chuffed I got what I had in mind down in code, and it's a solid basis to build something on down the road. For Dom - all I initially want is something that looks 'credible' and allows the player to land/explore/mine/establish bases, etc. Uber-awesomeness can come later if Dom ever gets released, and ever earns a penny ;)

Feel free to read the full article, and check out the video 'diary' of the dev-in-progress!

An excerpt from my latest blog post...

[color=rgb(58,58,58)][font=Arial]Work has progressed this week on the Celestial Body rendering - I've resolved the issues reported in the last post and largely wrapped it up for now. I've also obtained a few more high res textures to use as placeholders to extend the visual variety as I hop around the galaxy. I've added some renders to the media section over the weekend.[/font][/color]
[color=rgb(58,58,58)][font=Arial]But - the biggest 'wow' this week happened when I replaced the existing Star renderer with the Celestial Body, and then applied a new texture for the stars surface. It had long been on the 'todo' list to sort out the existing plain/dull texture, and I knew the lens-flare system would make it look a bit 'special' when I got around to it ... but it's been a while since I genuinely surprised myself without doing any code to make it happen icon_wink.gif Anyway... enjoy the video![/font][/color]

[color=rgb(58,58,58)][font=Arial]You can read the full entry here if you're interested...[/font][/color]
Whoa indeed - I can't believe it's been this long since my last Journal here... I seem to get no time to update anything beyond my own blog these days. Every single minute is spent 'dev-ing'...

Anyway - I thought I'd drop by and throw in my attempts at self-shadowing so far in Dominium. This is actually progress from two weeks ago, I'm having fun trying to capture the latest (and much better) results with FRAPS as I think I've managed to banjax it's interception of the frame buffer - ah well!

I've opted for the shadow-map approach, which I'm sure you're all familiar with - this is all relatively old-hat these days - but for anyone who's not... this viewer renders the ship from the point of view of the light source, and captures just the depth buffer information into a texture. It then makes that depth texture available to the 'proper in-game' shader when it renders the model, and works out whether each pixel in the final image is in shadow or not, by comparing the depth value against the one in the depth texture. If it's greater than the depth-texture, the pixel is lit, and vice versa.

Feel free to take a nose on Dominium's Youtube Channel

You get into a whole world of fun with z-fighting, and of course 'jaggies'... oddly, in this video it's using a 256x256 depth texture and the jaggies don't actually look too bad with a tiny bit of in-shader linear filtering.

Anyway, the current system is hitting a 2048x2048 depth texture (for testing) and using PCF as well. It looks great at a near-distance, but starts looking a little rough when closing in.

I've yet to get this in-game, the logic has been put in - but I'm not getting any depth texture output so I've clearly broken something somewhere... sigh. I just have to track it down!

Another update soon-ish-maybe-later smile.png
It's a sad truth - but it seems we've unwittingly fallen foul of the Trademark and Patents legislation.

"Dominion" is in use by Rio Grande Games for their card game and is apparently a pending trademark in the Video Games category.

As a consequence - they have (through their lawyers) requested us to cease and desist from using their pending trademark for our product.

Naturally at this point, this may mean having to cancel the pitch on Kickstarter. I have emailed them asking if I can rename the pitch and preserve the current campaign status and backers, I am awaiting their response. If I have to cancel I will immediately repitch with new branding. I'm not going away with this :)

I have contacted RGG's attorney to clarify a few points - and to see if we can arrange something mutually acceptable to allow the current pitch to complete before renaming. Subject to that I will rename Dominion to something else, moving the sub-domain, and altering all the satellite sites we've used as best I can.

I would point out that RGG and their attorney have been very helpful and polite, they are just protecting what is legally theirs - as we would if the situation were reversed. Branding is very important to any product. No "legal" action has been threatened, they are just asking us to respect their Trademark, which we of course do.

Finally, I want to take this opportunity to assure all our backers and followers of "Dominion" (meaning our product :) ) that I do not see this as the death of the game - it's just a name change after all... the soul of Dominion, the design and the game will remain the same!

I'll just have to do a bit more digging on the next name choice... :)

The campaign will continue as is - but will no doubt change in some form early this week coming. Updates to follow as this gets resolved!

Thank you for your understanding - I hope this doesn't affect your generous contribution!

PS. If anyone has any cool suggestions for a new franchise name - now's a great time to get them in ;)
[color=rgb(58,58,58)][font=Arial]I'm dead chuffed to announce this one - for obvious reason![/font][/color]

[color=rgb(58,58,58)][font=Arial]Maia, the highlight anticipated indie title by Simon Roth, has gained praise and excitement since its Kickstarter project took off to fund the games development.[/font][/color]


Maia is an awesome looking "God Game" - in active development - where you create and manage an underground colony - mining and obtaining resources needed to build the facility to house the colonists, and keep them safe against the hostile environment of Maia.



In what must surely be the first ever Indie cross-over project (ok, we haven't checked!) , the awesomely generous Simon Roth has agreed to spread the word about Dominion off the back of his Indie success.



In return, we uncover this parallel Maia in the Dominion universe (where almost anything is possible icon_wink.gif ) - which will provide a way to link to Maia's website and/or purchase page when it's ready. Maia will become a fundamental trade hub in Dominion, to encouraging a lot of in-game visitors icon_wink.gif



Check us out here! : http://www.kickstarter.com/projects/maksw/dominion-fight-for-your-future-amongst-the-stars



Video here!

[color=rgb(58,58,58)][font=Arial]The time has come folks... after some great feedback on the new pitch, we're ready to go on our publication date of [/font][/color]00:00 [color=rgb(58,58,58)][font=Arial]on[/font][/color] May the 4th[color=rgb(58,58,58)][font=Arial]![/font][/color]

[color=rgb(58,58,58)][font=Arial]Our hope is that we can ask everyone who is interested in backing us to back us on the same launch day! If we can get some momentum going on day one, it will help bump us up on the visibility list on Kickstarter and Kicktraq - and hopefully more people will get to see our pitch - increasing the chances of being funded this time around![/font][/color]

[color=rgb(58,58,58)][font=Arial]So - we ask that if you are as enthusiastic about seeing Dominion take space-flight as we are, please be sure to back us once again, on day one of the pitch, on May the 4th![/font][/color]

[color=rgb(58,58,58)][font=Arial]I'll update here with the pitch link the moment it's live![/font][/color]

[color=rgb(58,58,58)][font=Arial]And if you can't back us - or aren't interested - but know someone else who might - please pass us on wherever you can that will listen![/font][/color]

[color=rgb(58,58,58)][font=Arial]Thank you for your support![/font][/color]

[color=rgb(58,58,58)][font=Arial]Too many exclamations! I can't help it!![/font][/color]
  • Advertisement