Maksw back in the dev trench http://dominium.maksw.com/2015/01/31/slowly-slowly/
Slowly, slowly…
Published on January 31, 2015, by Mak - Posted in Dev, General, News 0
I’m finally trying to get back into the dev-seat, again. So without belabouring the point… onward with the post!
I made a small tweak to the HUD scanner, so now contacts are scaled based on their overall ‘presence’ in the scene. This works really well to give you an at-a-glance idea of how far away an object is relative to you – or how big it is. I also fade them when they get too far away, so now the scanner isn’t dominated so much by all the contacts and you can see by eye which one’s are most relevant. It’s a work in progress, for sure – but I’m happier with it’s current state.
I’ve also returned to the Trello Development Board’s ‘Doing’ list
and began working on navigating the galaxy again. Diving back into the code after so long has shown me how long it’s really been since I touched the game code – I’ve forgotten the intricacies of quite a lot! Returning to the Autopilot and Course systems – I’m not sure if they are subtly powerful, or overly complex… I was aiming for ‘powerful’ when I wrote them, so I have to trust my past-developer-self!
Short update on the blog about navigation http://dominium.maksw.com/2015/02/12/mini-post-navigation-wip/
Just a quick update to keep the cog’s whirring…
I’ve continued working on the auto-pilot/navigation/scene management this week, chipping away at the iceberg that is neatly analogous to the systems I’m working with. One third of it ‘visible’ to the player, the other two thirds lurking under the surface and hidden away from sight.
I’ve made great headway, and now can plot a course across the galaxy that neatly exits the current system, and the hops from star to star, entering and leaving each star system until it gets to your chosen destination.
Nice video from MaSW demonstrating the navigation concept. http://dominium.maksw.com/2015/02/21/navigating-the-galaxy-part-one/
New player ship model. http://dominium.maksw.com/2013/12/27/tiny-update/
Malsw how about showing the new player ship in technical drawing format ie top, side, front, back ect as you can't see much in the screen shots.
My shame Pinback! I didn't spot this request - I'll see what I can do 😉 And here I'll do a round up of all other queries/suggestions I've neglected on this forum to date - my sincere apologies, but my time/health/life et al - no excuse, but a reason...
And thanks for keeping tabs on the old project here - again - it's still appreciated 🙂
Hope he goes with some self illumination on the ships ie ship lights as Star Trek TMP or Babylon 5.
You're darn tootin'! The intent is also to hook these into the ships power systems, so when damaged, they start flickering, and go off altogether if the power system fails. This will take some doing as daft as that sounds - due to the way self-illumination is handled at the game asset level for games. But, I have some ideas 😉
Nice lets see a turn table vid Maksw.
Coming right up sir...
Nice lets see a turn table vid Maksw.
Still uploading though - so check back in an hour or so. Got a problem with the shadow rendering on this one... *
* Notes down in bug list...
ATM, this is the best I can do - though I like the idea of technical/blueprints. I'm tinkering with something similar for the in-game ship status/review systems... but it's a nice idea to use for PR images as well. The 'turntable' request also has dragged something I planned during the last Kickstarter back into life... if I get chance soon, I'll see if I can do a bit better than 'videos' of the ships... 😉
Here is the Alliance 'Cobalt' Cruiser, atm, all yours when you start a 'Jack of All Trades' game in Dominium... the ship is configurable; the rear atmospheric stabiliser wings, and four engine pods are upgrades to be bought, along with the equipment pods mounted along the upper hull, and the additional cargo pods on the lower mid-section.
Looks great maksw and the skin it has almost looks anime feel to it. But that cruiser looks great and are most of the ships going to have this style?
Nice on Maksw 😎
Just as a thought if you doing turntables it might be worthwhile showing any other feature of the ship as in Landing gear or parts which can be added on.
Looks great maksw and the skin it has almost looks anime feel to it. But that cruiser looks great and are most of the ships going to have this style?
Cheers - though no credit assumed by moi 😉 'Style' is going to be down to the race which builds the ships, each being different - at least that's the plan. But as for 'look' - they will / should all look 'realistic'. The texture palette on the skin for this one is a bit muted, so with the shaders in use it lends it a slightly anime look I'd agree.
Nice on Maksw 😎
Just as a thought if you doing turntables it might be worthwhile showing any other feature of the ship as in Landing gear or parts which can be added on.
I'd love to - time is the only limiting factor tbh. But, I'm tinkering with this 'idea' I resurrected, and if that at least comes off, this may have a chance of happening 😉
New update from MakSW. http://dominium.maksw.com/2015/03/01/darn-unity3d-fail/
Further to my hinting in the last post, I have to reveal a minor failure – or rather, a hurdle which I don’t have the time or inclination to jump.
Back in the last kickstarter, the idea of a ‘demo’ executable to show ships, stations et al came about – and this evolved into using Unity3D (free) to produce a webplayer – the ultimate in cool-some which would let me simply drop new models in for all to see.
Sadly – the mesh/material system in Unity3D is too rigid to make it easy to do that. 666 (Dom’s game engine) allows multiple materials per mesh, per model. Unity3d (as far as I can determine) only allows one material, per model. I’m not interested in reworking the models just to satisfy Unity3D. I may be wrong, I don’t know Unity3D well enough, but that’s the wall I’ve hit after quite a bit of research.
I wanted a web player which would let you select from a list of vessels and space stations – and then I’d update it over time with new toys (like exploring hard points, sub-systems, etc.) Ah well!
Anyway, for the fun of it – here is the result of my hours worth of experimentation over the past few months; http://dominium.maksw.com/test/shipviewer/viewer.html
Middle mouse button to zoom in/out.
Another plug in that requires updating before I can see anything.
Short update from the blog. http://dominium.maksw.com/2015/03/14/mini-update-local-system-map/
Just a quick update – having realised the dev/debug value of plotting routes in the GUI map system in-game, I decided to bring implementing the local system map forward. This will be the ‘RTS’ like tactical scanner/map for the immediate space around your ship(s). As such, it will show everything in immediate scanning range, waypoints, courses plotted by the NavCom and so on. Which is great for me as I can then see the results of the visibility culling code, movement of ships/fleets/flocks, the states of the NPC pilot AI’s, all in a nice GUI!
It’s actually turned out easier than I thought (meaning it’s turned out as easily as I planned!). I simply created a new GUI panel, derived from the ‘Map’ class in the code, and then told it to render the entire local scene graph and ‘boom’ – one scanner! It’s also proved useful already – showing me some NPC vessels teleporting, and also getting stuck in some odd repeat/cyclic navigation loops.
More to follow…
Short update from the blog about the GUI http://dominium.maksw.com/2015/03/25/mini-update-buttons/
Another progress update on the GUI work of late…
The Local Map is in place, and it’s inspired some more design choices which I’ll reveal when I get them in place in a video to show it all off. So far it works a treat, but needs the usual ‘polish’.
It’s logically led me to more interactive elements for the GUI, namely Buttons. So far I had a rudimentary table row / table cell setup which lets me buy/sell commodities in the trade window, but it was always a ‘make-it-work’ solution. Now I’m looking at the likes of tool bars, and enabling the auto-pilot from a button, I need to have a more general structure to allow me to click on items, toggle them on/off, and so on.
So, the past copule of week or so’s ‘spare time’ dev (about 2 hours
) has been all about refactoring that ‘make-it-work’ code out and creating a nice new lump of code for handling various button states, and sending messages out when triggered. All the GUI is configurable from XML files at the moment, which was always the plan to make it ‘moddable’. Off the back of that I’ll collate all the messages that the GUI can issue into a list – so (eventually) the player can customise as much of the GUI as I can support.
I want to wrap up this latest GUI dev-effort before I start looking at the wider issues (like the looping NPC-autopilots!).
Other than that – I’m up to rolling in the edits for Chapter 11 of Insurmountable Odds, with Chapter 12 about to be sent out for proof reading.
Mini update GUI. http://dominium.maksw.com/2015/04/06/mini-update-gui-gui-gooey/
Mini Update : GUI, GUI, Gooey…
I’m afraid the dullness of the updates continues as I get immersed in the mire of GUI… I’ve worked on many GUI’s in the past, and that experience told me that two rules apply to GUI design/development…
1) you will rarely ever make the ‘perfect’ GUI
2) you can easily get lost in the morass of user interactions, animations, timing, enable/disable states, easy theming, easy customisation and so on.
It is possible to do the perfect GUI of course – it just takes time and skill. Modesty aside, I just don’t have the time!
Anyhow, I now have a button (woo-hoo!) and can knock up toolbars with ease – keeping as much as possible customisable via XML files. I can see some challenges ahead with the current solution – such as theming the entire GUI (as every UI ‘window’ has it’s own XML file) but that’s a problem for a later time, should I decide to go with theming. If I only end up with 8 windows, theming is little help and not worth the dev effort of supporting it. If I end up with 38… well, that’s a different story.
update read more on the blog http://dominium.maksw.com/2015/05/06/gassing-away/
As a pleasant distraction from the world of GUI, I have turned my sights onto Nebulas, and general gas cloud rendering, as I want some nice stellar scale scenery to fly through as I navigate my way across the Cluster. I’ve been champing at the bit to have a crack at this for a long time! Progress is going well
Pictures say a thousand words Maksw.
And a min one about the book http://dominium.maksw.com/2015/05/11/momentous-mini-update/
..
Pictures say a thousand words Maksw.
Patience Pinback-san, patience... 😉 An article on the Nebula Experiments (the first of hopefully many) is under way...
Spotted the vid on YouTube.
Nice update from Maksw about working on the games UI 😎
Can't remember if there is any cockpit views in the game although being able to move windows around the screen may prove problematic to any static cockpit view unless it can be reconfigured on the fly.
I am 50/50 on cockpit views, but only because of logistics. I'd love to have them, especially as I want the player to wander around their ship in person. But the main challenge with them is actually getting unique cockpits for all the possible ships in Dom (and there are already a lot) - especially fighters or small crew vessels. Right now the aim is that this GUI is direclty realised 'in your head' with nano-integration technology. (This will become apparent when I actually release the first book, Insurmountable Odds.)
You're right to wonder how this could relate with a fixed cockpit view, I'd have to ensure the 'real' interior does not conflict with the 'fake' GUI. My plan at the moment (subject to change) is that your 'integrations' will interface with the ship you are in, and your internal 'GUI' will configure itself to suit, even to the extent of simulating holographic instrumentation within the actual cockpit which stays put as you looked about. (Think HoloLens / Occulus Rift).
Plenty of fun to be had with GUI!
Will you be able to make the windows boarders invisible?.
Might be an idea to leave cockpit views for modder to do if you are going to have a large number of ships in the game.
New update about work on the NPC. http://dominium.maksw.com/2015/06/19/never-fear-the-npcs-are-here/
Never fear, the NPC’s are here…
… well, they are on the way at least
So the past week or so has been about the Non-player Character behaviours. The NPC’s are controlled by Finite State Machines at present, with basic state controllers which will grow more complex over time.
This week I’ve been tidying up the hacks made to date whilst experimenting, and consolidating the ‘Trader’ behaviour for docking/undocking and generally pottering about the local scene. This includes creating a ‘state map’ – a spreadsheet which shows the initial state, and the conditions required to change to another state. This is essential as all the possible combinations can drive you mad, and testing them is even worse!
Update about docking http://dominium.maksw.com/2015/07/03/docking-almost-complete/
Docking (almost) Complete
Published on July 3, 2015, by Mak - Posted in Design, Dev, General 0
I admit I have derailed myself somewhat from the NPC work of getting them to dock en masse, but trust me it’s worthy and with the best intentions at heart It’s all aligned to getting back to the NPC’s docking / undocking behaviour.
The past week has seen more than the usual amount of dev effort, as an adjustment of 10 mins to my commute (ie. I get up 10 mins earlier) means I can spend almost an extra half hour working on Dom per day! All of this has gone into implementing/fixing the Scene Instancing system within 666, though sadly (and to my shame) most of that was wasted due to failing to spot one simple line of code in the exporter which broke everything, and took quite a while to figure out.
As mentioned previously – I want to be able to create a single model/module, with markup for docking, lights, collision etc. and then use this as a building block for a much larger and far more complex object. Hive stations (which you can see in the image on this post) are ‘dual 12 geodesic‘ constructs (basically like a leather football) made of twelve pentagons, and (in the current form) twenty hexagons.
One for a video.
New update on the docking. http://dominium.maksw.com/2015/07/11/docking-complete/
Phew! It’s been a big week for development in Dominium, so bear with me…
Firstly, Insurmountable Odds is now back from it’s guaranteed-honest-guv last proof read. Wendy has spotted more minor errors which I’ll now clean up. I’ve also done some quick research on the various ePub channels though there is still a lot of groundwork to do.
NPC’s are now docking/undocking from the Hive station – I’ve had to make a number of refactors/changes to the code with the instanced Hive scene, as the first pass led to 480 docking waypoints being added which choked the entire scene graph
Now docking waypoints are only created on demand when someone asks to dock and a reservation is granted. I’ve also had to address the scene setup in the Scene Context Manager, which is responsible for deciding what vessels are present in the scene when you arrive, and how they behave (Trader, Pirate, etc). Now it can configure vessels as already docked in the station, so it looks a bit more realistic. Next on the list is getting new vessels to arrive as time goes by, and also allow existing vessels to leave the scene for stars afar as they go about their business.
The instance station scene has caused an issue with the shadow mapping system – one I knew would happen. I know what to do to solve it, but I’m not 100% sure on how to actually implement the solution, so for now I’ll have to disable shadow mapping on the station to get a video done. I also have to fix up the point light system to work with the instancing – and wire them up to the docking bays (you’ll see what this means when I get it done and shoot a video…).
Also, none of the vessels care about orientation – they just dock/undock at crazy angles – I’ve yet to add docking ‘volumes’ to determine if a vessel can fit, or orient itself to the docking bay so it looks ‘sensible’.
So work done, lots of work! but still plenty more to be done!
Couple of updates, first one about the docking more about it on the blog. http://dominium.maksw.com/2015/08/07/flight-of-the-navigators/
This week I have been (largely) working on improving the autopilot course plotting, notably to improve the visuals when docking/undocking for both the player and NPC’s.
I got fed up of flying through the station geometry, and being taken on wild erratic loops before heading for the waypoints
Right now (more or less) things run smoothly, with the AP’s (autopilots) able to avoid the station itself, and loop around it to head for the approach waypoints and then on into the docking bays themselves. All of this code is totally ‘generic’ – meaning I can plug a Docking Module into a large carrier vessel, space station, asteroid outpost, etc. and the AP will happily dock/undock without complaint. There is some polish left to do (such as smoothing the course plots a bit better, and also following moving waypoints for carrier vessels in transit), but overall this is another todo tickbox ticked!
Second one about the model viewer http://dominium.maksw.com/2015/08/08/live-dominium-model-viewer-at-last/ go have a looks at this as you can rotate and zoom in on the ship as well as read some notes about different parts. 😎
Another sketchFab http://dominium.maksw.com/2015/08/19/another-sketchfab-update/ this time a light fighter.
Latest Post: game crash ... Our newest member: for4dscatterpink21 Recent Posts Unread Posts
