- October 1, 2016 at 8:50 am #4548
- October 28, 2016 at 3:20 pm #4725
PROCEDURAL GENERATION OF PLANETS
This became a buzzword again with No Man’s Sky. We know how that turned out. But enough of that.
So anyway, I decided to visit the denizens of my very own sub-Reddit to enlighten them on the wanton obfuscation that’s going on regarding this nonsense. Seeing as those morons over there are just going to down vote it to oblivion, I decided to leave here as well for posterity. It all started like this:
“Given what your source has said you are arguing semantics, similar to your thoughts and implementation of seamless transitions (no I am not poking fun here you have stated your definition of it and are entitled to it). Take for example the gentleman in Minnesota who runs a business called Drive a Tank. The business is called Drive a Tank but only two of his four packages includes driving an actual tank. The other two have you driving a British FV433 Abbott SPG (self propelled gun, or self propelled artillery piece) and a British FV432 APC (armored personnel carrier). Neither of those vehicles are tanks by any definition of the term tank. Is he misleading customers? No, he states what his vehicles are. Should his business be called Drive a Tank? Who cares, in the end you get to drive something cool. Should CIG be calling it “procedurally generated planets”? Who cares, as long as the end result is good.”
Well at least you actually did the research, instead of just spewing rubbish like others tend to do.
I concede the point that right now – especially after yesterday’s AtV broadcast which shows what they are doing and how, that it’s probably all down to semantics. Why is that? Simple, because CIG themselves are to blame for yet another fiasco. If you search here on Reddit, Google, RSI forums etc, it is clear that the insinuation of procedurally generated planets implies the pure sense of the term as used by us devs over the years, and which isn’t open to interpretation.
That’s how the media, gamers – and everyone took it. Then they started thinking NMS, Battlescape, Dual Universe etc. All of which use the term and tech correctly.
Right now, this is what you see on Google when you search for Star Citizen procedural planets.
The minute Chris went on stage and called it “procedural generation of planets” – which btw my sources (and recently confirmed by Goon, TheAgent) say devs have asked Chris to stop using – he created expectations that the planets would be created as such.
Also, try reading these…
All this time, and even with the unclear methods which started all the way back to August, everyone (myself included) was under the impression that they were in fact doing procgen planets.
Then finally, the Oct 27th broadcast of AtV 3:11 made it clear that what they were in fact doing, is what most of us with experience building terrain tech, have been doing all this time. And in their StarEngine editor is no different from what you see in the likes of Grome, World Machine or with tools like Gaia (1, 2), Terrain Composer (1, 2) etc on Unity. It’s just a height map. In an editor. In which artists hand-craft most of the elements, while use the editor’s toolset to generate repeating (e.g. grass) assets, manipulating a 3D object (the Sun or star in the scene) with an attached light source etc.
All basic rudimentary stuff. What’s shocking is that as per the funding stretch goals:
They got $1m (at the $20m stretch goal) for:
“First person combat on select lawless planets. Don’t just battle on space stations and platforms… take the fight to the ground!”
And another $1m (at the $41m stretch goal) for:
“Procedural Generation R&D Team – This stretch goal will allocate funding for Cloud Imperium to develop procedural generation technology for future iterations of Star Citizen. Advanced procedural generation will be necessary for creating entire planets worth of exploration and development content. A special strike team of procedural generation-oriented developers will be assembled to make this technology a reality.”
And it’s going to take a LOT of time for ANY of that to be in the SQ42 (which has planetary missions, according to sources), let alone the PU.
The biggest problem is going to be performance. You think the game’s performance sucks now? Just wait until they finish doing the first planetary scene with all their high fidelity graphics – then you’ll see.
Then you have data storage. Storing those height maps on disk is going to be a major problem. We’re talking terrabytes of data if they even think of doing any scene that’s more than 12 sq km large.
This procgen fiasco is no different from all the other instances whereby reality takes a backseat to obfuscation. Some recent examples:
FPS headbob: they disabled headbob in fps, and all of a sudden it has a nonsensical name, “visual stabilization” to make sound like it’s something else – or some newly discovered tech.
Persistence: Same rubbish. There’s nothing persistent about Star Citizen. The ability to save and restore player data from a dB isn’t new tech, and nobody ever accused it of being “persistent” in the sense of the term as recognized in gaming tech. The game is 100% instanced, and that will never change. So no matter what is being told to backers, even if they invent some fantastic networking tech (hint: they won’t) that’s going to solve their multiplayer issues, there’s never – ever – going to be an MMO coming from this. Why? Because the design was all wrong – right from the start. All MMO games are persistent. You login, game state changes, you logout, log back in, and the state you left is no longer there. So regardless of whether or not you are on the server, the world state is consistently updated and persists. Even when servers are taken off-line, most save the entire state so that when it is brought back up, it is restored “in-place”. e.g. in Line Of Defense, you can login at a certain time, e.g. 1pm and the Sun is up, logout, come back later and it’s night time and it’s pitch dark and anything that was around during the day, is still there.
Seamless space<->planet transition: Rubbish. They’re using trigger points on the planet, in much the same way they do jump targets. Not new. Not revolutionary. Which is why in the Homestead tech-demo from the CitizenCon2016 presentation which I wrote about in my Shattered Dreams blog, you can see the area on the planetary sphere where the base is located. They jumped to it. They couldn’t pick an arbitrary point on the planet and jumped to that because it’s just a textured sphere that bears no relation to the planetary height map below. How do I know? Well watch this Universal Combat CE video (start at 12:05). I select and jump to the planet, pick a spot on the sphere, engage, and my ship appears (I use an external camera transition sequence) exactly at that spot. Why? because it’s procgen and the data for the planet, corresponds to what’s mapped to that sphere of the planet. Right now, you can download the UCCE or GALCOM Echo Squad demo on Steam and try it.
I could go on and on and on, but I’m sure that you get the idea of what I’m going on about.
So this “procedural planet” nonsense that’s now a huge bone of contention, is just more of the same. The disappointment that’s coming is when backers realize that by creating these planets the way they have, it limits the surface coverage for any planet. So instead of having large planetary surfaces – assuming they ever finish and implement it – you will end up with small planetary surfaces, with key points of interest. No different from how space has locations like ArcCorp, GrimHex etc.
The end result? Well, that’s precisely how it’s done in Line Of Defense and most games. Create a height map to define the terrain area (in LoD it’s 256 sq. km edge-to-edge). Have the artists and modelers build the assets into it. Then use scripts to add other dynamic content that’s not static (e.g. rivers, canals, bridges) in the scene. Use rendering tech for water (we use Triton), atmosphere (we use Silverlining), weather, dynamic day/night cycles etc – and a trigger point (in LoD it’s the jump gates or the location selection on the map if you are using the HAIS to go to the planet from space) to get to those locations.
That’s not procgen planets. Which, btw is what’s implemented in every single Battlecruiser and Universal Combat game since 1989. That’s why the smaller 2009 games, All Aspect Warfare & Angle Of Attack, use a different terrain tech that’s similar to what is described above.
And I opted not to do procgen in LoD because it’s a different kind of game and wouldn’t have benefited from it, seeing as I already designed the entire game’s world scope from the onset.
In conclusion, the bottom line is that, once again, backers are being sold a bill of goods that’s not representative, nor indicative of what they were promised. The $20 million stretch goal promised “First person combat on select lawless planets“. The $41 million stretch goal promised “Advanced procedural generation will be necessary for creating entire planets worth of exploration and development content“. Nothing they have shown thus far, is any of that. And my guess is that even the rudimentary FPS on planets, is a long way off, and because doing a proof-of-concept demo (as in Homestead) with a single player in a heavily scripted environment, is a lot different from the actual implementation for multiplayer. And that was promised in the 3.0 patch which was promised “end of this year“.October 11, 2016 at 10:26 am #4589
QUICK THOUGHTS ON STAR CITIZEN GAMESCOM 2016
The presentation was bullshit. All of it. It’s staged using an R&D dev branch which was already shown two weeks ago and CLEARLY STATED BY THE DEVS to be in R&D and (I quote): may never be done. Meanwhile, during the stream ahead of the show, this is the ganky 2.5 patch that paid streamers were playing.
Sources say it was heavily scripted, and even that quest giver animation was done last month specifically for THIS canned/scripted Gamescom presentation.
Even the barren moon used for the procgen, anyone with access to CryEngine can put together in a weekend.
Note that they did this SAME thing ELEVEN months ago when it too was “coming soon”. That was the Nyx (https://vimeo.com/137655209) base. Still MIA.
Aside from that, this was 2 clients in a controlled environment on a private local LAN server. Which is NOT indicative of the shit that was being streamed just days before at the show. And THAT version which is the 2.4x kernel, is still largely broken. Which, when you think about it, is hilarious that the 2.5 build they were hoping to use, is somehow a LOT worse than that one; so they couldn’t even use it.
It’s all designed to show “progress” where there is none. This was more to appease the whales (stuck in Sunk Cost Fallacy), and somehow con new gamers into giving them money because they DO need the new money.
Thing is, if this was 2 years ago, and they hadn’t done this SAME SHIT before with various builds at PAX, GDC, E3, Gamescom, CitizenCon, nobody would care. But now, FIVE years – and going into year SIX and $119m later, this is still a pre-Alpha proof-of-concept tech demo that’s nothing more than a glorified CryEngine mod.
Then there’s Star Marine which they shit-canned months back. I wrote a huge blog about it amid the uproar. Then Chris went on the record and said that he was “annoyed” that people are asking about something that was “already in the game”. Yes. With a straight face, he said that SM was already in the PU and being played.
Now that State and Fed officials are looking up their skirt, and given the fact that Star Marine – as a separate module – was PROMISED and PROMOTED for over FOUR years, all of a sudden, it’s back again. That’s what happens when you start to worry about the legal liabilities of your actions.
Not to mention the fact that the games were due out in Nov 2014. It’s now Aug 2016. And neither Star Citizen nor SQ42 is going to be released before year end. So this Nov makes BOTH of them TWO YEARS late.
NONE of this sways my opinion about the game. They can’t build it. They don’t have the tech. They don’t have the expertise. And now they’ve run out of TIME and MONEY.
Anyone who thinks this “game” is ever seeing the light of day, should just ignore me and go give them money.
To be CLEAR: This is NOT about raging against them for “trying”. It’s about HOW they’ve LIED CONSISTENTLY while raising money for a game they KNOW FULLY WELL they can’t build. Also, it’s not about whether or not it’s alpha, pre-alpha, a tech demo or any of that. It’s about THIS being WHAT they have FIVE years and $119 MILLION dollars later. Anyone who thinks that’s somehow OK, SHOULD go give them money. Long after this shit-show collapses, most of us will just be staring into the abyss where dreams go to die.
It’s amazing to me how Shitizens are claiming “victory” over a scripted demo based on wonky R&D. Like the games were suddenly delivered. Even as they conveniently ignore/forget that CIG have done this same very thing many times before and NONE of that is IN the game right now. Shitizens wanted “something” to tide them for the next 6 months. then come Dec 2016, they’re going to (again) pretend Gamescom 2016 never happened. Meanwhile, they’re completely oblivious to the fact that NEITHER Star Citizen now SQ42 is a 2016 release & BOTH will be 2 YEARS late in Nov 2016
Then there’s this…October 1, 2016 at 8:51 am #4550
THE NEW RADAR SYSTEM
So in the most recent AtV 3.9 broadcast, the F42 guys showed (start at 5:26) off the new and upcoming radar system. Shortly thereafter, the most vocal community backers were up in arms, quickly expressing [misplaced] outrage, and dubbing it “golf swing radar“. A thread (with over 26 pages) on the forums was quickly
moved to concern, away from the main forum threaddeleted. Shortly after, another thread (30 pages as of this writing) popped up; this time with a poll. That one was moved to the concern forum once CIG/RSI got wind of it.
It’s much ado about nothing.
As a systems designer and someone who has developed some of the most complex (go play any of my Battlecruiser/Universal Combat games if you think this is hyperbole) systems in a space combat sim, I quite like how they implemented it. It looks cool, straightforward and functionally sound. Plus (and this is a biggie), they unified it across the infantry and ships. I did the same thing in my BC/UC games, whereby even the NPC infantry characters, have some sort of radar system which not only detects sounds, but also prioritized based on range and elevation.
What’s lost in the translation I think, is how the dev described it. But the fact of the matter is that he described it correctly for the layman to understand how it works. On the face of it, the system is no different from any other implementation of a “power up” mechanic in hundreds of games. So this outrage is completely misplaced I think. Plus, he also stated that it’s a first iteration, and that LA is going to be running with it. Which means that they are going to be tweaking and fine tuning it along the way.
The issue that I have with this system is that unless you’re going to be doing this “scanning” while stationery or moving at low speed, it’s going to be quite cumbersome to use – if you’re the pilot. Using a mechanic such as this, whereby the player needs to provide constant input, is counter-intuitive and misplaced in a game like this. Heck, even the most hardcore air combat sims don’t do it like this. I think it should be implemented as a fire-and-forget type system, but with simple key presses to activate whatever modes (e.g. ACTIVE vs PASSIVE) they want. Then all the benefits and restrictions are embedded within those modes.
In games of this type, the operation of a radar system is usually automated (it’s not like this is a realistic air combat game which requires accuracy and fidelity). You plot the targets, give the radar a range, give the player a way to select targets etc. You can also differentiate the radar op based on range, elevation, altitude (if on planet surface), target cross-section size, op mode etc. You can literally go crazy with it.
If they wanted to implement this as a “skill” (which is precisely what I think they’re going for) based op for multi-crew ships in which one player is going to be using this; then this is probably the way to do it. It’s not like the pilot is going to be doing any of this; in much the same way that a turret gunner isn’t expected to fly a multi-crew ship.
But here’s the problem which all multiplayer games which require player cooperation, run into: who the frack wants to be sat there, in a chair, pissing around with a game mechanic which, for all intent and purposes, doesn’t provide the same instant gratification and satisfaction as any other game mechanic? I don’t care what some of these guys keep dreaming up, even as they theory craft their way through a litany of pure and utter BS (which not even Chris Roberts has promised they could do in the game); when it comes down to it, most of them won’t want to be that guy. In games which require player co-operation, there is always “fun” stuff for all player classes to use. e.g. a medic, a tank etc. In a game like this, there is nothing fun about a skill based radar system, no matter how it’s implemented. Again, this is all assuming they are targeting this as a skill based system. If they aren’t, then this point is moot.
At the end of the day, it’s all down to user experience. If they keep it this way, in which it’s a timed “progress bar” type system which requires constant input (among other things), instead of just a fire-and-forget key input (which can also have the progress bar as it powers up and activates), it will be a complete disaster. And then they will have to do what they always do: go back in, rip it all out, or nerf it. Time wasted.
My suggestion would be to keep everything as-is, but instead of the constant “golf swing” input, simply make it a fire-and-forget mode change input. e.g. passive is the default, then you press a key, and it switches to active, which then initiates the same progress bar. Then, it could be that once the player (pilot or other) switches modes, the pilot would have to keep the ship pointed at the target in order for the progress bar scan to complete quickly. Doing it this way also allows the player to operate the radar system, even without a co-op player. And in the event of a co-op player, perhaps the ability to select multiple targets based on priority (which the pilot may not be aware of; especially in a combat situation), is the add-on benefit. The other benefit to this is that it would work in all ship types, since it gives the pilot autonomy, but at a cost.
FYI, I don’t believe this is a QTE (QuickTime Event) they are showing as the progress bar. It just looks like a Flash based UI (probably using Scaleform or similar; we use Iggy in LoD) animation.
The radar system in my BC/UC games is quite complex under the hood, and I did my best to not expose too much of that to the user. Read how it works on p27 of the UCCE 3.0 game docs.
The forum ‘Main’ is closed to new topics and replies.