Comm-Link:Monthly Report - May 2016
As most of you know, we’ve been working hard to launch Star Citizen Alpha 2.4 this month. The patch is currently on the PTU undergoing testing from our backers. As they can attest, we’re battling some blockers largely related to networking. We’re making good progress, and will keep you updated… we’re as eager as anyone to see our backers battling it out aboard Starfarers, shopping for clothes and earning in-game currency. Meanwhile, development goes on for all aspects of Star Citizen and Squadron 42, whether they’re intended for Alpha 2.4 or a future release. Without further ado, here’s May, 2016 straight from the developers that lived it!
- 1 CIG LOS ANGELES
- 2 CIG AUSTIN
- 3 FOUNDRY 42 UK
- 4 FOUNDRY 42 DE
- 5 BHVR
- 6 TURBULENT
- 7 COMMUNITY
- 8 THE WRAP-UP
CIG LOS ANGELES
West Coast, Best Coast
Hello Citizens of the Stars. Once again it is that time where we share what our developers in the City of Angels have been up to. Needless to say, getting 2.4.0 out the door has completely dominated all of our schedules. Ensuring we release a quality product to you is always our top priority; however, doing so requires quite a large amount of attention to detail when you are attempting to create one of the most technically advanced games ever. So let us recount what each team at the CIG-LA office has been up to during what has been an unusually overcast-weathered month of May.
Much of what is happening in 2.4.0 is based upon what the Engineering team has been laying down tracks for. Shopping, persistence, bug fixes, and so much more. While Mark Abent has been focused on the 2.4 Phys Controller and Seat Integration, he and Paul Reindell have been helping the Engineering team in supporting the Persistence and Shopping features.
Ariel Xu has still been poring over his Port Editor and Loadout Editor and has recently implemented simulation parameters into the Loadout Editor. This will allow simulations between similar assets such as collision proxies, ropes, etc. These kinds of internally-built tools help streamline the design and engineering process.
Chad Zamzow has started working on Coolers and Heat Sinks, updating the technical design document and has started testing the system in ships along with testing the functionality of how IR and heat signatures can be tuned. While Patrick Mathieu has done a code merge for the Seats and Controller managers, he has also had a hand in several other systems such as the Energy Control Manager (for power plants), Flight Controls, and the game’s event system. Chad McKinney wrote a technical design doc for the engineers on Signal Pipes after he worked on the Entity Health components (essentially the wear & tear functionality of components that are being sync’d with Tech Design). Chad has also been helping the QA team by providing custom builds for QA to test very specific parameters of the game. Flight Engineer John Pritchett has also been hard at work, currently in the UK office working on positional controls for capital-class ships.
Being a Technical Designer is much more than coming up with game design ideas. A Technical Designer has to know how these systems and designs are able to function within the game based on certain parameters such as game engine limitations, resources, etc. With those things in mind, Lead Tech Designer Kirk Tome has started testing the Power Plants and Shields 2.0 systems along with designing an overview of how overheating/heat spiking will affect ship components. On the ship side, Kirk has also been working on the Origin 85x and coordinating efforts with the Engineering team on how heat and wear will function in terms of design.
Along with ship systems, as many of our astute readers know, the Tech Design team also performs the designing of how ship functionality will operate in-game. Calix Reneau has started working on the F7A Hornet, the Prowler, and space stations while Matt Sherman has been working on the white box for the long-awaited Drake Herald all while getting the Reliant flight-ready.
Matt has also been working on supporting the newly-revealed Buccaneer and has also added some much needed updates to the Carrack design brief. There is a touch of Exploration he has been peering into but let’s wait until next month’s report so we can report on what he has accomplished thus far.
The LA Tech Design team was also joined by a new member, Stephen Hosmer. So stay tuned for next month’s report to see what our newest Tech Designer will have accomplished by then.
Art & Animation
The Art team was joined by our new Character Art Director, Josh Herman, who brings quite a bit of experience with him in regards to characters and delivering the highest of quality.
CG Supervisor Forrest Stephan has not only been working on clothing support for the character team for 2.4.0, his efforts also look steps beyond what we are currently delivering and extend out to 2.5.0 and further.
A large number of the artists have been dedicated to building the upcoming Caterpillar. Gurmukh Bhasin and Justin Wentz, our ship Concept Artists, have been doing exterior passes of the Caterpillar. This included adjusting the Command Module, turrets, decals, tractor beam room, engines and cargo, as well as the materials pass. On the interior side, Daniel Kamentsky and “Jin” Hyun have been busy with the interior cargo module.
The other half of the CIG LA Art staff continues to work on character art. Omar Aweidah and Cheyne Hessler’s bespoke character hair is currently in progress and looking fabulous while Jeremiah Lee’s costume concepts have been perfected and approved to move into production.
Global Technical Content
As we have explained in the past, the Global Tech Content team is a difficult one to categorize because it extends into everything we do at CIG at a global level. We had a new Associate Tech Animator join the team and are excited he’s here! Erik Link started this month and will be working with our animation team so stay tuned for next month’s report to see what accomplishments he has contributed to the team. But for now, Erik has been working on cleaning up Mannequin and digging deep into our systems to help increase our deliveries.
Last month we reported Gaige Hallman had been working on the clothing volume system to determine how clipping will work. While a few related bugs have popped up, Gaige was pretty swift at getting them resolved and has been working on asset rigging for the Shubin Miner uniform, while John Riggs has been working on fixing the Vanduul Hand Geo and Skeleton just to name a few.
Matt Intrieri, apart from working on asset validation tool, he has started on the Tech Art white box for the Drake Herald while Patrick Salerno has been working on the Reliant grey box Tech Art. Last but not least, Mark McCall completed working on skinning and implementing the RSI Pilot Flight Suit Jetpack.
Continuing from our last update:
Squadron 42, Squadron 42, Squadron 42.
Yeah, we were on full-blast for the past month. Both Will and I were over in the UK to help out with the pick-up performance capture shoot. We got to have some familiar faces back to the set as well as some new actors join the show. We were thrilled to have on set to play the role of . It went better than any of us could’ve imagined and was spectacular to watch this character who’s been kicking around for a while, finally be brought to life in such a dynamic way.
Otherwise, on the PU front we’ve been delving into things that shan’t be made public yet, so unfortunately there’s not a lot to tell.
Now, back to the mines of Squadron 42.
Oh, if you haven’t heard, there has been a revamping of the Ask A Dev forum thread. We’ve just started to dive back in and answer your questions, but if you had a question that was still unanswered from the old Ask A Dev – Lore thread, feel free to repost it in the new one and we will do our best to get to it, progress permitting.
As I was saying, until next month.
This month the CIG-LA Quality Assurance team was all hands on deck and focused on all the new 2.4 features, including the new PU Clothing, and the shopping system, a vast amount of persistence and performance testing, and help troubleshoot stability issues. Saitek was gracious enough to provide us with a Saitek X-56 Rhino H.O.T.A.S. peripheral so we were able to put the controller through its paces after a very short fight over who got to use it first. However, the most exciting thing this month was the privilege of an early look at preliminary large scale solar systems with procedural planets, going from space, to atmosphere, and eventually landing on the ground. At this point the terrain is visually pretty sparse looking, but this early on, the excitement is about the technology itself. There’s nothing quite like flying through and around canyons in an M50!
There you have it folks; that was the month of May in a nutshell for us at the Los Angeles branch of Cloud Imperium Games. It should go without saying that there is much more going on behind the scenes to make all of these milestones possible and we can’t wait until you see what we unveil next.
Game Dev: Bigger in Texas
We’ve continued to crank away on 2.4.0 through the month of May. We’ve generated 145 builds from the build system; we deployed 98 internal server builds and published 14 of them to the PTU for external feedback. Everyone in the studio has been working night and day and we’ve been making a lot of great progress to support the many technological and design changes that are part of this version. We’re very excited to see this version continue its march soon to the Live server, and as you can imagine teams are already hard at work on 2.5 and beyond.
The merry month of May has been a productive one for the Austin Dev Team. We’ve spent most of the month wrapping up our tasks for 2.4.0 and planning ahead for 2.5.0. The Design Team has been polishing features in 2.4.0, specifically Shopping and Port Modification, so that they are in tip-top shape for when 2.4.0 goes Live. Robert Gaither has jumped over from QA to help out with placing all of the item ports in the hangars so that you guys are able to customize the layout of your flair objects and ships. He’s been meticulous in making sure that the item port placement makes sense for each type of flair and linking up the item ports so that placing larger flair and ships cancels out the ability to place smaller flair and ships in the immediate vicinity.
Lead Designer Rob Reininger has been polishing and fixing bugs with the Shopping experience, in addition to planning for several features coming down the pipe. We’ve got a final design for “Kiosk Purchasing” in front of CR and are awaiting feedback. This feature will allow for purchasing of items that are too large to display in a conventional shop, such as ship components, ship weapons, and the ships themselves! We’re also putting focus on designing additional phases of “Try On/Inspect Mode” where each type of clothing asset will have a specific camera record that “zooms in” to specific parts of the body depending on what you’re trying on. So for example if you’re trying on shoes, the camera will zoom in to the feet. There will also be specific “Try On” animations for the character as well so that the character can check himself out while he is trying on the latest and greatest swanky apparel.
Speaking of new swanky apparel, both Rob and Robert have been working with the Character Team to create briefs for and schedule in additional assets for future releases. Our goal from this point forward is to have new clothing assets ready for every new release. Sometimes these will just be material/texture variants of existing assets but sometimes we’ll have brand new assets from all-new clothing lines and manufacturers. Our major focus for 2.5.0 will be to have some more grungy frontier clothing ready for you guys.
Designer Pete Mackay has been iterating on the ship pricing formula he’s been working on. He’s also been designated as the Design Owner for Game Analytics going forward as well. Pete has been talking back and forth with the Gameplay Engineering Team, the Server Engineering Team, the DevOps Team, and the Platform Team to nail down the best approach for capturing and displaying game analytics from various aspects of Star Citizen. We want to know how you guys are playing so we can focus on the things you like the most and get you more of what you love, and tracking game analytics is the best way to do that.
The Backend Services Team has been furiously smashing bugs with the Persistence Backend all month in an effort to get it ready for release. This is the most massive change to our core technology we’ve had since the debut of the Large World tech, and with that comes a lot of hiccups that need ironing out. The team has been doing a great job though and we’re in the final stages of polish on this before release. We’re now looking ahead to 2.5.0 and beyond. Our near-term taskload includes Persistent UEC, which will allow us to actually use UEC as part of Persistence instead of just our test currency Alpha UEC. Ian Guthrie at Wyrmbyte has also helped us create an Analytics Service for Gameplay Engineers to hook into to provide the data that Pete Mackay needs as mentioned above. As always, we’ll be knocking out bugs with Persistence as we see them as well.
The Art and Animation Teams are trucking along with their longer-term tasks. The Ship Team is still up to their eyeballs in the work for the Hornet F7A and the Herald. Jay Brushwood has been on the set of the mocap shoot at Imaginarium the past couple weeks capturing new enter/exit animations for all the ships, which we’ll start getting in pretty soon so you guys can get in and out of your ships more quickly! Daniel Craig has wrapped up his work on the updated 300i enter/exit animations and will be moving on to the Avenger next. Our PU Team has been supporting S42 with implementing background animations. They’ve specifically been working on animations for the Mess Hall scenes and interacting with Ship Terminals. They also helped us out in a pinch by getting in some new “Weapon Inspect” animations that you can see in action while inspecting the weapons in the shops. Oh, and that death animation that happens for when a player enters an airlock without his spacesuit on? You can thank Vanessa Landeros for that!
Emre Switzer has been doing a lighting revamp for several areas of the game. He’s already tackled ArcCorp and will be moving on to Crusader next. He’ll also be touching up some of the ships as well, like the Reliant.
Lastly, we wanted to reach out and give a hearty thanks to Mark Skelton for all of his effort and devotion to this project and especially this studio. Mark has moved on to a new project and new chapter, but we wish him all the best in his future endeavors and can’t express enough how sorely he’ll be missed. Thanks Mark!
April’s 2.4.0 testing continued well into May with the build making its way to the PTU. As of this writing, QA has deployed 14 builds to the PTU since the initial release to the Evocati testers.
With the assistance of the testers on the PTU, we’ve been able to reliably reproduce a number of various issues which resulted in Code 7 disconnects. This has greatly assisted us with identifying the various causes of these disconnections, which has allowed the Network Engineers to address them as we identify them. As a result, a significant number of these specific disconnects have been corrected since the start of the PTU. We’ve also seen a number of server/client crashes fixed, as well as improvements to the Port Modification system, and a large number of fixes related to shopping. Not to mention, enough improvements in item persistence to allow us to begin persisting the database across multiple builds.
Internally, we’ve been gathering lots of server/client performance data for the Engineering team to analyze to see if there’s any improvements that can be made in the short term to help with performance while we wait on the larger improvements coming later.
We’d also like to welcome Tori Turner to the QA Team, who has been assisting our Squadron 42 testing team.
That about wraps up this month, aside from continuing 2.4.0 and Squadron 42 testing there’s nothing much new to report… well, aside from preliminary testing for Procedural Planets, as well as the first forays into the Solar System map…
May was another busy but solid month for the Game Support Team.
As everyone knows, 2.4.0 has been not just our focus, but the entire company’s focus. Chris Danks and Will Leverett spent the first part of the month with Evocati Test Flight, helping get bugs into Issue Council and then into our dev pipeline. As 2.4.0 managed to get into a state where we needed more people, we opened up to our PTU 1st Wave testers, and then Subscribers.
To build any community, you have to dedicate time and energy, and we’re very proud of the fact that CIG has allowed Game Support to do just that with both Evocati and PTU testers. We’ve put a lot of effort into making this successful, and we could not be more pleased with how awesome our volunteer testers have been. It’s really through their passion for this project that we have had such fantastic results which have helped us tremendously in our efforts to complete 2.4.0.
As a reminder, for those wanting to participate in Evocati or PTU, it’s possible through being an active member of the Issue Council. We’ll be adding to both Evocati and PTU ranks later this summer, so jump on in at https://robertsspaceindustries.com/community/issue-council!
We were also thrilled that our friends at Turbulent visited us for a week in Austin. We got to spend a healthy amount of time on a variety of topics, not the least of which is Issue Council improvements. We’ve identified a handful of requests that we’re going to start developing on, some of which came from the community, some internally. We’ll be very excited to get those out!
We’re also growing in Austin, Texas! We’ve been interviewing candidates for a Game Support role to help with various tasks such as account security, technical support, and our publishing process, and we’ll be excited to have another hand to improve the level of service we can provide.
More progress was seen on the patch reduction size project in the month of April. As previously mentioned, this is a big overhaul so it’s definitely going to be summer before we get to the point where we can roll this out to everyone but we’re hoping to start seeing real world use of the new system soon for internal testing. This month has been all about carefully incorporating the changes which support the new patching system into our build pipeline without affecting regularly scheduled deployments. This is no small task but we are making progress on schedule as we had hoped.
As we work through the build pipeline we have found that it may be possible to obtain some further optimizations in the build process. Much in the way we are breaking out data in to its smallest parts which will allow us to deliver more granular changes within our patches under the new system, we’re now identifying ways we should be able to increase granularity in our build process. If this works, we may be able to compile portions of the build down to certain individual changes further reducing dependencies on other aspects of the larger build. In other words, by reducing dependencies we might be able to kick certain types of build changes out in seconds where normally we would have to wait minutes or sometimes hours for that type of fix.
We certainly have more discovery and testing to perform but hopefully we will have much more to report in this are as our work on our huge patch project progresses.
This month we have been super busy keeping up with the dev teams work on persistence. We’ve delivered 18 publishes to PTU along with countless deployments for QA and individual use dev testing. Literally, countless deployments because at some point we lost track during the late nights. Our primary build system cranked out 145 builds generating a total of 18,350 gigs of data. Alternate build systems aren’t tracked but are doing almost as much work considering that we’re now requiring code pre-builds prior to code being checked in for the testing and production builds.
April has also been a month of spring cleaning for us. We’ve reworked a number of internal tools and docs and we’ve completed our planning for our new publish orchestration system. The goal of this project is to make our publishes more automated and configurable. Currently we have a decent system which is fairly dependable but the addition of persistence has shown us that we must be able to make a myriad of configuration changes quickly and easily rather than manually. Our new system will enable all of this for us and be much more extendable meaning we can handle changes much better than we can today. While this may not show up as a neat flashy thing that people see in the game, we’re really happy we get to do this work because it makes the job of publishing Star Citizen so much better in the long run.
FOUNDRY 42 UK
Another productive month in Manchester! Chris spent some time with the team this month working on Squadron 42, and we’re very excited to be getting closer to sharing more information on that part of the project. Here’s a report from each department about what we did this month:
Ahhh the month of May, everything is blossoming and so is the teams work – we are really getting into a groove here and the concept team are pumping out a lot of super high quality work. We’ve done a large amount of work for future ships this month, these aren’t needed for Sq42 but are needed for the persistent universe and to keep on expanding the roles in the games, we have 4 unannounced ships/vehicles in concept right now and they are almost all complete, it’s hard to choose which will be my favourite, they are all really exciting in their own way!
We’ve also continued to work heavily on ship items, mainly power plants, coolers and shield generators – look out for the Gorgon Industries – it’s got some serious bite :D Weapons are continuing both on FPS and ships, working out upgrade paths for all the different sizes of ship guns and how to be efficient with our designs but also give the fans what they’d like. Props and prop dressing has continued, the list of required props is getting longer by the day so we will take on additional resources to fill that gap so that Sq42 can look its best. That’s all for now folks!
The last few remaining art bugs for 2.4 have been ironed out, hopefully you guys will be playing it before too long as we’re looking forward to seeing what you guys think of the new features. As always the team is hard at work on Sq42 development, not too much information can be told but we are ending the Greyboxing phase for the Shubin interior levels, finishing out Final Art on some other undisclosed locations. We are still pushing forward on Final Art for our VS level, everything from lighting, materials, atmospherics, props, terrain, rocks, and buildings are being worked on. That’s all for this month folks, enjoy 2.4!
This month has been a heads down and getting things done month. After wrapping up 2.4 requests and bugs the team have been focusing on either ship items (formally components) or props to add narrative to Squadron 42. Because of the way we approach the props anything we create can be used anywhere in the game, even if we theme particular props to tell a story in one area we can then override the material and reuse the asset in another area, this means we get a bit more reuse for our time investment and it reduces art fatigue.
Ben Curtis has been spending a lot of time on documentation this month, now we have the new shader tech mentioned last month it’s time to get thorough documentation together and update some of the old ones. We have a few new starters over the next month so it’s important to have everything easy to find and refer back to, as we get more resources in the future this becomes more and more important.
Looking forward the whole team will be focusing on the ship items for a couple of sprints to make sure there is plenty of content when the feature goes live. It is going to be a busy month but we can’t wait to get all the content out to the players so you can start really customising the performance of your ships and making them your own.
Work continues on our ‘big guns,’ the Idris, Javelin and Bengal. As we reported last month, interior work on the Idris has largely wrapped up and we’ve moved to building some story-specific Squadron 42 variations… but we can’t talk about those just yet! The Javelin and Bengal exteriors are ongoing, with the latter’s team benefiting greatly from the work done on the former.
Towards the smaller end of the spectrum, work is ongoing on the F7A Hornet, which will be the hero ship for Squadron 42. We’re going for updates to the Hornet that make it clear this is a different, military-specific version, and so far the results are great! We’ll share more of that as Squadron 42 gets closer. We also completed work on ‘pods’ for the Argo transport which will let you use it for a number of different utility functions.
On the concept side, we are finishing up work on one of the ships you’ve been waiting for: the Drake Dragonfly “space motorcycle.” We think we’ve come up with a plan for a very cool, very SMALL ship that’s going to work very well alongside some upcoming game systems. More on that soon! We also pitched several designs for Aegis’ next ship. Can’t reveal more yet, but it’s a tough one!
This month the graphics team have finished off a number of features and fixes which we hope will be in the backers’ hands very soon.
The first of these is a major upgrade to the particle lighting system. Previously the particles were lit by a different system to the rest of the game, and while this was cheaper it had many visual problems such as lack of shadows and incorrect brightness or colour for some light types. We’ve now changed it so that it uses the new tiled-lighting system and so matches the rest of the lighting much better, but we’ve also added fully volumetric shadowing. This means we get accurate shafts of light passing through particles which looks very impressive in our tests and we can’t wait to see what the artists can do with this.
The tiled lighting system in general has also had a major upgrade, partly to allow the particle lighting, but primarily to achieve greater performance on modern GPUs. This has been deactivated in recent public builds but we expect it to be enabled in the next major release. While looking at the lighting we’ve also started to improve the quality of rectangular area lights. Real-time renderers need to make many compromises to achieve any form of area lighting in real time, but we’re hoping to improve the results of these because sci-fi environments so often use rectangular lights.
Our work on the various high-dynamic-ranges features continues with the completion of the light-linking feature to allow realistic levels of brightness and glow from our lights. Next we’ll be focussing on the exposure control system to make it better approximate the complexities of the human eye and brain’s amazing ability to adapt to environments which high contrast or very low light levels.
Some other more minor changes include: uncapping the GPU texture budget so that GPUs with more memory can benefit from higher texture resolutions and less likelihood of seeing any ‘popping’ from the texture streaming, completion of our internal render-profiler, continuation of our major UI refactor mentioned last month, and various bug fixes with culling.
For the engineering team, much of this month has involved 2.4.0 and helping get it into a state where we can finally release it to live. Bone has been finishing off the port modification system, allowing to customise your hangar and change your ship loadout from inside the game, and it is now complete and is in the final stages of bug fixing and polish. Similarly the shopping is all in and working and again we’re just fixing up any bugs and polish that comes along.
Our network team have been up busy fixing up the disconnection issues we’ve been finding on the PTU build. Unfortunately these have been pretty gnarly and hard to track down and fix, they’ve been coming from the changes required for persistence not playing well with the current networking system. One change required of persistence is being able to reuse entity ids, which the engine was never really designed to do, and as a result we’re having to deal with the consequences of that. Long term George is working on a new message queue system which should be able to deal with all these problems a lot better.
In-between the bug fixing and polish Craig has spent some more time on the carrier takeoff and landing, Steve has been making more progress on the Object Container system and also our entity component system, which breaks down an entity’s update into smaller individual blocks which can easily be reused. It will help clean up a lot of the codebase as well as helping on the performance side. Sadly for the UK office he’s now leaving us and moving to our sunny LA office, our loss and their gain.
Gordon’s been doing more polish work on the cover, as well as the vaulting and mantling. Romulo has been doing the player refactor and moving armour over to the new Item 2.0, as well as some weapon polish. Jens has been working on player moving and the head stabilisation.
This month, will try to keep this a bit snappier just because there’s a lot to cover. Apologies for flitting between bullet points and paragraphs!
Darren Lambourne has been busy with:
- Setting up new variable boost layer for thrusters on many ships
- 2nd Pass on BEHR Laser Cannon S5
- Reworking and fixing anim sounds across several ships, including Connie pilot/co-pilot seats. General stock-take of missing audio
- Beginning setup of the AEGS Idris audio scheme
- General bugfixing across several ships
Luke Hatton has been working on:
- The cockpit interactive user-interface sound, adding sounds for the power distribution triangle and shield distribution
- The Aurora series now have their own pass-by whoosh sounds and should be more easily distinguished when flying past you
- On the FPS side, sounds for hitting targets with projectile weapons have gone in, along with kill confirmation sounds for both friendly and enemy characters
Stefan Rutherford performed something akin to open-heart bypass surgery on the Wwise project side of things – he generally maintains this, ably assisted by Jason Cobb. We’ve put a lot of thought recently into how the game will be mixed (both for S42 and the Live release) and as part of ensuring things work and scale this needed doing. On top of this, he produced new FPS weapon sounds and editing up the recent weapon recording session material.
Both Phil Smallwood and Bob Rissolo were on-set at Imaginarium to continue with recording duties for our monumental Squadron 42 cinematics. Our lovely new dialogue rig, the D1000 got its first major run out, which Phil’s been debugging a little, smoothing any rough edges. Both returned to master and edit the resultant dialogue.
Matteo Cerquone has mostly worked on Squadron 42 ambiences, with Ross; assisted with checking fidelity of sounds affected by a wholesale conversion settings change in Wwise (part of a general optimisation pass), and cleaning up old Foley events in the character tool.
Ross Tregenza did:
- A lot more work on the Music Logic system – it now has huge web of fully functional states combined with a growing web of momentary stings, and all new music in place, it’s also beginning to expand beyond space-flight music into FPS & EVA
- Squadron 42 level ambient sounds – the levels are advancing well with Ross and Matteo starting to add a load of ambient audio to the spaces, lots of levels really starting to come alive there.
- Battle-chatter – working with the AI guys to start getting the battle-chatter dialogue systems up and running properly
Simon Price has continued laying down pieces of the dialogue pipeline, improving the scalability of it over the last month. Most recently he’s been working on migrating dialogue data over to use external sources. Perhaps that doesn’t seem hugely exciting but it’s part of the overall ethos of keeping things sensible and not overloading the Wwise project with duplicated structure.
Sam Hall has been working on a system for dynamically loading audio assets, to ensure we only have loaded in memory what’s absolutely necessary. Different kinds of sounds have different requirements as to how resident they tend to need to be; some kinds (such as ambient sounds that aren’t required to synchronize too much) can stream in, and any kind of latency isn’t perceptible or appreciable. Others, such as gunshots that the player triggers, need to be ready to go instantly. So after sorting through what needs to be resident and what doesn’t, it’s been a question of ensuring the system can bring in audio assets to memory as soon as they’re needed in each case. For a game such as ours it’s important we only have loaded, what’s important to the player; loading everything won’t be an option while scaling up of the universe continues apace.
Sam’s also been adding more music logic events and parameter tweaks to improve the dynamic music experience. And of course has been fixing audio bugs as they’ve arisen.
Graham Phillipson’s been busy on the in-game VOIP tech, we’ve actually had something that we could demo internally as a result of this which went down well – of course, we’re really keen on getting this out to the community. Adding to the ability for the community to, well, commune, I think it’s going to be a huge benefit for everyone and it’s been great to hear it in action. Standard audio bug fixing duties and audio system back-end stuff too, much as usual. Graham added the ability to assign parameters to Audio Trigger Spots which gave all the sound designers much cheer. Though this seems a small thing in the grand scheme, it ensures we’re not just creating new objects in Wwise for subtle contextual changes to audio in the game; it allows us to add change at the point where the change is required rather than, again, duplicating contexts at source as well as at the destination.
Ewan Brown is a new Senior Audio Programmer and has been settling in, getting to know the code-base and how things fit together, providing tool support to the likes of Mannequin. There’s a lot to pick up on and he’s going to be assisting Sam and Ross with their musical endeavours too.
Jason Cobb has been busy with the following:
- Developed audio build validation scripts
- Bug fix various voice leaks, documented two test cases for fixes needed for Flowgraph audio triggers to play correctly with zones
- Bug fix support for hard-coded mat_water material fx
- Started development game audio inventory script
- Various wwise project upkeep, optimizations, support for Stephan’s environment re-org effort
- Area-based mix state markup for multicrew ships. 90% complete
- Investigated situation for markup of single-seater ship interiors.
And that’s all for the moment, please do ask more questions on the forums and we will try to get the whole audio team answering where applicable. Thanks for listening!
It’s been a busy month for the VFX team (I know, I know, we say that every month!). Lots of fine-tuning and bug-fixing has gone in for the imminent 2.4 release – specifically fixing up a couple of particle effects causing memory leaks (easy to fix, not always so easy to find the culprit though!) and a further optimization pass on the new plasma shotgun.
Away from the live release, we have really started to get our teeth into Squadron 42 effects to a more polished level of quality. Obviously we can’t give away too many spoilers, but it’s really exciting to be working on such a diverse range of environments and set pieces. From billowing dust and water sprays, and obviously a lot of explosions, we’ve got it all going on. It’s really starting to come together.
On the weapons side of things, we have begun a clean-up of our impact effects libraries. Specifically here, we are creating surface-specific impact effects so if you fire your ballistic machine gun down at the dusty ground, you will get a kick-up of dust as opposed to a huge blast of sparks. Nothing ground-breaking here but necessary nonetheless and will go a long way towards enhancing the player experience.
We also began to flesh out VFX-related plans for the incredible procedural planet tech. We have some simple but effective ideas as to how we can place effects on a planetary scale (hint: we won’t be manually placing them) It’s really important that we are smart about this, so we can save time in the long run whilst allowing us to maintain the same quality and scale of effects across a planet. Looking good so far!
Finally – and this may be mentioned in the graphics team write-up – some exciting news about particle lighting. We are close to moving over to the new tiled lighting system for particles. This will allow much more accurate shadow-receiving – large spinning fan casting long dark shadows in a steamy corridor? Check!
FOUNDRY 42 DE
Changing the Worlds
The weathers not sure what it wants to do out here in Frankfurt, sunny and hot, overcast and raining, last month had a fair share of it all. The office grew by 2 people in May, Janine helping out with production and David joining the weapons art team. We’re just about at capacity in the office so we officially started an expansion. When we moved into the office space last July the owners of the building put the adjoining space on hold for us for a full year, one of the perks they offer to new tenants. At that time we didn’t know if we would have any need for it, but thought it was a nice gesture.
The team has also been doing some excellent work not detailed below on the procedural system… they would rather let you see it in action than spoil all the details now, so stay tuned on that front!
This month we also kicked things into gear with Gamescom, it only makes sense for Frankfurt to help out as much as we can since we live here. Not too much can be said at this point, but we’ll definitely be there in August.
This month we had our 2nd performance capture shoot for SQ42 at Imaginarium Studios in Ealing London that complemented and completed scenes in the earlier chapters.
Last summer was our main shoot that gave us approx. 75% of all needed material for SQ42’s story. With this new shoot complete and another final shoot upcoming in July we will have collected every bit of performance! Highlight of this shoot were scenes with the Idris’ quartermaster handing out big guns as well as an in-universe spectrum show with a furious and most importantly hilarious host!
For the shoot the Cinematic team built some of the needed environments to be used for live-mocap and coordinated efforts to get all needed level segments, characters sorted in time for live-mocap to be effective. (Live-mocap is a process where we can see the motion data live in our engine on actual in-game characters inside the actual scenes/levels)
Michael, our Lead Cinematic Designer, has finished a first pass on an important, longer cinematic piece that happens in the middle of the story campaign.
The Cinematic animators have been providing support to the Gameplay team in the UK while they wait for data to get back from the shoot. They’re also finishing up sorting the quad cam video data from last year’s p-cap shoot. When that’s done the animators on the Cinematic team will review the p-cap shots with the quad cam data and make sure that the animations are playing out as they are intended.
Subsumption editor has been updated to version 0.901 and we started to implement some more functionalities exposed now in the tools for the designers. First of all we created some new Subsumption tasks to allow designers to use the following functionalities:
- Querying the Tactical Point System
- Move to a specific cover location
- Shoot from the cover the NPC is in to his attention target
We exposed a way for designers to suggest the next activity or subactivity for a given NPC. We also completed the first pass to support Action Areas. As we explained in the monthly report from April, those are the elements in the world that allow designers to mark areas with specific information: a multicrew space ship, for example, might have an engine room, a hangar, a control room and so on. Action Areas allow the NPCs to reason about the environment to fulfil their tasks. Those game elements are also used to notify the NPC when another NPC is entering/exiting the area or to re-route specific events that are intended for the characters present in the area. We also implemented the basic code to handle Subsumption events, designers can create those specifying different properties (for example if the event is something the NPCs should see to perceive it, if they should hear it, if there is a max range in which the event can be received, and so on) and Subsumption keeps track of all this data.
We also completed the first pass on using the Usables/Interactors as navigation links. This unification step was required since Squadron 42 and Star Citizen are not only using the classic navigation links to allow characters to jump, vault, and so on. We also have links to connect the navigation through the usage of items (for example passing from room 1 and room 2 may require the AI to open a door) and these items can also be used by the players, making everything even more complicated. Using the Interactors makes sure that an NPC that opens a door doesn’t require any different code to synchronize the action with other players or other AI characters, making all the code flow much more consistent.
Regarding behaviors, we are currently embedding specific “mental states” to allow the normal NPCs behaviors to cope better with cinematic scenes and in-ship state (piloting a ship, controlling a turret, and so on)
Regarding the ships behavior we are almost done with the first pass to improve the behaviors of the ship assigned to restrict their movement into specific areas. We currently have missions where spaceships need to guard specific environmental elements or where ships cannot leave specific boundaries to avoid being destroyed.
Currently boundaries where always considered as a soft restriction on the ships behavior, but we are now expanding the ships behavior to correctly handle a strong spacial restriction.
This month we also spent time on improving stability and performances of the live game, so that all of you guys can continue to enjoy each release of Star Citizen.
This month the weapon art team finished two new ship weapons and did extensive work on the weapon material library. On top of that we are currently modelling a new ballistic submachine gun and doing the final touches on the Scourge Railgun detailing and texturing. The Railgun is meant to be a visual target for all the new weapons to come, so we’ve taken some extra time to take it to a gold standard level of quality.
We’ve also been joined by a new starter, David, bringing the weapon art team size up to 4 people now.
Level Designers have been working on finalizing the layout for the Outlaw Base, it’s had a first art pass and will come back to them for a mark-up phase before release. This base is also scheduled for a tiered release so there will be a lot of back and forth between art and level designers as areas get released an new ones get added. The guys are also working hard on the Truck Stop base which is a nice place for pilots to stop to refuel, grab a bite to eat, get some supplies before they head out on big journeys. Another area in which level designers are working in is adding landing sites on procedurally generated planets.
The system designers have finalized the Power Distribution system which once implemented should power all our ships from single seaters to capitals and even stations. This system will allow players to configure how power travels within their ships, which components get power, how much do they get and where do they draw it from. At the same time it should allow more nefarious players to sabotage said system. At the same time the Looting, Inner Though and the Usable/Interactor systems are also fully designed now and are heading into production. A lot of work went into ensuring that all our usable props and animation metrics for them are properly standardized so we don’t have to do the work twice and everything will fit together once it’s in game.
On the AI side we are designing a system that can generate archetypes and loadouts quick enough to fill an entire galaxy without us having to manually build each individual NPC. Basically by defining rulesets and tag sets the system will be able to create said archetypes matching their gear to where they came from, what their job is, what the dress code is in the area they are in, what rank they are etc. Besides that, there is also a lot of work going on in designing the tools we will need for the brains and logic of our new Subsumption based AI.
Both system and level designers have been planning out the work for the next year and the upcoming releases to make sure we have a more realistic picture of what can be done with the allotted time.
Renderer refactoring: On the Renderer side, we did some housecleaning and optimizations. Based on the refactorings from last month to increase the object count, we started to simplify the data upload to the GPU. Previously the CryeEngine system is based on reflection, so that the code could find out what data was needed on the GPU and only upload this data. While this sounds like a solid idea, finding out what was needed was more expensive than a straight data upload. So we began to remove those reflection code paths in the time critical areas. This also improved the readability of the code, as we can now see what the code does and not the logic to find out what to do. Related to this change, we also ensured to only upload the same data once to GPU. Previously it uploaded a data buffer for each object, and then uploaded the same data again if the code decided to use instancing. This is now fixed.
Data Patcher: On the Data Patcher (the tool which will be responsible to create the data for the engine to use when we switch to incremental patching), we made a little progress by better defining how to store the data. Not much reportable progress here as much work is about infrastructure discussions.
Optimizations: To further optimize the streaming code, we added timeslicing support to it again. This way the cost to update the distance to objects not visible to the player is done less frequent.
Tag System comes into the ZoneSystem: Initial support was written to support storing tags inside the ZoneSystem. A Tag is a small string which we use to give context information to an entity object. For example if we want to know if something is a chair, we can tag it as a chair. This way the AI system can ask all objects and find out if they are chairs. We already have such systems inside the engine but those are lacking spatial information, so they can only answer: is this object a chair, but not “find me all chairs around me”. This lead to some in-efficient solutions as the code had to brute force get many objects and check their type. To overcome this limitation we are moving the support for tags into the ZoneSystem, our spatial position system. This required some changes and new systems:
- Storing and comparing a string is not very efficient on a computer (but very convenient for a human, thus we need it), so we implemented a Trie to allow us to very an efficient way to map unique strings to a fixed integer range. (We wanted to get an integer range instead of a hash as a range allows us some better broad phase checks and more efficient data storage)
- Since not all data types which we stored inside the ZoneSystem require tags, we made the whole zone system more flexible to allow the client code to specify the properties to store per object type. This also reduced our memory usage in crusader by 50MB.
- We implemented a specialized allocator for the tags so they can be efficiently culled by the low level zone system, which is implemented in SIMD, so the tags must follow a certain size and alignment.
- And as a last thing, we implemented code to allow filtering tags by a DNF (Disjunctive normal form), which is a fixed format and can be used for efficient checking of arbitrary boolean expressions.
Runtime Skel-Extensions: The character customization system in Star Citizen is internally using an engine feature called “skinned attachments”. With skinned attachments it is possible to replace every deformable item on a character (i.e. cloth, shoes, spaces suits, helmets, etc) and even entire body parts such as faces, hands, or upper and lower body parts. Each skin-attachment has its own set of joints that are automatically animated and deformed by the base skeleton. It is also possible to use skinned attachments that have more joints and different joints then the base skeleton and it is possible to merge all types of skeletons together, even skeletons from totally different characters. That means you can have a minimalistic base skeleton which can be extended by an arbitrarily complex skinning skeleton. In the original CryEngine this was an offline- or loading-time feature, because the entire process was pretty CPU intensive. For Star Citizen we turned this into a runtime-feature that allows us to extend a base-skeleton anytime while the game is running, no matter if the character is alive and playing animations or in a driven- or floppy-ragdoll state. This means that you don’t have to know in advance the type of joints you might need in the base skeleton nor do you have to carry extra joints around just in case you might need them. Instead the system allows you to add new joints at will and whenever they are required.
Full-Body Experience: we also invested a lot of time to improve the full-body experience in first person. Our main goal was to make the head-bobbing customizable. In Star Citizen the head-bobbing is a natural side-effect of the mocap data, because third- and first-person are using the same animation. To make the controls as smooth and precise as possible, we implemented a new IK-solution to eliminate all unwanted effects from the 3rd person body animations on the first person view and weapon handling.
Frankfurt TechArt is always busy with RND and actively supporting any discipline who needs help. This month we were helping with Eye stabilization for FPS , which will stabilize camera movement while playing in FPS, the results so far have been really good. We’re also supporting feature or RND for the itemport IK system for game, it’s moving positively as well.
On our DCC[Maya] pipeline front it is becoming much more stable but still needs a bit more support as we keep updating or expending it. We were also fixing bugs and supporting weapon Assets on all fronts like rigs, updating rendermesh, entity setup, Mannequin setup etc.
Overall TechArt is participating for new features as well as keep supporting daily operations.
The past month the Frankfurt VFX team has been working on Squadron 42 single player missions. This covers almost all aspects of VFX such as ambient/environment effects, scripted action effects and even some cinematic effects. This also requires a fair deal of collaboration with the individual level designers and artists. Once they are done designing and building a section of the level with props, VFX can then move in and decorate it with the appropriate effects. Everything from fire and explosions to blood and water.
This month in QA we’ve been working closely with our in-house Engineering team to test progress on the procedural planets, as seen in the Pupil to Planet trailer. With such a large scale planet you can imagine the number of issues we encountered throughout our testing. Including, but not limited to the buggy insisting on driving on its z-axis, defying all laws of gravity!! We also spent some time checking all characters currently in Star Citizen and Squadron 42 for issues that might be blocking our cinematic developers. As a result, we were able to identify multiple Squadron 42 characters that had definitely seen better days. Sean Tracy, Ali Brown, and Okka Kyaw jumped on board to assist and we were able to resolve the issues quickly, so that our cinematic developers will be able to continue to create amazing cinematic sequences for Star Citizen. Lastly, we spent the remainder of the month assisting Chris Raine and Chris Bolte with gathering profiling and concurrency data for the PTU servers. The community was a great help and rallied together to load as many players onto the PTU servers as possible so that we could collect data with a hi-load server in order to contribute to resolving the framerate drops the public has been experiencing in Crusader. May has by far been our busiest month in QA, but we would not have expected any less as our universe grows larger each day.
We Aim to Misbehaviour
From supporting Star Citizen Alpha 2.4 to working on some exciting content you’ll be seeing in the coming patches, we had a busy month at BHVR! Here’s the skinny…
For the engineering team, this month went by very quickly. A lot of effort was put on getting 2.4 out of the door, working hard on the leftover nitty gritty details.
We mainly polished and debugged features like the shopping system and cry astro.
The good news is that with release 2.4, we are establishing the foundation for really fun features that will be implemented for the next releases.
With no surprise, this month was almost all about shopping in both Port Olisar and Area18, getting features ready for 2.4.0 live release. This means, sorting out the last remaining bugs and working on improvements like for example; adding NPC shopkeepers or fixing some load out issues.
Level Designer Jesse Kalb, helped out re-design and implement the new port modification system for the flair items in the hangars. The game has many flair objects, so we had to work with Turbulent on getting things working right with the new design. Hopefully, players will enjoy placing the flair items and customizing their display cases.
On a different topic, Technical Lead Level Designer François Boucher, led the way for the creation of the CryEngine level structure and its components for the next map we are currently working on, the Pirate Base. With the whitebox map, hot out of the oven, from our friends in Frankfurt, we prepared the map so both Design and Art teams could work on their respective sections. This means, setting up landing pads, airlocks, doors, elevators, player spawning and finding a sweet spot for this base in the Stanton System.
Francois is also busy setting up the ship components shop that is going to open soon on Port Olisar.
Finally, the design team also started working on the shop designs, layouts and whiteboxes that we are going to find on the Pirate base. The mood is going to be different on the Pirate base and so will the shops. More to come, looking forward to further share with you guys!
It was a very exciting month for the BHVR Art Team, because we began production on new maps.
One of them is a new pirate space station, which we mostly concentrated our efforts on the global aspects of the map like: composition, orientation, basic dressing and evaluating the new extra modules that will be required for this map.
Next month, we will move to final dressing pass, color balance, decal placement and polishing.
The second map, is a new ship parts shop that will be available on a future release. This shop has great character, so we have spent a good chunk of time working on the dressing and first pass lighting.
Next month, we are moving on debugging and polishing.
For the props team, we continued supporting the new shopping system. Mainly working on item racks and shelves.
We have also completed several new props that the environment team is extremely happy to be able to use now.
Finally, let’s not forget the improvements and debugging work that was done for the upcoming 2.4 release.
The Turbulent Power!
Greetings from sunny Montreal where Star Citizen’s web team have been hard at work on everything from Buccaneer surveys to changing how you log in to the game! Here are some specifics on the projects we were working on this past month.
Multi-Factor Authentication (MFA)
For those that aren’t familiar, Multi-Factor Authentication, or MFA, is the type of security many people use with modern MMOs and web accounts, where you need to use a special key code or something texted to your cell phone to access an account. It keeps your data more secure by making it much harder for anyone to break in and assume your identity. We’ve had MFA in the works for quite a while, as we know you want to keep your ships and characters safe! We’re in the home stretch now, as we are close to completing the development of it for the RSI website. Once the QA phase starts, we will be working with CIG to test it and then roll out to the community. At the same time, we are continuing to work on MFA support for the game launcher itself, which will be especially important as we move more aspects of Star Citizen from the web to the game world itself.
You may know this better as ‘Organizations 2.0,’ which we pitched earlier in Star Citizen’s development. Instead of going with a simple update to the current Org system, we’ve opted to develop a purpose-built communications platform that can be adapted for many aspects of the game. Development continues on the new platform, which includes completely new chat and forum systems for the first iteration. We have set up a server for internal testing, but we’re still a few months away from a beta launch. When the time comes, the Evocati group will get the first access to kick the tires!
3, 2, 1… launch! We have been working with the team at CIG on the new version of the game launcher/patcher. The new version will support multiple environments (e.g. PTU, live) and multiple games (e.g. Star Citizen, Squadron 42), and will allow for background patching. In the first phase, the user interface will look like the current one, but we will be able to add new functionality and design in subsequent phases that the current patcher wouldn’t be able to handle. This is an exciting step for how the game ‘works,’ although we know it’s probably not as thrilling to the community as seeing a new ship or planet.
I guess you could say, the Bucc stops here! We assisted CIG in launching the next great pirate fighter, and all our metrics say it’s a hit! To support the Buccaneer, we built a ‘Drake customer survey’ site that will determine what bonus weapon everyone who purchases the ship will get. We took inspiration from the classic Ultima series for this, trying to come up with Star Citizen’s version of the fortune teller’s quiz used for character generation. After all, immersion isn’t just for the game! This month was also the month where backers could reap the rewards of our one-off operations: we distributed coupons to all those of you who took part in the April Fools “Big Benny” reveal, all the entrants in the Shubin recruitment programs, and also everyone who joined in for the latest Free Fly promo.
In preparation for the release of 2.4.0, we have been working with CIG to test the platform side. For example, if a user makes changes to their inventory on the website, they should be reflected in the game too. There are many different scenarios to test, so it’s been a collaborative effort between us and CIG’s QA team. This is one of those areas backers probably don’t think too much about, but is necessary for the move to a true persistent universe. It’s great seeing your ships in the inventory of the website… but it’s a lot greater having the game track them, their upgrades, their damage status, their location in the world and so on.
Also in May, Turbulent sent a small strikeforce to Austin for a series of face-to-face meetings to discuss various issues, such as server infrastructure, analytics, persistence, and the Issue Council. It is possible that some BBQ was consumed after hours, and we’ve had ongoing discussions with CIG about IT infrastructure, and improving performance. As you would expect, this is a complex subject, but we hope to have implemented some new measures by the end of summer.
Don’t Forget a Snappy Title, Jared
This train is just about to the station. I won’t hold you up with a long, boring intro, suffice to say, I could write a long, boring intro if I wanted to. I could do it, man. But I won’t. Because I know you’re in a hurry. Uh oh, is this becoming a long, boring intro anyway? I’d better move onto the next section before that happens. Quickly. Let’s go…
Each day I come to work with some of my favorite people in the world. And Thomas Hennessy. This month was a struggle with Ben and Alexis gone back east for two weeks on Bereavement Leave, but we pulled through with a newfound appreciation for the amount of work the two of them do each and every month. Between Ben and Alexis being gone, and Sandi going to the UK, it was a rare few days this week when the whole team was together, but my main man Tyler Witkin helped out from the Austin office, calling me on Skype each day to keep me company, and help shoulder the load while folks were out.
Basically, this section is just so I can say how much I like the people I work with. I’m in a mood.
This month’s 10 for the Developers episodes in lieu of Chris being in the UK covered a wide range of topics and hosts. Sean Tracy, Forrest Stephan, Adam Weiser, Omar Aweidah, Eric Keiron Davis, Gaige Hallman, Mark Abent, Randy Vasquez, Dave Haddock and Ben Lesnick all stepped up to step in for the Chairman this month. We are extremely grateful each and every week for the time and effort our developers put in stepping away from their work to communicate with the community. We quite simply going not do it without them.
Around the Verse continues to diversify it’s offering as we approach the 100th episode on June 30th. We explored the Nexus, Tamsa, and Min systems in Loremaker’s Guide to the Galaxy. We interviewed folks like artist Cheyne Hessler and the makers of Voice Attack and HCS Voice Packs. We ventured into the Wonderful World of Star Citizen to highlight the tremendous work fan-organization The Imperial News Network does week in and week out. With Ship Shape, we explored the whitebox design of both the Drake Herald and the Drake Caterpillar. And we sat down with designer Matt Sherman and Concept Artist Jim Martin to for an unprecedented exploration of the Drake Buccaneer concept ship. Things certainly came up Drake in Around the Verse this month.
Reverse the Verse, our weekly informal livestream with the fans survived the absence of Ben and Alexis for two weeks (if only barely) and the May Subscribers Edition saw questions posed to our Design and Tech Art members for a full hour.
As another month of development passes, so does another month of stories, content videos, and community accomplishments. This is a section we wanted to include to highlight all of the content creators, streamers, and more! For short, YOU!
First and foremost: PTU Testers. We want to take a moment to express our appreciation for all of our PTU testers who were patient and eager enough to write thousands of bugs and feedback posts over the course of May! As many of you know, this was our first time utilizing the focus-test group titled “Evocati”, and it was a smashing success! We look forward to collaborating together on future patches/content! Thank you so much!
Twerk17 continued his early morning streams that not only entertained us, but helped us greatly! The Design and QA team in the UK studio have utilized Twerk17’s early morning schedule to watch/analyze game-play and bugs! Thanks for being awesome Twerk!
While not Star Citizen related, a couple of different families acquired miniature co-pilots! Congratulations to STLYoungblood’s family and NighthawkZale’s family for both adding a +1 to the citizen count!
Streamer/entertainer/developer Geekdomo underwent a successful surgery, and we are all very happy to hear he is doing well!
We could easily write enough to make this section alone longer than the entirety of the monthly report. This community has really grown into something meaningful. We are all connected to each other not just as backers of the same game, but as dreamers of the same universe. Some may be pirates, while others militant UEE soldiers, but we share one goal in common: stepping outside the box of conformity and traditional game publication in order to try and bring a living, breathing universe that we have always wanted to play to life. This community has become a safe-haven for us sci-fi geeks and we love it. We want to give a huge thank you to everyone who has shown their support and patience for the team and this project as we continue progress on making the best damn space sim ever! We sincerely could not do it without you!
Building Star Citizen is hard work, but it’s the best job in the world. Every day we work is one day closer to our dream: the massive persistent universe of Star Citizen and an unparalleled single player cinematic experience in Squadron 42. We know there will always be setbacks, difficulties, challenges we didn’t predict… but we’re privileged to fight this battle alongside an incredible development team and an amazing community.
Our next release will be Star Citizen Alpha 2.4, which is being tested as we speak. Alpha 2.4 represents another important step towards our goal, with the introduction of persistence and the first part of the in-game economy. We’re very excited to have players earn credits in the game world instead of buying them through Voyager Direct, which has been a goal for a long time. We’ve already seen what players are doing with the Starfarer, our largest ship launched to date, on the test servers and we can’t wait to see what happens when everybody can start boarding.
We are also heading into ‘convention season,’ with appearances planned at Gamescom, DragonCon and our own CitizenCon. We’ll be sharing more details about these events shortly and how you can interact with the team both in person and remote. There’s a lot we want to talk about and then even more we want to get into your hands. We’ll keep smashing bugs, creating worlds and telling stories… and we’re happy to have you along for the ride!
We’ll see you in the ‘Verse.