Cloud Imperium’s Chad McKinney Lead Gameplay Engineer on Star Citizen has once again been answering the community questions, taking to the forums to help enlighten us! This is a summary of 14 or so questions he answered over the last couple of days.
There’re many different ways the company engages with employees, and also each team works a bit different. For example, for the programmers on my team I have weekly 1 on 1s (I did this before the whole pandemic, but it has been good to continue them) as well as we have the typical daily scrum stand ups. On top of that we have different channels for all the different features in progress as well and also try to keep the normal daily banter in off topic channels so as to not make everything feel so sterile. Is it challenging? Yes. It was much easier for me certainly sitting right next to everyone and being able to field questions on the spot as opposed to having people trying to ping you from chat or call. It was also much easier to just lean over and show a designer something in the editor instead of trying to wrangle things from screen share etc… That said, this isn’t so different from how we operated before since the company was already highly distributed. I imagine we’ve handled this better than other studios that had previously never had to deal with so much distributed collaboration.
There was definitely a purposeful change for 3.11 with how nav-points are locked when you spool. There was a change to how child points were handled so that neighbour points outside of what we call the arrival radius and that was indeed intentional. Think of all the nav-points in the solar system as part of a large tree with the star as the root, then the planets, then the moons as children of the planets etc… There is a rule that you should only be able to see children of the nav-point you are at and its direct neighbours, but that said previously the other children would only be visible within the arrival radius. For the moons this was mainly how you saw them anyways, but this was a notable difference on the behaviour for planets as the arrival radius is much tighter compared to what we call the adoption radius (the radius that contains all of its nav-point children). This is a long-winded way to say that yes there was an intentional change, but depending on what you’re seeing and where in the solar system you are there may be a bug that slipped in.
Is it possible? Yeah, this would just need someone to go setup the shops. I can run it by the economy team.
Will we be able to store snacks in crates or buy in bulk? (follow up question)
Two things here:
1. Can we make buying bulk snacks and drink possible? Yes, and in fact I’ve seen many streamers struggle with needing to manually rebuy so much so I will bring this up with design, it would not be that difficult to add.
2. There’s a separate question here about the representation of those items in the data base. Currently in the game our persistence implementation doesn’t support a concept of stacks of items, only stacks of commodities. So, when buying in bulk it will generate unique items for each unit. However we will be adding item stacks with the iCache implementation and global persistence.
The intention was to make more player ships immune to clean up (as of the 3.11.0m PTU Patch), not less. If you’re seeing ships getting cleaned up, please report it to the issue council. (This implies that the patch notes have a typo and vehicle clean ups are up to 3 from 2).
For the loadout issue, having players able to change the loadout of the ship has some very serious runtime implications that the system is not designed to account for (for example you could modify a ship that is streamed out or very far away from you, or modify a ship in a way that would cause physics intersections). This does not necessarily mean that you will never be able to do that, but for now it is something that can lead to some very bad issues on the server.
Cargo as we have it now is not the long-term implementation goal, there will be more development to feature set, and though not everything I believe has been announced, I will just leave it at ‘this is not the end for cargo’.
The service beacons are already the beginning of a kind of contract system between players, but down the line there will be further development on what kinds of contracts can be created and the fidelity of those contracts.
Will it be a thing? Yes, and in fact most of it is already working but currently disabled, awaiting work to do on life support system.
We’ve had physicalized elevators for a long time but we actually introduced teleporting variants to solve an issue about not always wanting to build out the areas to support them as they can get very far away from the destinations, with most of it being not very interesting or notable areas along the way (or would take art time to make them notable or interesting, but maybe not the best usage of that art time). As far as when to use the teleporting vs. physical variants? Ultimately that’s up to the landing zone teams and I don’t want to speak on their behalf for the reason for the current distribution or what it might look like in the future.
We have dirt and wear shaders that are used to make things look dingy, aged, and beat up which can then be dialled back when restoring areas, a part of a larger system having to do with environmental restoration. Now exactly when/how that will be implemented in a way a player has access to is a different question, at the moment we are more focused on the higher-level system first.
What your describing wouldn’t accomplish much since just swapping to a different instance would just make the other instance run the same way, there isn’t any concern of “heating up” or “cooling down” as a limiting factor here. Not to mention everything is running virtually in AWS. Now a better question is whether there can be some kind of phasing in of the tiers of complexity needed for server meshing instead of just immediately going for the maximal implementation, and the answer to that question is yes that is possible.
No, you won’t lose things that have been entitled to your account when physical inventory goes live. Now for normal persistent items (random stuff in your ships, etc) they will get lost like when we do any persistence DB wipe.
There are ships with elevators with nested grids already, for example the reclaimer and 600i. As for why some ships are setup one way and others not, I’ll leave that to the ship content pipeline team.
Is a large proportion of the physics problems in the game due to a lack of a good library for coordinate system transformation? Are you working on a solid library for coordinate system transformations?
This is not the issue; we have a very simple and well-founded methodology for transforms in various nested coordinate systems built on what is called the Zone System. The issues that you see are more related to how collision is detected at runtime with the hull defining the physics grid, not an issue with the semantic definition of the coordinate systems or transforming between different coordinate systems.