Jump to content

  • Log In with Google      Sign In   
  • Create Account

Journal of Mak

The Great Journey Continues - Part Two

Posted by , in Dominium 15 October 2016 - - - - - - · 1,669 views
dominium, space, trade, economy and 3 more...

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 ;)

The Great Journey Begins

Posted by , 06 October 2016 - - - - - - · 933 views
dominium, mak, space, game and 2 more...

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 :( )


Yes, you read right. Finally.
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.
I have chosen a task to complete within Dominium itself, the game universe. An epic task, a monumental chore of gargantuan proportion.
I must trade my way around several systems, and turn 1,200 SIS (Sulranian Imperial Sovereign) into 100,000 or more.

Ok, not so big – I grant you :) But, given the state Dom is in – purdy darned huge :D

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.

In other words, pretty much the entire game core.

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 :)

My journey begins at Star-7786, Planetoid-53095, GStation-1, with my purchasing 1,183 SIS worth of ‘Commodity-05’ – yes, exciting names!

Article : Lessons of Lorecraft

  Posted by , in Dominium 23 November 2015 - - - - - - · 638 views

<p>Hmm, could have sworn I’d already published this one… <img src="http://dominium.maksw.com/wp-includes/images/smilies/simple-smile.png" alt=":)" class="wp-smiley" style="height: 1em; max-height: 1em;" /></p>
<p>But, here it is anyway for those interested. </p>
<p><a href="http://dominium.maksw.com/articles/lessons-of-lorecraft/" target="_blank">Lessons of Lorecraft</a></p>
<p>My trials and tribulations creating <a href="http://dominium.maksw.com/saga/when-stars-fall/insurmountable-odds/" target="_blank">Insurmountable Odds</a>, and also touching on the origins for the entire backstory behind the game universe.</p>


State of Dominium

  Posted by , in Dominium 21 November 2015 - - - - - - · 780 views

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.

“Why?” you may ask… “A recent blog did this already did it not?”

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…

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?

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?

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.
Graphics Pipeline
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, Polyluxfor 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 Posted Image

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.

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 collisionsbetween 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 Maggycan 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 Posted Image
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 Posted ImageBut, 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 Posted Image Loreis 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 Posted Image
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)

  Posted by , in Dominium 15 November 2015 - - - - - - · 803 views

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!

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.

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.

Video Games Tax Relief (VGTR)

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?

UK Video Games Funding.

With this, I could get £25,000 GBP to help develop Dominium. Great! But, wait… I need to have £100k stashed in an account already, I need £25k to match the £25k, 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 ‘£1 for £1’ 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.

Anyway – bitterness left behind Posted Image Getting funding is never easy, for anything. Especially when you’ve got nothing but your own time to invest!

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.

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.

But, there’s a but Posted Image As ever.

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?

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…

Let’s hope – anyway Posted Image

Polylux Part Ducks

  Posted by , in Dominium 09 November 2015 - - - - - - · 593 views
Sorry, couldn’t resist it Posted Image
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!


Running well behind the curve... but with lots of lights!

Posted by , in Dominium 09 November 2015 - - - - - - · 798 views
opengl, glsl, shader, light and 4 more...
Running well behind the curve... but with lots of lights! It's about time for another journal entry methinks Posted Image

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 Posted Image 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!... Posted Image

Shedding light on Dominium…

  Posted by , in Dominium 29 October 2015 - - - - - - · 142 views
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!


General Thoughts on Progress

  Posted by , in Dominium 25 October 2015 - - - - - - · 147 views
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 Posted Image 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!


Kickstarter : Infinity Battlescape!

  Posted by , in Dominium 22 October 2015 - - - - - - · 162 views
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'...

Posted by , in Dominium 18 October 2015 - - - - - - · 714 views
opengl, glsl, shader, flare and 4 more...
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!

A little ‘Flare’…

  Posted by , in Dominium 18 October 2015 - - - - - - · 91 views
As promised…
Enjoy! Posted Image


Weekly Roundup #50

  Posted by , in Dominium 16 October 2015 - - - - - - · 142 views
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 Posted Image I’m glad I don’t have to hire my sub-conscious! Posted Image


Void Destroyer 2 Kickstarter

  Posted by , in Dominium 12 October 2015 - - - - - - · 166 views
Hi everyone – just a quick line to ask you to consider supporting Paul with the modest Kickstarter he’s just launched for $10,000 to knock out Void Destroyer 2.
Go support the man Posted Image Keep the indie gaming flame alight!


Weekly Roundup #49

  Posted by , in Dominium 08 October 2015 - - - - - - · 98 views
Dev news wise, another dull week from your perspective – most likely! Posted Image
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? Posted Image ) 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 Posted Image


January 2017 »

15 16 1718192021

Recent Entries

Recent Comments

Recent Entries

Recent Comments