November 7th 2015
October was a busy month! The worldwide Star Citizen development team is hard at work getting Alpha 2.0 out the door, and we’re very excited about getting this one into your hands. In the past, our module releases have each shown a small part of the picture: ship configuration in the Hangar, social interaction in ArcCorp, single-seat dogfighting in Arena Commander… and now we’re leaping ahead and giving everyone a very early preview of Star Citizen’s beating heart. From multicrew ships to first person combat on the ground, Alpha 2.0 is our first serious look at how the puzzle pieces fit together.
We’re eager to share it, and to collect your feedback… because this isn’t the end of the road, it’s the start of a process that will culminate in the launch of the Persistent Universe. On top of the base that is Alpha 2.0, we’ll be building everything else necessary to creating a living, breathing ‘Verse… and we’re truly looking forward to sharing that process with the community. The following monthly report will update you on exactly what each of our teams has been doing to help reach this very important milestone!
What a month October has been. So many accomplishments leading us through another strong month has gotten us excited about what’s coming your way. The amount of work being completed and released is motivating us to push through to our next major milestone. The in-depth Santa Monica update is below so please look it over and let us know what you think!
This month the Engineering team has been working closely with our UK office and the Santa Monica Designers to continue pushing the boundaries of what is possible.
Lead Engineer Paul Reindell has strategized how our Item System is being revamped and made excellent progress towards its completion. The “ItemSystem 2.0” is designed to be more lightweight, and therefore less resource intensive. Rather than implementing all of the common functionalities into one CItem class, the Engineers have split the functionalities into standalone GameObjectExtensions (GOE’s), allowing them to remain self-contained. By accomplishing this, those systems can and will intercommunicate with one another. As an example, if a different character model is loaded, the effects can then be re-attached to the new model at the GOE level.
AI Programmer Chad Zamzow has made improvements to how the radar works by fine tuning the system to be much more effective at how it represents (or excludes) occluded or partially hidden objects. Further tuning has also been made to the rotational limits of turret hardpoints. He has created a smarter, more realistic system by allowing the Tech Designers to specify rotational ranges of each turret hardpoint. This will prevent turrets from unsightly/immersion breaking clipping through a ship’s hull mesh and any broken gameplay effects or exploits that might accompany such behavior.
Our Flight Engineer John Pritchett nd Designer Pete Mackay have been implementing the new flight modes to our IFCS. These new flight modes not only give players greater control over their velocities, but also provide a means to accelerate to the awesome looking Quantum Travel. Furthermore, John has also been working on integrating the IFCS system into player EVA movement, giving players fine-tuned control over how characters will move around in the near-zero gravity environment of space.
From the UI/HUD team, we have been busy at work completing the 16:9 diegetic screens for the multi-crew-capable ships. This format gives multi-crew screens improved real estate over which information can be passed on to other stations as well as broader details for each respective role, such as a ship’s engineer. We’re really excited about what we accomplished and hope you will be too.
With the Multi-Crew/Large-World release targeted within our sights, the Santa Monica design team has been hard at work, meeting several important milestones that will make it the most epic one yet.
For the Multi-crew release, we’ve prioritized recent design efforts around how the redesigned Constellation will handle during flight. As the Constellation is one of the most anticipated ships in the game, Lead Technical Designer Kirk Tome has been overseeing the tech setup of the Constellation, tuning the flight characteristics and center of mass. The lessons learned during this process will provide the pathfinding R&D needed to manage flight and control over ships in the Constellation’s size group generally.
Beyond the Star Citizen Alpha 2.0 release, the Design team has been making sure plenty of upcoming content will keep everyone excited and happy with their personal favorite ships. Designer Randy Vazquez has written the technical documentation on how the Salvage mechanic will work in-game hand-in-hand with designing the Crucible salvage-capable craft. Other ships that have met progress milestones this month are the Reliant and Xi’An Scout.
Investigations into new combat mechanics have been spearheaded by designers Matt Sherman and Calix Reneau, not least of which is the EMP weapon system and how ship systems can be affected by other types of attacks such as disruption to heat dispersion or disrupting the flow of energy to various ship components. This Distortion Damage is specifically designed to disrupt and drain power from nearby components. We know that the disruption cannons haven’t been very popular in Arena Commander so far because the disruption effect was still being designed – but that’s going to change for the better! As you can see, we achieve many of our larger milestones this month and are ready for another excellent month!
This month has been an incredibly productive month for our art team. We’ve put the finishing touches on the baseline Constellation asset, finalized ship and character concepts, completed rigged and animated character models, and more!
We achieved some major accomplishments and even large tasks for major ships like the Constellation and the Reliant. We finished the functional animations for the maneuvering thrusters, landing gear, missile launcher, escape pods, docking collar, turret doors, to mention a few – all needed to prepare this amazing ship for its first large world release.
Delivering Admiral Bishop was a major milestone for our character pipeline. We took him through all the steps needed to populate Star Citizen full of rich and animated characters. Everything detailed in our character pipeline video revealed this month shows off just one of the several steps to bringing our characters to life.
We delivered several needed concepts that are fueling production of Squadron 42 which we’re really excited to show you as soon as possible.
That does it for our art team this month and looking forward to sharing more next month.
Well, now we can talk about what the writing team has been up to the past few months.
So much Starmap.
As you can now see, we had over ninety systems and over three hundred planets to work out. While Dave has been chipping away at the systems since the project began, there were still a lot to figure out. Will, Cherie, Adam and Dave would set aside time each day to discuss the unexplored systems to figure out the basic information (star type, number and type of planets, other points of interest, etc.) but more importantly try to get a sense of what the character of the system would be. They’d ask questions like, what was the system adding to the Star Citizen universe? What kind of narrative potential could exist there? They also worked closely with Benoit and Turbulent to input the systems into the map itself. As we got closer and closer to release, they shifted onto double-checking the data, doing final sweeps for any typos and basking in the Galactus-like power of manipulating a universe.
After its release, they’ve been continuing to tweak the descriptions and working with the science consultants to generate the more detailed astronomical data for the systems and planets, but mostly we’ve been working on PU needs which have been coming in hard and fast.
At the same time, Dave has been over in the UK to sit in with Chris for editing selects for Squadron 42, while the team continues the push to help provide narrative and dialogue for the Crusader map. Specifically… dammit… can’t talk about that either.
And that’s it. The end of October brings another month of immense progress from Santa Monica and ever closer to the final product of Star Citizen. Thank you for working alongside us as we bring this expansive world to life and see you in the verse!
During the month of October the Austin studio has been hard at work and there have been a number of accomplishments. The team worked very hard to support many parts of the game that were demonstrated at Citizen Con, and we are very excited to be in the later stages of testing Star Citizen Alpha 2.0 and the Crusader System for upcoming release to the PTU. We’ve had a number of team members visit other studios for collaboration, and we’ve been focused on some internal reorganization to adapt to CIG’s evolving global footprint. Here are detailed reports from each team.
This month our PU team has been looking ahead towards upcoming releases, working on brand new features that will add to the Social Module experience. Mark Skelton and the PU Art Team have been putting the finishing touches on the Million Mile High Club. Complete with a dance floor, fish tanks, and Bartender and Doorman NPC’s, this luxury lounge will go out to a select group of backers and we expect it will be the envy of all who come to visit.
We’ve also shifted the Environment Team’s focus from Stanton to Nyx for a time, and we’ve got BHVR working to complete the Levski landing zone to get it in your hands soon. We’ve been going back and forth on the blueprint for certain areas of Levski, particularly the bazaar marketplace area, to make sure it is laid out exactly the way Tony wants. Levski is going to be completely different from Area18, and being the first Frontier world we will have released we hope it will scratch a mischievous itch amongst the community.
Additionally, we’ve been working on an additional shop in preparation for our Shopping Milestone. Casaba Outlet, once released, will introduce the first iteration of the in-game store and purchasing experiences. Tony, Zane, and Karl Jones have been working together on creating the brand new Shopping UI and it is looking really fantastic. The environment itself has had a design/layout pass by Rob Reininger and is now undergoing art polish right now by the team at BHVR. Casaba Outlet is a clothing shop so naturally it requires the creation of several new civilian clothing assets. We’ve partnered up with CGBot for this purpose to bust out some clothing assets from the Terra>Fashion Casual line.
We’re also recommencing discussion on how Character Customization will work in Star Citizen. We’ve had several ideas tossed about, and we expect to have an initial iteration ready for you guys to go along with Shopping. Sean Tracy has been working on a prototype to pass off to BHVR to take to fruition. We’ve also been generating more content to go along with this first iteration, including Billy Lord creating more hairstyles, and the clothing assets mentioned above.
We’re also in the process of adding new animations to the game for use by NPC’s in preparation for when we get Subsumption (our Peaceful NPC AI system) up and running for our NPC’s. David Peng and Vanessa Landeros have been working on Nightclub and Medical Unit animations, respectively. Bryan Brewer has also been polishing our Male Locomotion Sets and will be moving onto Female Locomotion Sets soon.
As always, it’s been a busy month for the PU Engineering team. A lot of work went into getting our recent SC Alpha 1.3.0 release out live, including a few pushes to PTU leading up to that release. With that release we introduced some new features into ArcCorp….namely the buggies and the respawn functionality needed to handle the multitude of insane deaths caused by buggies. A lot of work dealing with physics and collision issues went into this release (we knew you’d be putting those to the test!). We also increased the player count for ArcCorp up to 40 from 25, which was accompanied by some significant performance optimizations to ArcCorp. But that’s not all! We got in some new chat functionality, such as the private chat channels, so players can chat privately with their cohorts. These improvements were the result of a great cross-studio effort between our various CIG studios and friends at Behaviour and Wyrmbyte.
We’ve also maintained a heavy focus on upcoming releases that are planned for the coming months. Working closely with Behaviour, we have been putting together our party system and additional functionality for the hangar elevator interface. A ton of work has been put into optimizing performance throughout various area of the game, as well as strengthening our existing backend services and adding new services. We’ve been working hard on character networking optimizations…and all sorts of under-the-hood work that will greatly improve the player experience.
A series of networking meetings over the past several weeks have wrapped up, allowing us to begin getting together technical documentation needed for some of our longer term planning and road-mapping for essential networking systems.
Last but not least, in addition to tackling the many bugs that came with launching the recent live release, we’ve has been busy knocking out tools and editor bugs to help support a variety of developers in creating new content for Star Citizen!
Until next time, we hope you survive the post-Halloween candy comas! We can’t wait to get our next release out to you.
QA charged into the month of October at full speed. The first part of the month was devoted to testing our live demo for CitizenCon. We were very happy to see the presentation go as smoothly as it did and are extremely excited to get Alpha 2.0 in everyone’s hands.
Immediately following CitizenCon, we shifted our testing to the live deployment of Star Citizen Alpha 1.3.0. After five deployments to the Public Test Universe, we had a potential candidate to release to the live environment. There was some discussion to potentially release an additional patch to address some remaining outstanding issues. But the decision was made to focus on Star Citizen Alpha 2.0 and roll any potential 1.3.0 fixes into that release.
The remainder of the month has primarily been focused on testing Alpha 2.0 and the Crusader system. Our counterpart QA team in Foundry 42 has been conducting in depth performance testing and providing the information to our engineers in their efforts to optimize Crusader as much as possible.
Our ship expert Andrew Hesse has been working very closely with Designer Pete Mackey and Physics programmer John Pritchett testing the newly implemented IFCS modes for each flyable ship. Additionally the team has been working with Technical Designer Calix Reneau in his efforts to balance ship flight. Each ship’s flight characteristics were tested in 1.3.0 and then again in our SC Alpha 2.0 code branches. Calix is now able to compare ship flight in both environments which will help him to more effectively tune each ships’ flight characteristics in the progressing SC Alpha 2.0 branch to his intended specifications.
This month we have a new addition to the US QA team, Vincent Sinatra! Vincent will be filling the role of QA Lead in our LA studio. Vincent has a wealth of experience as project lead on multiple titles. Some of which include Doom3, Quake4, Enemy Territory: Quake Wars, Call of Duty Black Ops and Call of Duty Elite 2.0. Vincent will be focusing on testing each ship for proper flight characteristics and system functionality as well as any special projects requested by development in the LA Studio.
This month we also had our engine and editor expert Melissa Estrada travel to our Frankfurt office. Melissa spent a week training Senior QA Christopher Speak on our various Star Citizen specific processes and procedures. They also spent time discussing our automated testing development in detail. It was a very productive trip!
Right now we are continuing to focus our testing on Star Citizen Alpha 2.0’s internal test builds and the Crusader system. We are having a lot of fun with it and very much look forward to getting it out to everyone as soon as possible.
The Game Support team continues its work serving players, and yes, we’ve been just as excited as you about CitizenCon and everything that was shown there!
We’ve been continuing to assist players with technical support issues, and we’ve turned out attention to incoming reports of hacked accounts. A note to those reading: We’ve started to see a rise in unauthorized access to accounts, so make sure you are keeping your information secure and don’t share with anyone!
On a side note, we’re just as thrilled with the rollout and usage of the Issue Council as everyone else! While largely maintained by our QA team, we’ve been making sure the most pressing issues get attention, and with the 1.3.0 release, we saw our first bug reports entered in by players and fixed by the dev team. We’re excited to continue this process as getting player feedback is absolutely essential to building the BDSSE. Over the next few updates, we’ll start publishing those results for you so that you can see how this has affected the dev cycle.
As we have pushed out 1.3.0 to players, we’re extremely excited for what’s on the horizon for 2.0. As the needs of the game and community grow, so does the demand on the team. We’re very close to bringing on our first team members in Manchester which will expand our hours of operation and help lower the response time for when you send in a ticket to us.
Speaking of 2.0, we’ll be holding controlled PTU play sessions with players as we did for the Social Module. We’ll slowly ramp that up over time, and we will have a special place for those players to provide feedback and bugs. This will be an essential process to collecting information on the 2.0 release, and we’re very excited to help make this good as it can be before going to Live.
The month of October flew by for the IT team and as usual we got a chance to roll out some new services and a number of upgrades. As the pace of builds continues to increase we still need to keep up with the data delivery between all studios. Fortunately we keep finding new ways to improve our long haul transfer times to levels we couldn’t have expected the month before.
Moritz joined the IT team as our new Systems Engineer in the Frankfurt studio. Moritz has deep roots in Germany and brings many valuable vendor and service provider connections along with him. He had to hit the ground running because we were all too busy supporting CitizenCon to show him the ropes when he arrived. After the show we worked closely with Moritz to lay in some substantial improvements to the Frankfurt studio. Paul came over from the Austin studio and with the help of other members of the IT team throughout the company we implemented a new phone system as well as a sizable storage upgrade. Most importantly, we finally got the fiber internet upgrade installed which will make a major difference for the team in Germany as well as the rest of the company.
Last month our friends from Intel brought us a prototype server for performance testing of their latest SSD drives. This server is incredibly fast in every test we’ve thrown at it so far this month. We’re super excited to have the opportunity to performance test their new drives in various RAID configurations and can’t wait to put this server to the torture test of our game build and publishing environment.
For the month of October, DevOps supported the new and improved Build system, added more analytics to the Launcher and supported CitizenCon!
Since changing to the new build system, we’ve been able to push more builds out than ever before (and you can see how this has enhanced the feedback and deployment cycle for Alpha patch 1.3. We couldn’t have done that before)! We’ve also added a feature that grants QA and Production the ability to deploy game servers for specific builds. This allows any member of our team around the world to now kick and deploy builds “On demand”. They no longer have to wait on someone else to deploy a server to a build that they’re working on. We are continuing to improve the state of the new build system with “nice-to-have’s” as the core functionality of the build system has been fully implemented.
We also made improvements to our internal builds page that allows devs to check the status of all builds, monitor builds, and copy builds without the need of opening additional tools. One central location for all of your build needs! DevOps improving the way we upload our game data to Amazon for a faster and smoother distribution to all of you wonderful people. We updated our launcher with some bug fixes and added some analytics to help improve our services.
It was wonderful to see so many of you at CitizenCon earlier this month, and gratifying to hear that so many people around the world tuned in for the show! We hope you had a good time seeing first-hand some of our work, and there’s plenty more to come. Here’s the breakdown of what we did in October:
October is done and CitizenCon is out of the way, now all the focus here is on getting the first phase Crusader build into your hands. We are working flat out to get it in a stable enough state to give you an impression of the scope of this incredible game. There are still issues we are closing out that need to be in a better state for release, such as EVA which is going to be an integral part of Star Citizen.
Quantum Fuel is also going to be a factor for players to manage and consider, adding a layer of realism and strategy to travelling around the universe. Service stations, run by Cry-Astro have begun to pop up around the Crusader map allowing players to refuel, rearm and repair; for simplicity and convenience in testing the Alpha 2.0 build, these will initially be free, but when REC comes online in future builds it will give players more to think about.
We have implemented several starter missions for Players to tackle that are dotted around the map, and as we continue to fixup the FPS gameplay we now have a specific location that will host FPS combat for those brave enough to dive in. All in all we hope to deliver enough content to keep you busy for a while.
Another happy side effect from all the focus on the Star Citizen 2.0 build is that we have been able to move design resources back on to Squadron 42 now that a number of critical blockers have been removed. We have been making great progress on the AI system with the team looking at getting something into future Star Citizen – Live releases in the form of an asteroid base for you to tackle.
All in all, another exciting month on Star Citizen where we are really starting to feel things coming together after all the time consuming, but essential technology work that the engineers have been doing to allow us to deliver the experience that you demand. As always thank you so much for allowing us to do what we do to make this fantastic game happen.
This last month has been somewhat split into two as far as our main focuses (foci?!) of attention in audio have been concerned.
Firstly, we had CitizenCon, which was massive of course, and to varying degrees occupied the whole CIG Audio team right up until the event itself. Apart from the solid work that was done, i.e. the material that’s all going forward into the game, we put in an awful lot of work to try to make sure it was the best sounding event as far as the live streaming aspect was concerned. From our perspective, we weren’t altogether satisfied with Gamescom and there was a lot more we could do about CitizenCon’s audio quality and prep; making sure it all went smoothly was so important to us. Stefan Rutherford has to take a lot of credit for that, he was there throughout assisting the audio engineers and I feel that it really paid off.
It was awesome finally to show parts of Squadron 42 which has been something we’ve been working hard on for some time, our Dialogue Specialist Bob Rissolo put in some serious work to make sure that the Bishop’s Speech and Morrow Tour came across as well as they did on the vocal side of things. Talking of the Morrow Tour (also another facet of Squadron 42) – that featured sound design from most of the team but honourable mention to Ross Tregenza who owned that and ensured it all came together. Geoff Zanelli’s music was great to hear for all the Squadron 42 sections too. I have to mention Darren Lambourne, Luke Hatton, Jason Cobb, and our audio code team Sam Hall, Mikhail Korotyaev and Graham Phillipson who all put in so much effort to get it all across the line.
Hopefully you all saw (and heard) the StarMap which Phil Smallwood and Matteo Cerquone owned and pushed forward with on the audio side. Some great music from Pedro Macedo Camacho there for that too.
After CitizenCon, our second big focus for this last month has been SC Alpha 2.0, which features a lot of what was shown off at CitizenCon and more besides. E.g. on the dialogue front, we’ve been carrying out sessions for updated ship computer material and a whole host of requirements for various points of interest. We’ve also been continuing work on the many points of interest that you will be able to explore.
As well as the Alpha 2.0 work, we’ve been continuing on the sound for the Social Module, with audio also now being started on for the Million Mile High Club. Somehow we’ll get some ‘luxury’ sound in there! Also the FPS work has continued, esp. on the Foley side, and we’re now really looking to improve the EVA sound-scheme to contrast with the in-ship audio direction.
Of course ships are a massive aspect of our game and we’ve been both improving how we approach these, as well as creating whole sets of new pass-bys for specific ships and manufacturers. So they won’t just sound cool as they thunder past you, they’ll hopefully be more readily identifiable. This concept of ensuring consistent characters to different ship types is fuelling much of our 2.0 ship audio approach.
We’ve also been continuing to evaluate 3D Audio tech with a view to choosing an ideal solution for VR and headphones. We get a lot of posts about binaural audio and that has some bearing here, clearly.
Thanks for listening!
After a big push on getting the pcap pipeline up and running in order to support the Squadron 42 “Morrow Tour” demo that was shown at Citizen Con, the UK animation team has now joined in with supporting the SC Alpha 2.0 release by getting any of the FPS animations in order – this has involved R+D work for some of the team here to get to know the ropes, and then polishing up existing assets and supporting the Design and Code team with what they need.
We’ve also been spending time getting the new animator, Oscar, settled in to the team in Frankfurt and getting him up to speed with the tech so that he can work fulltime with the FPS team in Germany for the duration of the project.
The QA team in the UK have been doing the usual of juggling the requests from Dev and supporting the live releases such as 1.3.0. Earlier in the month we even had some of the CitizenCon limelight when our team demoed Crusader, the Morrow Tour and the ARK Starmap live on stage to the sell-out capacity crowd which was quite a bit of pressure!
We’re now testing the hell out of SC Alpha 2.0 to get that ship shape for its introduction!
Also we’ve grown in size, with a new addition to the team in Ben Hickton and have another tester on the way next month so we’re looking forward to having more hands on deck. In part this is to replace the void that Assistant QA Manager, Geoff Coffin and his lovely beard have left in the team after making a switch to Tech Design.
This month the graphics team have been putting the finishing touches to a number of features such as distant shadows, multi-crew ship damage, the improved LOD system, advanced face wrinkle shader. We’ve covered many of these in previous reports but as we get closer to releasing the next version of Arena Commander we’ve had to stress test these systems and fix all the bugs to ensure the backers get a good user experience. We’ve also been looking at lots of performance issues because as we’ve been expanding our maps we’ve been stress-testing the engine in ways it hasn’t experienced before. These have mainly been CPU optimisations rather than GPU optimisations as larger maps don’t necessarily results in more objects on screen, but do mean we need to process a lot more objects to check whether they’re visible and also to update their gameplay/AI.
One of the next features we’ll be focussing on is more improvements to the face shader. We’re getting some great results from the advanced face rigs we have, but the memory cost is currently pretty high and so we’re trialling a new technique that will vastly reduce the memory cost to just a small fraction of what it is currently, with the bonus of actually achieving more detail, so we’re excited to get this tested and hopefully in-game soon. We’re also going to start a major re-work of both the UI rendering and shield shader. Both of these were written very early in the project and as the design of the game has become more finalised it’s become clear they need an upgrade in order to do everything we’ll need in the final PU. For the UI we’ll be integrating it more closely into the rest of the rendering pipeline which will allow it to fit better into the scene and also be slightly cheaper to render. For the shield shader the technique will get a major visual and performance improvement which we’re excited to get started on!
Just a short update from the UK this month. After a really successful CitizenCon at the beginning of the month we’re now working hard to get the large world map out and released into the wild. A lot of this is polishing up what we already have, bug fixing and performance improvements, but cumulative small polish is critical for delivering a game that plays smoothly, even on a powerful computer.
This doesn’t mean we’re not doing any new features. We’re looking at improving the Retaliator’s damage so you can get it to split in two, which is a bigger task than might be expected. When a piece breaks off a ship like the Retaliator then what the game recognises as the interior also has to be broken in two and a new instance created. Also our debris system wasn’t network synced as the pieces from a fighter were small enough not to really be concerned about. This obviously changes when you have a piece of Retaliator debris bigger than the ships you’ve flown so far, then we have to start worrying about it being in the same position on all clients. We could have just hacked a fix in for this build, but we want to do things properly which has meant making that whole system more robust and future proof going forwards. Takes more time in the short term but you benefit in the long run.
There is a lot more going in which we hope to be able to show you shortly, but we’re now at the stage where it’s just a case of working hard fixing up all the current issues.
A lot of time has been focussed into hiring again this month, artists across the board, from all over the world and we are still going – if only we could add another level to this building like the environment guys do! Concept team has grown by two and given us a good boost in being able to dial in concept work Xi’an Scout, MISC Freelancer and Starlancer. We have a welcome Senior Character artist added to the team and they has been a flurry of activity on characters for SQ42 and heads for promo pieces (giving nothing away here!)
It’s been full steam (and other ambient effects!) ahead for Alpha 2.0 release. Specifically this means we have continued to polish and optimise the ship damage effects as well as ironing out some functionality concerns we had regarding how the interior effects trigger in relation to receiving exterior damage. That’s all coming together very nicely.
Also we did a fully sanity check on ship thruster effects to make sure they were still behaving as expected post-IFCS update. Fingers crossed, all good!
Aside from the ships, there have been lots of ambient environment effects polish and optimisation for the new map – leaking coolant, steam, airlock effects, holomaps and general space dust/debris to name but a few. There’s been a real focus on making sure these effects are as efficient as possible due to the sheer quantity required to populate such a massive area. We place these on a per-location basis, but as there are several locations within a single map, the overall particle entity count can get pretty huge. Thankfully we have a plethora of optimisation settings to play with, so within reason the effects shouldn’t cause too big a performance hit.
We’ve also been working with the graphics engineer to ensure our particles are being correctly lit/shadowed based on location/placement within visareas.
We also began R&D on a new type of ship weapon – can’t say too much about this but its effects requirements present us with some unique challenges. Looking forward to seeing this one take shape in the near future!
Ship team has been growing, we have an influx of new starters, here we always start them on props to get used to the pipeline and then add them into the production process of the ships. So, to the meat of it – Starfarer Interior, it’s ongoing, pushing to establish hero areas of the interior of the ship which then serves as the kit foundation of all other areas within the ship.
For the exterior, we continuing to establish the MISC exterior shader set / style, working up thrusters and landing gear in tandem. Additionally, the AEGIS Vanguard is marching forward to Hangar ready, using existing shaders and mesh parts established during the Retaliator production.
The Freelancer interior and exterior: still early days but the ship is really taking shape and giving off the MISC vibes, cockpit fitting, UI and cockpit fitting have worked hard to come up with something new and interesting yet functional for this ship so watch out for further updates.
The Sabre, currently being Greyboxed to establish a solid mesh foundation to build from at this stage, we’ll give this to ship tech to take through its paces and identify any snags before going into final production.
Now Citizencon is out in the public I can talk a bit more freely about what the Prop team have been focused on. Citizencon was used as a test bed for how we are approaching dressing the larger multicrew ships. The hangar dressing was a main focus, we concentrated on building all the engineering and diagnostic tools that the engineers need to keep their fleet in working order. A lot of work was also put into supporting the animations and performance captures, we have a good understanding of the technical set up required for getting the props working with the animation data. There is still a lot of work to be done on the smaller scale human props that we want to deliver, to really sell that lived-in feeling when you step on board these ships and environments, but the engineers are now geared up to fix any battle scars your fleet of fighters may receive!
The prop team is now focusing on 2 major areas, the ship components and the shopping experience. The ship components are super exciting for us, it’s going to pave the way in terms of ship customisation and performance. We are supporting the design team and making sure that all the options they want to give to the players from a game play point of view are viable from an art standpoint. So far its super exciting, the concepts are fantastic and we hope to have the first couple completed soon. Once we have the foundations in place we should be delivering new component artwork on a regular basis.
The shopping experience is part of the social module, it’s all about giving the players more options. I don’t want to give away just yet what shop is our focus but nailing that immersive shopping experience is our priority, making the shop feel alive and used when you walk and purchase your wares.
Summing this month up in two words, it would be dressing and customisation!
Optimise, test, polish, bug, repeat. This has been the mantra for the environment team since the demo you saw of SCA2.0 at Citizencon. It’s not the most fun part of game development but is an absolutely crucial step to ensure then end experience for the user is as good as possible.
The final level of dressing has been added to the scenes, everything from personal belongings left behind to half eaten boxes of Big Benny’s noodles – this process lets us tell small stories within the environment and hopefully adds the human element to the scene.
SCA2.0 has been the perfect proof of concept for large world environments and space stations for both the PU and SQ42, its shown how modular building sets can work and how amazing it can be to create space stations real time in the editor – simply amazing tech!
The environment team can’t wait to see you guys play 2.0, we want to see lots of videos of you guys exploring, and having fun within the sandbox
Frankfurt is getting a bit colder this month, and the leaves are starting to fall off the trees. The team here is 30 strong now and we have numerous candidates across multiple disciplines that we’re in discussion with. We appreciate all the support we’ve been getting from the community. Here’s a breakdown of some of the stuff we’ve been up to this month.
The Weapon Art team has been working on a prototype for new scope attachments and experimenting with lens shaders.
The picture is the current result of this, showing the prototype geometry (not featured in the game, purely made for testing) from a couple of different angles as well as in ADS view.
We’ve also continued to develop the manufacturer style guides and the high level production pipeline for ship and personal weapons.
On the level design side, Andreas and Clement have been looking into best practices of creating modular elements that can be used to build space-station-like-structures and experimenting with various ways of combining those into environments that, while allowing us to quickly build new areas, are still meeting our high standards of artistic & gameplay quality. This system also gives us the flexibility to quickly alter the flavour and content of an environment, changing it from something like a UEE to a pirate/smuggler space station.
On the system design side we have been focused on multiple things. Chris has been busy working with the Character Art, Tech Art & Animation departments ensuring our new character setup fits the new modular suit design. This needs to be done as soon as possible, as it affects all future FPS characters we will have from now on and doing it correctly now instead of waiting until later will pay off. He also worked closely with Francesco (AI) on finalizing the systems we need for our AI to function properly.
Another big task that is taking a lot of our time right now is re-visiting our Careers (both old and new ones), fleshing them out and trying to reorganize them each into component Player Activities and then split each Activity into its base Systems/Mechanics. There’s a lot of documentation work here but once done we will be able to have a clear picture of all the things the player can do in the Star Citizen Universe and what are the required systems are for it. This will also help production as we will be able to see what systems are needed for which career, allowing us to prioritise them.
Todd has been working with everyone involved in the FPS part of the 2.0 Baby Persistent Universe release, ensuring the quality of the FPS stays on par with what the backers are accustomed to seeing from Star Citizen.
This past month, VFX has been working hard towards adding and polishing effects for the persistent universe and arena commander module updates that will be released soon. Some of the effects included are improvements to the quantum drive spool up and effects for the new repair drone. We have also been making libraries of various types of space dust to place around asteroid fields. Everything from thick fog, to various densities of dust and even some hot plasma gasses.
On the tech side we have recently had some improvements to the particle refraction. This removes the ghosting artifacts that were possible with the old technique. It also adds a new feature, the ability to blur the refraction. This is important to pull off certain effects such as heat haze.
The gif is a close up of the repair drones welding torch effect that was shown in the CitizenCon demo.
Cinematics did some clean-up to the UEE senate scene so we can revisit it once Admiral Bishop’s dress uniform costume and other character details are finalized. (What you saw at CitizenCon was not fully final of course! We enjoyed sharing it but there’s more we want to do.) We also did some work on finishing the senate hall environment, including texture work and modelling the senate hall pieces with tables and so on.
We also reported and addressed issues like the lacking bone link dialogue in Sandbox and other cinematic related issues. Doing these highly polished bits once in a while is good for setting ourselves into “final” mindset and finding bugs or issues and address them early on.
After this we switched gears to another part of the SQ42 intro cinematics: A giant outdoor set involving an even bigger capital ship and our beloved Bishop. The scale of this set is seriously enormous.
We also started working on the first scene with Mark Hamill’s character and to say it is like a dream come true would be an understatement. We have a first version of the UEE pilot helmet on him that he & other pilots including the player will use and it just looks so cool!
We continued working on the McArthur Skydock, focusing on getting the textures where we’d like them, making normal maps and finishing up the diffuse and gloss textures, and built some new parts such as the huge columns and claws that hold the ship.
During the first part of the month we have been focusing a lot on the Morrow Tour experience, improving and polishing the AISequences and how those are connected with the AI behaviors.
We introduced the possibility for level designers to requests activities in parallel like walking and talking, and we also made a pass on the Usables to properly utilize them as navigation links and started our iterations on Subsumption to create basic routines for AI NPCs.
After CitizenCon we moved our focus on mainly two areas: FPS AI and multicrew ships controlled by AI.
FPS AI – First of all we have extended the zone system to be able to register general AIZoneObject so that we can have multiple AI objects connected with the zone system without really polluting the zone system API.
We started with the cover information so that behaviors can query correctly cover spots in the ‘Verse.
At the moment are currently working on the first version of our systemic combat behavior creating basic tactics the AI can select during the combat behaviors.
Spoiler alert!! :) I can share with you guys a little snippet of the behavior tree where the AI selects a cover spot that has a shooting posture and it then sprints towards the cover location.
Focused mainly on bugfixes and small features for me this month. One thing the players might notice is the improved pass-by sound effect logic for the space flight. With the new and improved mathematical basis for the game logic, we were able to tighten the ship flyby sound effect timing, which in turn allowed us to make the sound much more detailed and focussed, especially for the really close ones.
DevOps kept refining the build system, making it more stable and bullet proof. In particular a lot of effort has been put in the buildmonkey front end page. Instead of having someone from DevOps deploy servers, QA can now do that on their own just by clicking a button. We’re heading towards the point where there is less involvement from a DevOps Engineer to handle simple everyday tasks.
We’ve been experimenting a lot with docker and how that can help improve our tools’ stability. Our build system (which is on github now) is going to have its own continuous integration system. Even though it’s far from being done, right now whenever there’s a new pull request or commit on the master branch, we get that change and spin up a new build server within a docker container on a completely automated fashion.
We also got visited by Alex P from the ATX studio. Within CIG he’s one of the most knowledgeable individuals for server automation, chef and general live service management. That week’s been very productive in terms of getting deeper knowledge into certain systems.
Hi Everyone, during the past month my main focus was on upping the quality of our two October releases: CitizenCon and SC 1.3.
During this time I worked on several optimizations, mostly around the ZoneSystem and CPU side object culling. Besides those, my second focus was on improving our thread backend to be more optimal for a PC only game.
CPU Performance has changed a lot over the recent years. In the old times, optimization was straight forward, there was only a single execution unit inside the CPU which did all the computations. In addition, there was an active GHz race, causing your code to automatically run faster by each new released CPU. Nowadays, the GHz of CPUs don’t change much anymore (single core performance still increases, but not on the level as it did before) and CPUs have gone “wide”, by providing more execution units.
This puts more burden on the programmer, as concurrent programming can be very complex. Since games have (by their nature) are very sequential execution; each frame first must update the state of the world, and then send this state to the GPU for rendering, It is hard to parallelize those in a way that actually gets you any performance gain. To do this, one of the most prominent models used for Games is a so called Main Thread. This Main Thread can be assumed to be like a regular game loop from the single core CPU times. The other cores are then used during a frame to help the Main Thread. If for example, we must update the state of 100 particle systems, we can distribute those over all CPU cores, to reduce the latency between beginning to update the state and being done with it. See the attached picture for a simplified example how this distribution helps.
To make all of this even more complex, the PC platform has to be more general than consoles. On consoles, the game normally has all the resources exclusively and on a known hardware set. On a PC, the game has to share the resources dynamically with an unknown number of processes running at the same time on an unknown hardware platform.
So to better utilize the PC platform, we switch the thread backend to batch oriented work stealing approach. By using this new model, we can massively reduce the cost to communicate with different threads as we only need to send a signal once per batch, and not once per entry. We also reduced the contention between the worker threads (important to scale to a higher number of CPUs), by utilizing work stealing so that threads communicate with each other instead of over a central queue.
This whole threading change was one of the major improvements for performance for 1.3, which also causes a higher CPU usage (which is good, as we now actually make use of the cores inside your CPU). Currently, nearly all legacy jobs are already ported over to this system, as well as all CPU side culling of the ZoneSystem. In the future this system will be used to parallelize parts of the game code, as well as a few additional things.
On the physics side we encapsulated the physical parameters from the animation hierarchy and moved the entire code and all data structures into the physical hierarchy. We also invested some time into a radical cleanup of the synchronization-code between the animation- and the physics-module and added new debugging features to display the physical state of articulated entities.
On the animation side we helped the fps-team to build a new animation rig which makes full use of existing engine features like animation driven IK, which in turn makes it possible to have “runtime retargeting” and “procedural motion warping” on animated characters. In parallel we added several new debug features to visualize the primarily joints of the rig and to display the inner workings of animation driven IK. There’s a future design gain from getting this to work – more ship cockpits and crew stations could be able to have more of an individual feel and not seem artificially or excessively ‘templated’ on each other.
The rest of the core engine team have been busy on numerous fronts. It’s a bit premature to go into all the details, but rest assured you’ll hear more moving forward both in our monthly updates as well as our weekly ATV segment.
We were all quite impress with your driving skills and your unstoppable determination to drive a buggy inside G-Loc Bar. You created enough scrap metal from those damaged buggies to build an Idris. While you were driving around, here’s what the team in Montreal has been working on.
The design team is hard at work with Austin to take the next step for the shopping experience. A new shop is coming up for ArcCorp, while we are working on the stores for upcoming new locations. We are also working on giving you more feature for the character customisation system.
Digging into a massive asteroid, the art team is setting up amazing vistas for the next location you will be able to explore soon. We’ve also finished the final art pass on a very special club. Be kind with every citizen. You don’t know who might be owning one and you want to make sure you are on that VIP guest list. We are only waiting for the engineers to hook it up to an elevator so you can access it … No buggy allowed this time.
This month we completed a lot of the development that was started last month. Most of these features were delivered to the user via the recent Alpha-1.3.0 Release.
We polished and completed our first iteration of the Loadout Selector Usable Item, please try it and give us your feedback! You’ll also see a lot of new features added to the Chat, most notably the possibility to create private conversations as well as filtered conversations. The Transport Elevator Console modifications have also been completed. The list of destinations is now populated directly by the Location Service (Backend). It’s now possible for players to have access to different instances of Area18 and player will be able to choose which one they want to go to based on how many of their contacts are in a specific instance. This information is now displayed in the console.
We’ve also put in a lot of work on features for future Releases. We’ve worked on the Ship Selector Usable Item that will enable players to spawn a selected vehicle on a landing pad. The list of ships available to a player will reflect the list of ships he currently has. We are also working on adding a Party-forming functionality through the Contact List as well as fixing various Scoreboard Issues for Star Marine. We’re also in the process of working on a framework that allows for some UI Elements (i.e. Chat, Contact List) to adapt when a player passes from First Person View to Third Person View.
We’ve also provided some support for the production of Flair Items that will be awarded to certain Backers as part of the Referral program that was launched at CitizenCon 2015.
Last but not least, we’ve continued working on a UI Development Toolset and are currently in the process of having it tested by different team members to catch any Issues before we roll it out to other studios.
‘til next time!
This was a super busy month for all teams, as we work towards the 2.0 release. On the Moon Collider side, we were mainly providing support and doing some bugfixes for a few interesting issues that cropped up with ships, such as some scripting issues in the tutorial, and some behavior tweaks for encounters on the Crusader map. However, for the most part, ship AI has been quite solid, so we were able to do a lot of cool feature work that won’t be in 2.0, but will appear in the following release.
So, what have we been working on?
We’ve made a couple of nice improvements to spline flying for ships. As you may know, ships mostly fly freely in combat, but we do sometimes have them use splines to achieve results that we can’t otherwise get easily. For example, if we want a ship to fly close to other objects or through small gaps, their obstacle avoidance usually won’t allow it, and so we can markup maps with splines to guide ships through these kinds of areas.
The benefits of splines here can also create a problem though: if we’re not using avoidance on splines, then what happens if an object ends up floating into the path of a spline? Up to now, the AI would just collide with the object. This is great if you’re thinking of playing a game of chicken with an AI on a spline, but it would be nice if the AI could be a bit smarter. Now, AIs have the ability to avoid obstacles on their splines, while still allowing for them to ignore the obstacles that the splines bring them close to (such as the big space station they are flying through). There is also an ability to provide extra markup in places where veering off the spline to avoid an obstacle will make the ship crash, so that it can be smart about when to avoid, and when to just plow through. Now you really might end up in a game of chicken and not know if the AI is going to blink first. Are you feeling lucky?
The other thing we’ve improved with splines is to make them work better when they’re attached to moving objects. Up to now, if you had a spline attached to a moving object, like a rotating space station, it would rotate with the object, but when an AI went to fly that spline, it would actually fly a stationary copy of the spline, fixed at the moment the ship started down it. This has been limiting some of the scenarios in which we can make use of splines. Now, we’ve made it so that if a spline is moving, its position will continue to be updated even as a ship is flying along it, and the ship will do its best to stay on it. If a spline is aggressive enough to be just within the capabilities of the ship flying it, then this might not work and the ship will struggle with the additional movement of the spline, but under most normal usage it works fine, so you should be seeing AI ships maneuvering expertly around large moving structures in the future.
Death spirals are a feature that we mentioned starting on last month and that we continued working on a lot this month. This has turned out to be quite an involved task, and we’ve expanded it to the more general concept of “death flourishes”. The idea is to have a generalized framework to sometimes delay the destruction of an AI ship when it has become fatally damaged, so that we can have it do something interesting, such as perform a death spiral, before it is destroyed. But it also needs to be smart, and not make the ship invulnerable to further damage while doing its death flourish. You don’t want it to fly a death spiral into an asteroid and NOT explode!
As part of this feature, we looked at three different ways of doing death spirals. The first one was to allow designers to place special splines in maps to help make ships fly into structures and explode on death. While we may look into this one further in the future, we realized that in practice, for it to look reasonable, the spline needs to be near enough to the ship that it can start flying on it within a couple of seconds, and that’s going to end up happening very rarely in games. So we might end up using it as a rare option when the situation is just right, but it’s never going to be a common case.
The second option we tried was using maneuver splines to fly death spirals. These are special splines that can be placed in front of a ship at any time and it can then follow. Originally created to prototype allowing AI to fly fancy combat maneuvers, they are an obvious candidate for death spirals. So far they are working fairly well, but we found an interesting problem with them that will require further work to resolve. AI controls ships via simulating the same control inputs as human players, so it can’t cheat by doing things that human players can’t do. But we’ve found that when trying to make a ship fly a really aggressive spiral spline to make it look like it has gone out of control, IFCS will kick in and limit how extreme the control inputs can be. This means that we can make the ships fly moderate spirals, but so far they have been unable to keep up with really cool looking ones. We will need to do more work looking into how we can get better results for this.
Finally, we tried a very simple but surprisingly effective option of just jamming one of the ship’s thrusters on! If you pick the right one, a ship will quickly go into an uncontrollable spin. It works well, though it’s a bit limited in variety, so we will use this along with the spline flying option, and have tunable probabilities for seeing these things happen before a ship is destroyed. Over time, we hope to expand the list of possible death flourishes with other ideas, which could even allow for unique deaths for certain types of enemies. There’s a lot of fun to be had here, and the end result should mean more satisfying kills during dogfights.
The last thing to mention this month is a refactoring we’ve been doing on the ship takeoff and landing system. We’ve been reworking several aspects of it to use Kythera behaviors for control during all but the final vertical descent/ascent to the landing pad. This has allowed us to integrate takeoff and landing splines into landing pads, and ships will automatically choose the best spline for their approach direction. Up to now designers have been needing to manually script a lot of this, which is time consuming. With these changes, landing areas will now be a lot easier to setup and will be more robust. This means designers can build maps faster, which means more content, and that makes us all happy!
Here’s what we’ve been up to in the last month:
October was a very exciting month, with CitizenCon taking place in Manchester this year. To coincide with this event, Turbulent delivered many new updates to the website.
The Referral Program was unveiled at CitizenCon. It allows Citizens to invite their friends to play Star Citizen. The new system not only gives rewards to the new recruits, but also implements unique rewards to be given to backers every time that someone used their referral code to create an account and purchase a game package. The more recruits that you invite, the more rewards that you can access. In the future, we will reveal higher-level rewards.
We were also thrilled to be part of the unveiling of Squadron 42. We added a new landing page on the website to introduce this exciting new single player module to Star Citizen. An amazing cast was announced, but we will have to wait and see where they fit in the Squadron 42 storyline. Stay tuned for future updates on the cast and the game.
CitizenCon also saw the introduction of a new ship, the Aegis Sabre: a lightweight fighter to be used as a “rapid responder”. With its sleek, performance-oriented design, the Sabre was a hot item, rivaling the sales and community excitement of much larger ships.
Finally, Turbulent was proud to unveil the long-anticipated Starmap and we were thrilled about how you the community have embraced it. We are continually collecting your feedback to help us plan future versions of the Starmap, as we work to make it as polished, realistic and comprehensive as possible. Not only did the Starmap catch the imagination of our community, as to what their game universe would look like, but it also caught the eye of the web design industry. The Starmap already has been the nominee and recipient of many awards for web design/development excellence, including being featured on Google’s Chrome Experiments, as well as winning the FWA (Favorite Website Awards) Site of the Day (October 30) and AWWWards Site of the Day (October 30), CSSDA (CSS Design Awards) Website of the Day (October 20).
With CitizenCon done and 2016 on the way, there is no rest for the wicked here at Turbulent as we are currently planning our next projects for Star Citizen and cannot wait to present to you what we will do next!