• Advertisement

Mak

Member
  • Content count

    30
  • Joined

  • Last visited

  1. This might be a useful reference for you, if you've not come across it. I'm tinkering with a 2D platformer at the moment, and it's been a good read. http://higherorderfun.com/blog/2012/05/20/the-guide-to-implementing-2d-platformers/ They provide some detailed (and experienced) tips on how to consider tilemap collision from a platformers perspective.
  2. Renderer bells & whistles ~ pt. 2

    Very nice eppo! Now, using the Developers Rule that 'nothing you ever show, no matter how impressive, is ever good enough'... would be awesome+ to see this demo with that silvered water surface animating :)
  3. Rather than copy/paste this time, I thought I'd knock up some more pre-amble... http://dominium.maksw.com/2016/10/15/the-great-journey-part-two/ 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 ;)
  4. The Great Journey Begins

    Cheers Eck :) A very, very long way to go still - but the seeds are promising I hope...   Hmm - autopilot / docking... it's been a big area of development effort, and it's ongoing. It's by no means final, and a lot of it is 'this will have to do for now' code (TWHTDFN - not much of an acronym!), but as you're interested enough to ask... :)   The system (at present) is broken into three objects - the Autopilot, the Navigator, and the Course. You ask the Autopilot to 'fly to B from A' - it then asks the Navigator for a Course (in my case a series of courses), which it plots. This may be direct from A to B, or via a set of waypoints. If an object is between A & B, the navigator does raycasts for collisions/intersections along the course itself, and then figures out where to add intermediate points to go around the object with a suitably wide berth. This can get tricky in densely populated areas of the scene octree!   The Course itself is a simple bezier spline through the points the Navigator issues. There can be a chain of 'courses' to follow to get from A to B, depending on how many times the Navigator has to avoid an object.   The Navigator is then responsible for progress along the Course(s), and all the Autopilot does is keep things ticking and tracks your position along the course as you progress.   At the moment it is very 'on rails' - once the Autopilot is engaged, you can't fly your ship, you have to disengage it first. When I get to it, I'll allow the player to intervene and alter course, and the Autopilot can then step in afterwards to make any necessary corrections.   As for docking, this is driven by a 'Docking Module' which can be attached to anything - a base, station or vessel - instantly granting it the awesome power to have things dock with it. Markup drives the approach points, and docking points within the docking bay itself. Eventually it will have collision volumes / trigger volumes as well for the AI to utilise.   The player and NPC's all make docking requests - which are fed into a queue which is processed FIFO. If the docking bay is not busy (i.e. no one else is docking/undocking) the request is granted and it's all yours. This 'permission' will eventually expire, just in case the player decides to dawdle, or gets distracted.   The 'permission' also provides a set of waypoints through the approach to the dock, and that is then handed to the Autopilot for it to worry about. Up until recently, you could only dock/undock using the Autopilot, but I've just set things up so you can manually dock/undock at long last.   Balancing the splines is a bit of a trial... and sometimes they go a bit... OTT :) as you'll see in the next episode!
  5. The Great Journey Begins

    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]Gameplay.[/font][/color] [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] [color=rgb(58,58,58)][font=Arial][/font][/color]
  6. Planet Generation - continued

    If you're looking for resolution independent, you're best off looking to generate noise in the shader - which can be done easily by the way. In fact, you can repurpose the code you have already and lift it in. Using the shader as the workhorse eliminates most of the concerns with texture seams, especially when using 3D noise.    I've yet to get around to completing my article on Dominium's planetary terrain system, but here is a link to Acko's superb resource I used as a reference; http://acko.net/blog/making-worlds-introduction/
  7. Troubleshooting Physically-Based Content

    Nice, well formed article. Having recently 'gone PBR' in my own engine, it's great to have yet more good references for the inevitable 'When Things Go Wrong!' dramas!
  8. Hmm, could have sworn I'd already published this one... But, here it is anyway for those interested. Lessons of Lorecraft My trials and tribulations creating Insurmountable Odds, and also touching on the origins for the entire backstory behind the game universe. Enjoy! Source
  9. Weekly Roundup #54(ish)

    Screenshots now in the gallery ;)  [sharedmedia=gallery:albums:557]
  10. Dominium

    General mish-mash of screenshots from the work-in-progress Space Trade/Explore/Combat/Expansion super epic!
  11. State of Dominium

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

    Cheers Eck - I hope it will be ;) I can rustle up some screenshots no problem, will add them in here as soon as I can. In the meantime, feel free to check out http://dominium.maksw.com - where all the main action is at.   As for the formatting, it's pretty messed up eh? This was my first 'cross blog' posting using GameDev's automated RSS feed puller importing it direct from my WordPress blog RSS. Looks like I'll have to turn it off Ah well   I've just copy/pasted, and all seems well aside from the mega-huge smileys!
  13. Weekly Roundup #54(ish)

    [color=rgb(58,58,58)][font=Arial] 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 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 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 [/font][/color]
  14. Polylux Part Ducks

    Sorry, couldn't resist it 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! Source
  • Advertisement