Welcome to some more Star Citizen, today I wanted to talk about Star Citizen’s Development Model, More on the Bind Culling Delay & a call to action with the Pledge Store Interest Survey.
I want to talk very briefly about agile development. For those of you that don’t know Star Citizen uses this model for it’s game development.
It’s basically an iterative development throughout the life-cycle of the project, constant communication, and tightly-knit teams, there is less in the way of focused locked in long term planning with this approach BUT it does allow for a huge amount more responsiveness and change easily.
CIG uses small sprint teams to focus on a particular mechanic, feature or ship to typically push for a quarterly release.
The approach has it’s benefits and pitfalls, going for the Waterfall or more planned approach may have led to more simple, less good looking game with less ships and features BUT it would of been able to have a more timely release date.
That said for the scope of what Star Citizen now is, agile development probably is a better approach.
And partly with that in mind there was a Question about Bind Cullings Delay & are we likely to see it before September?
Since in the RtV it was said that all there was needed was testing after integration, any chance we can do this in a 3.2.x PTU build in order to get it implemented sooner rather having to wait 3 more months for 3.3?
Clive Johnson CIG Replied
“Not my decision but I don’t think you are likely to see Bind Culling in a 3.2.x PTU build. Without Object Container Streaming, Bind Culling causes loading stalls as entities enter the client’s range. We’re still working on being able to turn on Bind Culling in the PU, but even in the simpler test maps where we do have it working, the loading stalls are pretty frequent and noticeable. That’s fine for developers, as it gives us a way to find and fix the bugs that Bind Culling/OCS will introduce while OCS is still being worked on, but it’s probably not an experience most backers would want.
Bind Culling and OCS should give us performance improvements on clients and that is, after all, one of the big reasons for doing them in the first place. But let’s not count our chickens before they hatch. The only way to know for sure how much of difference BC/OCS will make is to finish implementing them and then measure the difference.
There are many ways to skin the performance cat. If we didn’t do BC/OCS we’d find other ways to meet our goals. No one optimization is going to be the silver bullet. It’s going to take a lot of different optimizations, each optimizing different areas of the game in different ways. We’re confident we’ll get there, it just takes a while.
I don’t work on Object Containers so take what I’m about to say with a pinch of salt.
My understanding is that an Object Container is an entity that contains other entities. What makes OCs special is that they are collapsible so we can unload the contents of an OC but keep the OC entity itself in memory. You can think of any large structure in the game (ships and even the solar system) as a hierarchy of OCs. These hierarchies of OCs form the skeletons of these structures and the engine can opt to load or unload the different parts. The skeleton is always there, but the meat on the bones can be stripped back if it isn’t needed by a client.
Possibly that was a bit of a gruesome analogy but I hope it helps get the idea across
OCS is being worked on by a small team of our engineers. When parts of the work get too big for them to handle on their own they create tasks for other teams to work on. This way we get the best of both worlds; tight focus on the core technical issues, and wider resources to help with the conversion of existing code where necessary.”
Bearded CIG Added – “Performance and stability are both iterative because fixing issues is like peeling back layers of an onion.”
Pledge Store Interest Survey
There is a Pledge Store Interest Survey that you can get involved with:
As promised earlier this year, and as part of our effort to keep building you a better and more comprehensive store, we want to know what is important to you.
To do so, we created a survey to collect some of this information. Answering it will help our team improve the store.
It should take you less than 3 min to answer.
Also, if you are interested and available in participating to user interview that would last about 20 to 30min.
It’s super important IMO to have your say anytime there is a survey or way to give feedback when asked for it by CIG.