Star Citizen, Roberts Space Industries - Chris Roberts' life support and retirement fund [2012-]

Alpha 2.6 is out: https://robertsspaceindustries.com/...r-Citizen-Alpha-26-With-Star-Marine-Available


Since the start of the closed Alpha I've played Star Marine lots of hours and I think it's good. The movements are very fluid. The basic feeling is good and much improved over the last build. In the next patches, Star Marine will be expand by the scope and mechanics. As a former Crytek fan I have to say that I find the movement and the mutiplayer already better than in the Crytek games. If the ping is good Star Marine movement also looks much more realistic than the slapstick like Battlefield 1 movement animations. Animation work for Star Marine is top notch.

However, animations without using a weapon should be massively improved in the future:
-moving forward [W] is too fast
-walking [press "B" and then "W"] is too slow. Only a few people will use it
=the current standard forward movement speed [W] is disturbing fast. Especially in narrow space ship interiors
-->make moving forward [W] slower as now but faster than walking. Sprinting [W+SHIFT] which needs stamina should stay nearly as fast as now.


The new flight model went in the right direction.
And for PvP it is for me still by far the best flight model of all curent space games. But some values are wrong in my opinion.

First: Why should we use Afterburner? For fighting or traveling/ escaping?
When it is used for fighting, it should be about 1.5 to 2* as fast as the SCM speed and hardly consume fuel. Then they should reintroduce CRU again.

If it is used to escape and discover, then the final speed should be about three to four times as high as with SCM. The fuel consumption should increase massively so that the afterburner can only be used once or twice with the maximum speed until it is empty. Plus slow regeneration. Boost should not be consumed at SCM speeds.

The acceleration should be reduced by a total of about 20% and the acceleration in afterburner even significantly more. Brakes should last much longer than accelerating on space ships without large retrotrusthers. Everything above a cutlass should be cumbersome to control. Constellation etc. are weapons platforms. No OP Falcon from Star Wars.

In any case, the community is split. PvP professionals who have scared all other players would rather have the old even faster flight model. Casuals are now satisfied for the most part.


Let's see when 3.0 comes. This will bring most innovations at all. This will include many things they have been working on for years.
The fps performance in Persistant Universe is largely limited by the missing network culling etc. A lot of this should be fixed with 3.0.
 
Last edited:
New third person camera system is really good. This does not look like a fanmade trailer at all.


I was very impressed.

Cannot wait for player created STAR WARS looking capital ship battle trailers in the future.
 
Last edited:
Blog post from June 2016 - Here is a viewpoint of another developer who left Cryengine for the Lumberjack AWS (Cryengine) fork.
June 2nd 2016
Hello there,

My name is Aleksey Laptev, I'm experienced CRYENGINE user and game developer. I was using CryEngine since the first Far Cry Editor came out in 2005. But I've chosen to switch to Lumberyard. I'm leaving CryEngine just as hundreds of other very dedicated developers did.

I'm very happy by the fact that my favorite engine has been taken into care by such company as Amazon. And here is the explanation.

Shortly: Crytek is a terrible company to have any business with.
https://gamedev.amazon.com/forums/a...e-crytekcryengine-and-why-lumberyard-and.html
 
Last edited:
For some reason game developers are incredibly bad at keeping middleware and game engines current. It seems like they just branch off at some arbitrary point and never give a second though about staying on the current dev version.
 
If Crytek hates him and people like him why do they continue to build stuff using Crytek's tools. Can't they find something else?
Perhaps he is far far more versed with the Cryengine than the Unreal/Unity given that is what he's been using for years, not any of the other engines.
 
Perhaps he is far far more versed with the Cryengine than the Unreal/Unity given that is what he's been using for years, not any of the other engines.

Maybe if he would have switched in 2009 when he was banned from some forum he could have had some other skills by now.
 
Yes, but they are showing less because people were angry about the little new content in the last December livestream.

Still they are releasing 4 videos per week.
-Citizen of the Stars (Monday)
-Bugsmashers or Loremaker's Guide to the Galaxy (Wednesday)
-Around the Verse (Thursday)
-Happy Hour (Friday)

-one really long studio report per month
-one status update per week.
-40 - 70 pages long PDFs with many pictures and text on a topic. That is Jump Point episode.
-monthly Subscriber's Town Hall Livestream

Videos, Livestreams and the Jump Point episode are financed by the subscribers and not from the donators.

Most important show is always Around the Verse which should be published within the next 65 minutes.

___

Recently, 2.6.1 was released. Now there are servers in USA, Germany, Ireland and Australia.

Ping test: http://www.cloudping.info/

____

Then they have released Spectrum 0.3. This is something like Discord but it will be integrated into the game with VOIP.

Spectrum link: https://robertsspaceindustries.com/spectrum/community/SC

Spectrum has already shown positive elements because instead of the usual bad questions in Q&As etc. that have been asked and answered many times before they got interesting questions. This is because of CIG allowing the people to upvote questions on Spectrum.

EDIT:

ATV

https://gfycat.com/DeliriousHarmlessGazelle

They showed inter alia:
-progress in planet tech [07:00 and 8:28]
-Port / Body individual colliding zones and clothing /armor customization [46:40 -47:40 and 26:48]
-Face individualization [48:00]

The individual characterization (clothing and face) becomes extremely extensive. The layering is more dynamic than in other games.
I have not seen a customizaion like that in this quality yet. I will definitely imitate myself in this game.
 
Last edited:
Love the usage of POM decals on so many surfaces in the game (ships, character art, weapons).

Usually you just see it used on startic ground or at the best, brush geometry that does not move in games. Having it be negative in sillouhette instead of positive also gets rid of a majority of the grazing angle problems you tend to notice with POM.
vlcsnap-2017-03-10-168gaox.png

vlcsnap-2017-03-10-16sizr1.png
 
Yes, CIGs POM is advanced whereby they can apply it to many assets to give them more depth at a low performance cost.

I do not know a game with so many micro details. Let's see how the situation will be with the appearance of Squadron 42.
 
Last edited:
I am very hype with this game since its first trailer unfortunately I don't think I can play it since I'm not rich and I can't surrender my real life to life in the game to try to accomplish something there. But the game looks incredible for sure.

I'm curios, whats the current seize of the game right now?
 
My folder is 31.1 GB in size.

I'm waiting for Alpha 3.0. Due the later Alpha 3.0 release there will be more content as originally planned for 3.0. Item System 2.0 is still not finished yet and other areas such as mining made progress in this time.
 
Oh that's lower than I expected I thought it would be like 80gbs already.

Thanks

Enviado desde mi HTC One mediante Tapatalk
 
So I've been watching some youtube of Wing Commander games, reliving Prophesy & finally getting an understanding of what happened in 3/4 which I'd never played.
Got me thinking: is Star Citizen actually part of the Wing Commander universe?
 
No, EA owns the Wing Commander IP. However, Squadron 42 (singleplayer title) will be as Roberts would have done the next Wing Commander game. Maybe even bigger because of the 145,5 million USD they have got so far from the backers.

Btw
The will use Vulkan and maybe drop DX11:

"Years ago we stated our intention to support DX12, but since the introduction of Vulkan which has the same feature set and performance advantages this seemed a much more logical rendering API to use as it doesn't force our users to upgrade to Windows 10 and opens the door for a single graphics API that could be used on all Windows 7, 8, 10 & Linux. As a result our current intention is to only support Vulkan and eventually drop support for DX11 as this shouldn't effect any of our backers. DX12 would only be considered if we found it gave us a specific and substantial advantage over Vulkan. The API's really aren't that different though, 95% of the work for these APIs is to change the paradigm of the rendering pipeline, which is the same for both APIs".

Hi @RoyFokker,
I meant that in the sense that there's nothing you're seeing that's not come to you through D3D 11 - you can't mix and match APIs piece by piece, so if a feature looks a little different after one of our patches, one shouldn't think "oh, they must have moved that bit to a different API", it'll just be that we've improved it (or broken it, I guess) some other way.
The ongoing conversion work is a little hard to explain, but I'll give it a shot anyway. Bear in mind that I'm not the guy doing it...
Adding in support for a new API could theoretically be a somewhat straightforward job. Since CryEngine has had to support a ton of different ones in its history - D3D9, OpenGL, various console flavours - most of our code talks to wrappers of varying thickness to avoid having to go back and rewrite everything whenever a new one comes along. There are always a few oddities, Lumberyard for instance has added some mysterious (to me) conditional code to deal with how memory works on some mobile platforms, and there's bits left over from CryEngine supporting the 360, but let's ignore them.
What happens, though, if you naïvely port from a higher-level API to a lower level one, as in the case of D3D11 to D3D12 or Vulkan, is that you strip away a layer of driver complexity, and then writing almost the same stuff yourself in the wrapper layer because the code outside the wrapper assumed the conveniences and limitations of what was there before.
That might seem kind of abstract, so I'll give a concrete example. Under D3D11, when you want a texture loaded on the GPU, you just hand the driver some memory and it gives you back a handle. If you load more than will fit into GPU memory, the driver quietly works out what's best to swap out into normal memory and you don't even know it happened, besides the performance cost. With the new APIs, you're responsible for reserving the right sizes of memory, resizing and swapping where appropriate, etc. Theoretically that's far more efficient, you know what you want where and less stuff gets moved around, but if your outside-wrapper code is still trying to add and remove things without warning, your wrapper just ends up having to handle every possible case anyway, only now you don't have the advantage of a decade of fine tuning by your hardware vendor, so a lot of early Mantle/D3D12 ports actually turned out to run slower rather than faster.
So a lot of the work in this conversion is about restructuring how the engine approaches render work. As one example, standardising how jobs ask for temporary memory gives us a pretty good saving even now, but also means that the engine understands the concept of allocating things from a shared pool, and so is able to ask for the right amount once we change API.
In another example, the new APIs would let us offload the work of creating command lists for the GPU onto multiple threads, but the engine previously had to do it single-threaded, so tasks were written in a way where one can depend on things that were done by the one before it. One of the sweeping changes that came through my code last year was that each piece of rendering work is now placed in a packet that can't see the others, in preparation for the work of filling and executing those packets being moved off-thread.

As you might guess from these examples, the visual improvements we're expecting from all this things like being able to push more objects for less CPU time, saving (and then spending) lots of memory, that kind of thing. It's a hard topic to talk about because there isn't really a big unique thing you can point to in the game and say "look at that magnificent Vulkan-exclusive rendering feature!", the way you could with eg. D3D11 and tessellation, but it's more that our art teams are always going to be pushing at the limits of what we can make run fast, and this should give us the ability to move those limits further up.


https://forums.robertsspaceindustries.com/discussion/comment/7596719/#Comment_7596719
 
Last edited:
Vulkan >>> D3D12 IMO, also strongly pushing Vulkan at the office.
I count that a good news, but it will delay the game for a while, it's not trivial to move to Vulkan if you want to use it to its best.
 
In my layman's understanding I can see no reason to ever use DX12 when Vulkan does basically the same thing across all platforms. Clearly I am missing something as it seems the number of DX12 games vastly outnumbers the number of Vulkan games (Doom is the only one?).
 
Back
Top