View source for Comm-Link:Monthly Report - February 2016

{{Infobox commlink
|title = Monthly Report: February 2016
|url = https://robertsspaceindustries.com/comm-link/transmission/15224-Monthly-Studio-Report-February-2016
|type = Transmission
|image = |publicationdate = 2016-03-05
|series = Monthly Reports
}}

'''Greetings Citizens,'''

We had an extra day this February, and we put it to good use! [[Star Citizen Alpha 2.2.0|Star Citizen Alpha 2.2]] is now ‘live’ and Citizens everywhere are making good use of the new features to expand their adventures around [[Crusader]]. Between the hostility system, physicalized EVA and the increased instance limit, things are hopping! An extra special thank you to our front line [[PTU]] testers this month, who helped us put out an astounding nine builds before we released 2.2! With 2.2 live, the team is eager to move on to features to be added for [[Star Citizen Alpha 2.3.0|2.3]]… but before that happens, we’ll take our monthly look back at Star Citizen’s progress for February 2016.

[https://player.vimeo.com/video/157493381 Vimeo video]

== CIG LOS ANGELES ==

[[File:MonthlyReport-201602-LA-2.jpg|300px]]

Greetings Citizens!

We are back again with another month in 2016 that has come and gone. Time does seem to fly when you are having fun, doesn’t it? We are definitely having fun, but make no mistake, we are completely focused on getting more enjoyable content released so you can join our merriment within the black void of space.

With the 2.2 patch released, it is hard to believe it has already been a month since our last community update; not because time flies so quickly but because of how busy the CIG LA office has been these past 29 days (we definitely appreciate the Leap Year giving us an extra day to polish content). Just to give you an idea of what we have been up to, here is a breakdown of what each development team in the LA office has been up to.

=== Engineering ===

[[File:MonthlyReport-201602-LA-1.jpg|300px]]

The LA Engineering team has been elbows-deep in new technologies that are getting incorporated into Star Citizen. Starting with Allen Chen’s efforts, we have looked at how player interactions work in-game. For example, when planning out how a player will interact with an object, we realized that a single “Use” prompt was limiting us to a single predefined interaction with an object that didn’t take context into account. By allowing each object to handle interaction logic by itself, this reduces the amount of extra effort required to maintain all of the implementations. Allen has engineered the system so that each contextually possible interaction for an object will contain a localized string token that will be used by the UI to display the description of that action. This leads to a system that allows us to add, remove, enable, or disable interactions on an as-needed basis instead of a more cumbersome and error-prone ad hoc basis.

You may have heard us mention updates to the Shield system in our news updates, “10 for the Developers” series of videos, and other news outlets. While the Tech Design side is being handled by Lead Tech Designer Kirk Tome, the Engineering side is being performed by Associate Engineer Chad Zamzow with oversight by Lead Engineer Paul Reindell. Chad has been working on implementing the “Shield Generator” item to the revised design spec. A large part of this consists of matching the new components to the new design which involves pulling power and converting that power into shield points to be pushed into the corresponding shield pipe.

In an effort to increase efficiency in our coding and to help provide the Tech Designers with more powerful tools, we have created our own in-house tool we call DataForge. This tool allows us to create data quickly within the game without the need for parsing. This database not only allows us to view data in multiple ways, it also loads data faster and ensures that the data are adhering to a specific schema.

Both Mark Abent and John Pritchett have been hard at work behind the scenes, performing various changes to our game data that have potentially long-standing implications to how our data functions. Mark has been providing support for projectile creation through DataForge while John has been working on tweaks to the Thrusters and EVA. Mark’s changes to the Projectiles provides our Tech Designers with a powerful option to create projectiles directly through DataForge without having to go through XML editing. Flight Engineer John Pritchett has been busy cleaning up Thruster effects to fix the thruster effect range, boost effect range, and adding transitional effects when activating Boost.

=== Tech Design ===

[[File:MonthlyReport-201602-LA-3.jpg|300px]]

With the 2.2 release imminent, fixing bugs for 2.2 was the utmost priority for the Tech Design team this past month. Although Shield system has been at the forefront of the Tech Design team’s tasks with regards to new content, our ships have been making great progress through the pipeline as well.

Tech Design Lead Kirk Tome has completed the grey box stage of the Xi’An Scout. If you have not watched the recent “10 for the Developers” featuring Mr. Tome, you will find an abundance of information and updates regarding the Xi’An Scout. While the grey box stage has been completed, the final tech design for the Scout is still underway. Furthermore, Kirk has spent a considerable time performing a re-factor of in-game masses. Starting with the ships, he has been researching a more accurate and proper way of calculating the mass.

Apart from creating a metric for Shield performance, Tech Designer Calix is in the midst of completing the white box tech design stage of the Drake Caterpillar. This stage includes determining where the components will be located throughout the ship, the layout, along with other important features such as the list of what weapons it will have, where they’re located and most importantly, the basics of how the Cargo mechanic will function. Finally, with our components constantly evolving, Calix is designing how Power and Cooling will function within our ships.

As mentioned in the Engineering section, with the creation of our in-house tool, DataForge, it allows the Tech Design team greater efficiency and flexibility when creating new items and experimenting with parameterization (laying the groundwork for future balancing passes). Tech Designer Matt Sherman is in the middle of converting all of our Projectiles from XML and setting them up in DataForge. Since this is an ongoing and evolving task, Matt is also responsible for grey box tech designing the MISC Reliant. This includes the metrics that comprise the Reliant such as its internal layout, placement of hardpoints and various components, etc.

=== Art ===

[[File:MonthlyReport-201602-LA-2.jpg|300px]]

When it comes to the CIG LA Art team, there is definitely no shortage of exciting things to report. New ships and old ship revamps along with character updates have been a top priority for the Art team. Furthermore, the Art team has also been responsible for creating lots of new artwork across the game.

While Calix has been working on the white box tech design of the Caterpillar, he has been working hand in hand with 3D Art Lead Elwin Bachiller, who in turn has been working on the modeling white box based on additional concept artwork using updates to the Drake style guide, both created by Concept Artist Gurmukh Bhasin.

Moreover, the LA Art team has also been working on the MISC Reliant, having completed several milestones. Exterior LODs were completed by Daniel Kamentsky, while Elwin completed redesigning the cockpit. The changes to the Reliant’s cockpit include redesigning the UI in order to adhere to updated UI specifications, animation, and textures. These are all part of a “flight prep” pass completed by Elwin. The flight prep pass is a review of everything that is needed before the ship becomes “flight ready.” This includes doing a pass over the damage states, LODs, and other precursor tidbits before it is released.

On the Character side, Artist Omar Aweidah has finished creating high-poly geometry for undersuit armor and several UEE Navy item variants have been his responsibility.

Speaking of costumes, Jeremiah Lee is submitting a first pass for the Heavy Armor concept after completing an early design pass on the same. Like our spaceships, designing armor and clothing also go through a series of approvals and revisions before they are approved for creation. This ensures we are adhering to thematic style guides based on key manufacturer embellishments.

=== Tech Content ===

The Technical content team is the amalgamation of Tech Art and Tech Animation into a global unified team.

This team consists of Technical Animators and Technical Artists working together to bring together all of the Art, Animation and even Engineering proceeds into a cohesive “in game” asset or feature. Typically this includes complex problem solving across many different pieces of software, educating members of other teams on best practices for coordination and handoffs, constant performance profiling and even reactive bug fixes on release build content, just to name a few. This team also includes key developers that perform the rigging and animation implementations of both ships and characters.

On the ship side, recently-promoted Senior Technical Artist Mark McCall (congratulations on a well-deserved accolade) has been tackling animation bugs for the 2.2.0 release. These include fixes such issues as the Vanduul Scythe/Glaive firing animations, adding steps to prevent clipping animations of the Landing Gear through Mannequin, optimizing thruster setups and many other important fixes.

Meanwhile, Patrick Salerno is continuing the review of all ship LODs and normalizing the mesh count and more importantly density. Patrick is making a huge effort to ensure that performance is at the highest possible level across all of these ships and is currently reviewing the Mustang and Hornet along with each respective variant.

Senior Tech Artist Matt Intrieri is currently performing an LOD pass on various ship components which include the landing gear, escape pods, thrusters, intakes, and many other components. This is an ongoing task given the number of assets requiring his review. Associate Rigger Gaige Hallman and Senior Rigger John Riggs have completed rigging of various character assets that will become obvious to players once character customization comes online. Gaige has finalized the process of skinning vertices from the character models whilst John has completed the asset rigging and simulation setup for the UEE Navy BDU uniform. Next up for John is performing R&D for rigging the Vanduul – we can’t wait to see the results of this!

=== Narrative ===

For the most part, we’ve been focusing pretty heavily on Squadron 42. Lead Dave Haddock has bounced over to the UK for the month while Will’s been Skyping in to have daily meetings with the Squadron 42 designers to step through the game to see how the levels and gameplay have been progressing, to see if any changes have necessitated any additional pick-up lines from our higher tier actors, and delve a little deeper into the dialogue and narrative needs for the secondary (non-principal) cast members.

On the PU front, we’ve been working with Designers in Austin and the UK to flesh out more of the landing zones, provide lore support for ship components and help out with developing narrative in the Baby PU.

In the [[Starmap]] and [[Galactapedia]] arenas, Adam finished his review of the previously published Galactic Guides, resulting in a monstrous 120-page document outlining potential changes/disparities that would need to be made to bring either the Galactic Guide or the Starmap in sync. We will all sit down and go through each one to talk them out. Meanwhile, Cherie has continued to work with our awesome astronomy consultants to generate the scientific data while waging her epic battle with the internal wiki.

So that’s it for us. Nothing terribly new to report (that we can disclose at least), but continuing to chip away at the mountain of needs.

=== Quality Assurance ===

CIG LA’s Quality Assurance team expanded as we welcomed two new testers to the team after extensively reviewing applicants; Eric Pietro and Colby Schneider have joined Vincent Sinatra as members of the CIG LA Quality Assurance department – and their timing could not have been better. Considerable time was spent training the duo and getting them up to speed with regards to CIG’s QA methodologies, software testing theory, and acclimating them to our fun world. In a few short days they were ready to hit the ground running; the LA QA team aided our ATX and UK counterparts in testing the new 2.2 code for PTU pushes, as well as investigated a number of issues for Design and Development, including but not limited to:
* The new Hostility Feature
* Sabre Flight Performance & Equipment loadouts
* New cooler component implementation
* EVA adjustments and zone grid transitions
* Ship entry animations
* The transition from 16 to 24 playable ships in Crusader
* Shield recharge times
The QA team also performed an audit of the mass for all ships, as well as a landing gear pass to ensure everything lined up to specs and was functioning correctly.

=== Conclusion ===

As always, this is just the tip of the iceberg of what is going on behind the scenes here in Los Angeles. We are not only excited about you enjoying 2.2, we are also planning for the future and working on quite a large pool of features that are slated for later patches. We are only two months into 2016 and we are always looking at what is next, ready to face these challenges, knowing that the trust you have for us is greatly appreciated. We are proud to have you along for this epic adventure, in the game and out, and we hope you look forward to seeing the major developments to be released in Star Citizen in the coming months of 2016.

[https://player.vimeo.com/video/157484402 vimeo video]

== CIG AUSTIN ==

[[File:MonthlyReport-201602-Austin_Header.jpg|300px]]

'''Greetings Citizens,'''

February began with a push to get 2.1.2 to the Live server, and ended with a push to get 2.2.0 to the Live server. It’s been a busy month and we’ve made an incredible amount of progress on many fronts! The Persistent Universe team has been hard at work, and will have results to show in game very soon. QA and Live Ops have been working around the clock as always, and the global nature of our company and our community allows us to make continuous forward progress on our goals any time of the day or night. Enjoy some detailed reports from each team leader!

=== Persistent Universe ===

[[File:MonthlyReport-201602-Austin_Shot_1_Scout.jpg|300px]]

The PU Team in Austin has been making significant progress on several different features this month, the main one being PERISTENCE! Yes that’s right, the cornerstone feature of a “persistent” universe is indeed the ability to persist data across play sessions, and Jason Ely and the server team here in Austin have been making great strides into laying the groundwork on the backend. We are rounding the corner on this massive undertaking, having rewritten whole portions of the codebase to get this integrated into the game. The first feature we’ve been testing with is “Shopping”, and our first release with Persistence in it will utilize Casaba Outlet’s stock of shirts, pants, jackets, etc. to show off persistent gameplay. We’ve also been brainstorming other ideas for opportunities to utilize Persistence in gameplay, such as player health, ship/item health, currency, and reputation.

Having mentioned Shopping, let me elaborate on this feature a bit more. This month we’ve solidified the flow of Shopping Phase 1, and we’re wrapping up the tasks that are required to set up Casaba Outlet as a shop in game. This means setting up the clothing racks with items, tagging each item with the tags necessary to get it to show up in the UI correctly, and calling out variants for the clothing assets that have been made so the Character Team can schedule these in. We hope to populate the shop with enough to keep you guys engaged on the first release, but leave enough empty space to allow us to fill it with more varied clothing assets later on down the line.

Ship Artists Chris Smith and Josh Coons spent their time this month wrapping up Final Art phase for the Xi’an Scout. They’ll be moving on to the Herald next month, we’re excited to see what they do with it. Emre Switzer finished lighting passes on the shops for the Levski landing zone in Nyx, as well as for the Asteroid and Business Hangar. Mark Skelton has completed several style guides for clothing manufacturers within the ‘verse that will inform character concept artists and 3d modelers going forward.

Our Animators spent much of this month developing animations for use in Astro Armada and G-Loc Bar. We also did some work on various enter/exit speeds for the Avenger and Aurora, and we hope to carry this over for all ships into next month. Lead Ship Animator Jay Brushwood spent a couple weeks in the UK syncing up with the Ship Team there, establishing steps in the pipeline and ironing out kinks in the workflow and communication. It was a very productive trip, it’s always good for folks to get face-time with other studios when possible.

Lastly, work wrapped up on the Friends System 2.0, which transitions the Friends/Contacts system from Platform to our backend services. This new Friends System incorporates some much needed new features, such as the Ignore List. This has been handed off to our UI Team to schedule in and create the front-end work for this feature.

=== Live Operations ===

==== QA ====

When the month of February began QA was wrapping up our previous release of Star Citizen Alpha 2.1.2 to our Live environment. QA continued to investigate a couple of lingering issues as well as gathered public feedback. Shortly thereafter, QA began focusing efforts squarely on testing the new features which would be included in the next release.

Todd Raffray headed up an early test of the new Party System updates. Each feature improvement was documented and individually tested to ensure the updates worked effectively. QA was very happy to ensure that playing with your friends would be much improved in 2.2.0.

The team then began testing additional features that were slated to be included in 2.2.0. These included Monitored Space, The Hostility System, and the changes to the layout of the Crusader map. The team also created a list of must fix issues which was then delivered to production.

Each new system was meticulously tested by the coordinated efforts of each of our QA teams around the world. The day would begin with our QA teams in UK and Frankfurt beginning testing headed up by the leadership of QA Manager Phil Webster and Senior QA Tester Steven Brennon. As the day progressed, the testing would be handed off to our US QA teams headed up by QA Leads Andrew Hesse and Vincent Sinatra. The daily information hand-offs went very smoothly and contributed to almost 24 hour daily testing coverage. This coverage ensured development continued smoothly to help release 2.2.0 as soon as possible.

As new 2.2.0 features came online, they were added to our list of things to test for release. These included flight testing of the newly flyable Sabre, the hangar ready Xi’an Scout, ship cooler items and the new physically based zero gravity EVA.

Additional in-depth testing was conducted on the ship combat time to kill values for each available ship and weapon as well as a comprehensive pass on the ship landing and repair mechanics.

We have had some new recruits added to our ranks this month. Phil Webster has joined our Foundry 42 office in Manchester, UK. Phil comes to us from Sony. Phil will be fulfilling the role of QA Manager and is already doing great things leading the Foundry 42 team. Please welcome Lee Jones to our Foundry 42 testing team. Lee also comes to us from Sony and will be assisting our Veteran Liam Guest in dedicated Squadron 42 testing.

We also have 2 new testers joining our LA studio this month. Eric Pietro and Colby Anderson. Both Eric and Colby have industry experience and have already proven to be great additions to the LA QA team.

Senior QA Tester Christopher Speaks travelled from our Frankfurt studio to Foundry 42 and held training sessions for our UKQA team on the testing and use of the Cryengine Sandbox Editor.

Right now the team is working hard to get 2.2.0 out to the live environment as soon as possible. For the month of March, the team will be focusing on testing the new additions which will be included in Star Citizen Alpha 2.3.0. We are very much looking forward to the new content coming soon. See you in the Verse!

==== Game Support ====

February has been an amazing month for Will Leverett and Chris Danks as Game Support worked feverishly alongside QA, Production, and our PTU testers to get 2.2.0 branched, built, tested, fixed, and shipped out the door. To go from branching to full release in three weeks is amazing, and we think we can still improve the process to make it even better.

We spent quite a bit of time this month working on establishing our new protocols for PTU invite waves. This was accomplished by focusing on Issue Council engagement and previous PTU participation. From our perspective, 2.2.0 on PTU has been amazingly successful, and in no small part due to the passionate backers who were always ready to help. We’ve gotten amazing feedback that went right into the development pipeline, particularly through the Issue Council and structured playtests.

Many players have questioned why we did not roll out 2.2.0 to a greater number of players on PTU, or what the downside is to having more players involved. The answer is twofold: 1) cost and 2) 2.2.0 simply did not require additional waves for testing (in fact, sometimes having fewer is better). Each build download and every server costs money, and if we can avoid unnecessary expenditures while still accomplishing our development goals, that helps everyone in the long run. Additionally, bugs involving resource allocation and network bandwidth can result in errors that manifest quickly even with relatively small numbers of players. When bugs of this kind are involved, expanding PTU access often doesn’t help diagnose the problem, it just makes it worse – incurring higher cost for no benefit is just plain wasteful. In cases like this, bugfixes are investigated and applied while the addition of additional waves of testers proceeds at a much more controlled rate until it’s clear that the blocker has been addressed.

A very healthy 70% of the Wave One group participated in at least one build since 2.2.0 went to PTU, and we’ll cull the other 30% from the list in order to rotate in others who want in to help with active testing. 
Aside from 2.2.0, Game Support was able to spend time on our service issues, getting completely caught up on our tickets (along with our colleagues in Customer Service) and we’re excited that we can provide quick turnarounds now to players who need individual support.

Related to that, Game Support will be working with Customer Service and Turbulent to assess different options for creating a true knowledge base that serves the players of Star Citizen. We certainly don’t want to roll out a drab, mechanical site, but instead provide a medium in which the community can interact, find solutions, and when possible, help each other.

It’s been a super productive month, and we’re excited to roll right into March on the road to 2.3.0!

==== IT/Operations ====

February has been about Data. We are working on an important project with the rest of the Operations teams and key Development team members in our Frankfurt studio to fix these huge patches once and for all. This project could take some time to roll out due to the depth of work involved but the project is too exciting not to mention.

Patch sizes have to do with the way the data is prepared for each version we publish. We know that patch differential between builds includes between 5-10% change for most builds. However, because the changed files are mixed with the unchanged files then compressed to larger pak files for delivery, even one small change in data can cause an entire pak file look different to the patcher due to the output of the compression scheme, which the patcher sees as an entirely new large file.

In order to correct this, we need to change a number of things including how the game engine reads data. We also need to change the build system and the entire delivery pipeline in order to do this right. Once done, we’re expecting to see major improvement in the size of patches between versions but we’re hoping for even more. Changes to the build system supporting this new approach should also allow us to do more incremental data builds rather than the much longer full builds. This would greatly reduce the time between developer fixes and testing, particularly for a game the size of Star Citizen.

==== LiveOps ====

This month the team has been working around the clock on deployments and the build system. We delivered 8 publishes to PTU with major improvements to the process allowing us to minimize downtime to moments from hours. Our analytics reporting has undergone major improvement in February both on the client and data side.

Our build system has been undergoing some substantial changes at the same time which leads to a tricky balancing act when trying to keep up with all the internal builds and PTU publishes. So far we’ve rolled out a new distributed compilation system which has shaved another 75-90% off the build times depending on build type, a new format for keeping track of data, internal and external automated crash reporting, as well as a completely new inclusion/exclusion system which helps us refine our builds down to specific testing goals.

We’ve also been working closely with the IT team and the rest of the Operations teams toward the goal of reducing our patch sizes. This task will likely trigger the largest set of changes introduced to the build system to date since we’re incorporating major changes to the build process as well as the delivery pipeline which will have positive impact on internal development as well as external patch delivery. In order to make all this happen while maintaining full support of the existing development schedule we will be building a completely separate build system which will run in parallel to the existing system. IT better crank up their air conditioners because we’re gonna smoke those servers!

{{#ev:youtube|https://youtu.be/DFkTG9YungQ}}

== FOUNDRY 42 UK ==

[[File:MonthlyReport-1602-UK-Header-Feb-2016.jpg|300px]]

'''Hello Star Citizens!'''

Between Star Citizen 2.2 and continuing work on Foundry 42, all of the Foundry 42 UK teams have been working hard and delivering excellent results. Keep in mind that we can’t share everything for fear of spoiling the events of Squadron 42… but there’s still plenty we CAN talk about.

=== Design ===

We have had another busy month in the UK design department. We are still working on the “new player experience” which is hopefully going to make the learning curve less steep for new backers. This not only encompasses a simplified UI set, but also has a refactor of the controls system to be more conceptually consistent across the various game modes such as EVA, FPS, and space flight. We are still working on [[mobiGlas]], this is a biggie as it is one of the major aspects of both S42 and the PU so we want to get it right the first time around. Scanning, for both cockpit and FPS, is now underway, and we are looking forward to getting sub-targeting of components into the game soon.

Andrew and the Tech team have had a number of meetings about the various balancing issues and we are hopeful that you will start to see the positive results in the coming releases (not in time for 2.2 unfortunately).

The [[Idris]] is getting closer to a game ready state and we have enjoyed our first forays into the test universe with a design team crewing it.

S42 is moving along nicely and we are starting to see blockers shifted in a timely manner so the design truck can keep rolling.

=== Audio ===

It’s been a jam-packed month as far as CIG Audio is concerned. Apart from the usual bug fixes, we had a very nasty in-game distortion issue at the start of February that was extremely hard to reproduce, and near-impossible to profile. Thanks to our fantastic QA department, as well as Sam Hall, Graham Phillipson, Mikhail Korotyaev and our friends at Audiokinetic for assisting with fixing that, and the community at large who were hugely helpful in sending us data and user stories. Apologies to anyone who suffered from this but we reacted to it as fast as we could. Good came of it, in that we now have added some analytics for the audio system, so we can keep an eye on audio resource usage in the wild (again, thanks to Sam for pushing that out there).

Work continues apace on ‘Squadron 42’, and Ross Tregenza has continued with putting down as many audio foundations as possible, and keeping close eye on cross-discipline progress. All of the systematic elements we’re working on across the whole game feed into Squadron 42, but there’s still a lot of custom and bespoke aspects of it to keep track of and make sure we’re ready for, so that when the time is right the whole team will sweep across this module.

Ross also worked with Sam Hall on the monitored zone system audio which you’ll witness soon enough, it’s still in a relatively early stage where the audio is concerned and we’ll improve this further as we iterate upon it.

Bob Rissolo has been very heavily invested in the Dialogue Pipeline tools and database. This is quite a large project in itself, that feeds into the main Star Citizen experience but is again very important for Squadron 42 which is going to be very character dialogue-centric. He’s been mainly working with Simon Price, who’s joined us as a Consultant Audio Programmer.

Bob Rissolo and Phil Smallwood built up and tested out the dialogue recording rig extensively in a test shoot in mid-February, to make sure we’re up to the task of recording dialogue for performance capture sessions. For the most part it all worked as expected with only minor settings tweaks and optimisations required.

Sam Hall has submitted Version 2.0 of the Music System, including a visual logic editor. This shipped in 2.2.0 and was a ‘surprisingly smooth’ transition, at least so he says! Until we get some new content it might not be hugely obvious it’s there, which is a good thing in some respects. You want an in-game soundtrack and musical cues to sound as natural as it does in the movies, if not moreso. If it were to catch your attention unnecessarily, it could be more distracting than immersive.

Talking of new music content though: myself, Ross Tregenza and Pedro Macedo Camacho combined our powers and braved the (actually rather mild) Slovakian winter to attend our first orchestral performance this year, at the Slovak Radio building with the Slovakian National Symphony Orchestra. This provided us with new content for ship-based space combat, which will feed into the aforementioned music-logic system when the material is ready; we still need to add some extra momentary layers and elements for it to be as reactive to the game as Chris Roberts desires. Chris is very into his dynamic music, having pioneered such a system back on ‘Wing Commander’. So, we still have the extra material to come before we take it to a mixing session to give it some polish, after we’ve proven its effectiveness in our new system. Will keep you posted, and try to get some material from this out for you to experience when the time is right. Many thanks to our conductor Allan Wilson, recording engineer Peter Fuchs and our orchestral fixer Paul Talkington for arranging things.

These days we’re thinking heavily about dynamic/procedural mix methods, rather than the usual state-based mixing that’s common to more linear titles. To this end Darren Lambourne has been putting together a dynamic bass management prototype, which is a great place to start when it comes to figuring out mix fundamentals within Wwise. Many games suffer from the summation of too much low-end and we want to keep the experience clean, and configurable, for our users to reflect their different demands and differing set-ups. Will let you know when we have this ready to push out to the game proper but so far it’s quite promising.

And talking of mix – Darren is also working on a parametric mix/effects system to reflect atmospheric depressurisation, whether that’s out in space or when inside depressurised interior locations. We have the concept right now whereby exterior sound is simulated within ships – controversial we know but we feel it makes sense! However, the player suit when exposed to space independent of one’s ship, in our lore at least, it doesn’t have the processing power to perform the same function, at least not to the same level of fidelity. So what you’ll probably hear will be much more akin to structure-borne sound transmission, coupled with a lot of suit/internalised elements. We’re just starting with this one and we want it to be consistent with logic and gameplay, but also dramatically satisfying in its own right. Will share more once we have this at a good place.

Darren’s also pushed out some great EVA audio improvements, particularly re. the manoeuvring jetpack thrusters. We hope you appreciate this one, the articulation is way ahead of where it was previously. In some ways this is now much more subtle, but also far more responsive to player input. We’ll get together some video to show this off properly but it’s far more characterful while still retaining subtlety. We hope you like it.

Stefan Rutherford’s been working on some space-station mixing – there’s some neat bass modulation on one of the stations that varies things as you traverse. He’s done some lovely stuff on the Reliant, too; he’s produced ship ambient mark-up, with parameterisation of sounds so that all of them become far more responsive to external factors. E.g. power-plant level, ship strain. Under his model a single light buzz on a panel can change in tone and timbre, if power output is high to other components – because non-critical ones (such as a light) are receiving less power. A light fitting will also tend to rattle when the ship is undergoing excessive gravitational forces or ‘excitement’. We hope the summation of this level of detail will contribute to the ship experience.

Thanks to hard work by Graham Phillipson and Matteo Cerquone, we now have a solid and working piece of tech for ‘Automatic Character Foley’ in place. Traditionally, this sort of character-based sound would be spotted by hand to animation files, but we wanted to make this far more system-driven, as it’s a very labour intensive approach that doesn’t stand up to variable wearables (that’s a tough thing to say) or animation and clothing simply changing dynamically. So now, we have a system that modulates clothing and equipment sounds in response to limb velocities. We’ll hopefully be able to factor in clothing changes soon too, plus added equipment layers that’ll change depending on what weapon you may have equipped. Matteo’s also been working with the Xi’an Scout which has some great SFX in place.

Following on from the auto Foley though, we now also have a solid prototype for Automated Footsteps. Again, this is traditionally very labour intensive stuff, whereby sound designers would open up an animation file and spot to a timeline. That’s not a robust enough solution for us, so Graham has somehow figured out a way to infer accurate footstep movement and articulation, and play back appropriate sounds – in real time. We know this might not seem like a massive deal but there are many sound designers who’ve contributed man-months to this very task in the past so to solve this problem… well, one of us cried a tear of joy. Almost.

As fuel for the Foley fires (again with the tongue-twisters), we have a ‘wild Foley’ session upcoming to record footsteps, and some physics object style sounds (impacts, slides, rolls etc.). Stefan and Matteo will be overseeing that session, hopefully we’ll gather some eminently usable material there.

We also have a firearms session due at the end of March to capture outdoor gun-fire impulses/tails in an urban environment, for in-atmosphere locations with lots of reflective surfaces, in contrast to our earlier interior sessions which were more ‘roomy’, this is all about distant reflections that help define the outdoors.

Jason Cobb has been working on bug fixes, design documentation, scripting improvements to workflow. He also has sound design coming together for ship debris clouds, subject to a system to drive this properly, but looking forward to that.

Luke Hatton has continued on ship sounds, as is his specialism – we’re always fixing and refining audio for those as you know!

Oh, watch out for an upcoming extended version of the Big Benny Noodles theme. But I’ve already said too much about this, I’m sure…

Thanks for listening everyone, sorry it was such a long update but it’s been a big old month. We blame the leap year thing. Thanks!

=== Engineering ===

This month’s new big feature for the live releases is the hostility system. We wanted to start coming up with ways where you could see that your actions would have some sort of consequence, and as a result get some additional emergent gameplay going on. As a first step we’ve introduced safe zones, such as around Port Olisar, where the space will be monitored for any illegal behaviour. If you start shooting up an innocent party in the zone you will automatically get a wanted level, become a hostile, you will be marked up on everybody else’s radar as hostile and as you fire on more and more innocent parties the higher your wanted level goes up. Whilst you’re in the safe zone AI will spawn in and try and take you down. To make it more interesting if you have a wanted level you also become fair game for all the other players, so now anybody can now attack you without fear of reprisal. Of course if you are attacking other players outside of a monitored zone it won’t get noticed and your global reputation stands intact, although the players you attacked will remember and see you as hostile going forwards. You can reduce your wanted level though by using a terminal to hack into the system…

Outside of the releases, we’ve been making progress on lots of the other systems. The code to support turrets has been having a bit of an overhaul as previously it was tied very closely to the vehicles, whereas we want to have standalone turrets on a space station for example. We kicked off work on the scanning feature, where you will be able to use your radar to scan vehicles in more detail and get information as to what weapons they’ve got or even what cargo they’re carrying. This of course depends on how good your scanning hardware is and how good the blocking hardware of what you’re trying to scan has. This scanning is also going to be incorporated in the same way when in FPS mode so you can get information about the players around you.

Talking about FPS again it’s about making steady progress on all its mechanics. The new physicalized EVA is getting more and more solid, we’ve been spending a lot of time trying to fix up a lot of edge case issues, mostly when transitioning from inside a vehicle to outside, so you’re going from gravity to zero-g, or vice-versa (or from non-EVA to EVA). Cover is getting better and work has now started on prone and vaulting.

=== Graphics ===

[[File:MonthlyReport-1602-Optics1_New.png|300px|right|thumb|WIP - New Optics #1]]
[[File:MonthlyReport-1602-Optics1_Old.png|300px|right|thumb|WIP - Old Optics #1]]
[[File:MonthlyReport-1602-Optics2_New.png|300px|right|thumb|WIP - New Optics #2]]
[[File:MonthlyReport-1602-Optics2_Old.png|300px|right|thumb|WIP - Old Optics #2]]

This month the team has completed some final R&D work into the Gas Cloud tech, and out of that has created a roadmap for the gas cloud system. This outlines when we can start giving this tech to our other internal teams, such as art and design, to work with.

After discovering resolving several bugs with our recent Vis Area/Zone tweaks, the team moved to working on the facial tech. This work has been testing the current framework, to find performance bottle necks, bugs and the look to make general improvements to the tech to get the best out of it without reducing performance.

We have also been working on updates to bloom and lens flares. The current bloom implementation has a harsh falloff around glowing objects and requires their brightness to be cranked up significantly to be visible. The new system will allow for more subtle glows with a softer falloff, and its performance will also scale better with higher resolutions.

With the current flare system, an artist has to create a flare set for each light that generates flares, and simulating different lenses (e.g. for cinematics vs gameplay) which requires a lot of manual work creating multiple sets. There is also a limit on the number of flares that can be rendered per frame before they start breaking. We’re working on a system to procedurally render flares in screen space with a more physically based method, and the new system should significantly reduce the workload for artists and make it easier to change the look of the scene on the fly.

=== VFX ===

This month the VFX team have been working on getting the latest flight-ready ships including the Vanguard and Sabre. We’ve also done some thorough R&D for the Xi’An Scout effects, as we want to tie in with the fiction and create a unique style of effects compared to the human and Vanduul technologies. This all based on the VFX style guide which we mentioned in last month’s report; building a consistent visual language through a ship’s effects is very important for player readability, especially against the vast backdrop of space!

Away from ships, things are progressing solidly on Squadron 42’s environmental effects, as the environment and design teams have been fleshing out their levels in greater detail which allows us to jump in and add effects where required. There’s so much here we would love to tell you about but we can’t for obvious reasons – no spoilers!

=== Art ===

The team has been full steam ahead, internal concept and external all busting out fab looking work and it’s been a varied lot too!

Here’s a list which I’m sure you can discern what belongs to what: the Idris Gravity Generator room, Idris Cargo Room, Idris story line look dev, Planet look dev, Vanduul weapon look dev, Bengal Hangar, Hangar Breakouts, Bengal Bridge console/chair refinement, Powerplants, Quantum Drives, Coolers, Military props, Shubin Pilot briefing room, Shubin Bridge, [REDACTED] ship cargo room, Research Station look dev for the Gravity room and communal areas, Scourge Rail gun final pass, Rail Attachment system, ammo and just started on a new small ship! Oh – and some 2nd pass concept on storyline bases – that’s it for Feb!

=== Props ===

There is a running theme here, another month and a few more ship components! We now have the first couple of coolers and shield generators complete and the power plants have been started. 
But more exciting than that is that our team has grown! We have gone from 2 in the UK at the start of January up to 4, with our 5th member joining next week!

Apart from the ship components the team has been focusing on low tech props, we are focusing mainly on assets that can be used in both the PU environments as well as the squadron 42 environments. We have completed a few more tests with the blend layer material mentioned last month and have asked for a few little tweaks from the rendering team before we can go full steam ahead with it.

Finally we’ve have been making an effort to get on top of our documentation backlog. Now the teams growing it’s really important to have our pipeline properly documented and as its evolved over the last couple of months there is a bit to update! I’ve also been creating and updating our template files to make the animators lives a little easier and improve consistency across the board.

=== Characters ===

Our two man team has been busy as a pair of motivated bees, I’m not going to spoil any surprises but the character work now is really starting to matchup with the rest of the game in terms of fidelity and quality – exciting times, plus we have hired 2 more people to join the UK team – things are looking up!

=== Environment Art ===

This month the environment team have been hard at work fleshing out the environments for Squadron 42, there is a huge range of environments in production currently, so there is a frenzy of activity within the team. There is lots of back and forth between the level artists and designers as they move forwards refining the designs and layouts, something which is quick and entirely real-time using our modular system. That’s it for this months, back to it!

=== Ships ===

The Ship Team has been in the process of planning their angle of attack for the rest of the year, laying foundations down to hopefully make the rest of the year’s production run smoothly to push towards fully content complete of the SQ42 within the next few months ( content complete meaning all assets are in-game, playable but requiring polish ). Major highlights of this process have been pulling the RSI Bengal into a metric system that will take full advantage of a modular construction approach, much like we have done on the Idris, meaning we can have twice as much visual awesomeness with less of a knock on to both visual and memory costs in the engine. The Bengal was the first ship to be seen ever for Star Citizen in the original reveal, it’s like the Crown Jewel of SC and will be treated as such!

Both the Aegis Idris and [[Javelin]] have continued into final production, the Javelin taking full advantage of the Idris’ interior modules, meaning essentially whatever wins we make on the Idris roll over to the Javelin by default, this also has the added benefit that the Javelins interior production will in fact finish not far behind the Idris even though production on the Idris started several months before, we are gaining variation between the two ships with a clever use of material swaps, lighting and atmospherics, the Javelins will have a far more grittier feel to suit its role / characteristic as a ship.

On top of the above, production is almost complete on the Starfarer Base variant, she is looking beautiful indeed, but more so in our opinion is the Gemini variant, the Gemini being kitted out by Aegis really brings an interesting dynamic to the ship’s aesthetic.

{{#ev:youtube|https://youtu.be/MGzOj9mWB4U}}

== FOUNDRY 42 FRANKFURT ==

[[File:MonthlyReport-201602-DE-Header-Feb-2016.jpg|300px]]

'''Greetings Citizens,'''

The weather in Frankfurt this month was definitely colder than last, but it hasn’t slowed us down. This month the team added new people in Weapons Art, Animation, AI, and Game Programming, we’re now up to 37. As the team grows out here we can feel it continuing to pick up momentum, which is always a good thing.

Early in the month we had a handful of internal visitors to the office including Chris and Erin. It gave us a good amount of time to look through schedules, adjust priorities, discuss design systems and tech approaches, etc. We also had a few backers through the office which was fun, the team appreciated the good words and the fattening treats.

Thanks again for all the German team support from the backers and fans, it means a lot to us.

=== AI ===

Early in the month we completed the first pass on the refactoring of the Human perception. The new perception is now fully distributed and optimized: we mostly split the perception into visual perception and audio perception. All the other stimuli are either perceived currently as audio or visual objects. In the future we are planning to have several types of senses that can be plugged into the perception if needed.

The vision perception is mostly based on the CryEngine VisionMap, it allowed us to have a very flexible system that on the CPU side uses an average of 0.01ms! The audio map allows us to model the perception of sound stimuli and it also uses an average of 0.01ms! The new perception abstracts what’s perceived by the different sense and what we use as the target: the behavior tree is in control of the selection of the target and we are also supporting future extensions for characters that might be able to track multiple targets at the same time.

[[File:MonthlyReport-201602-AI.jpg|300px]]

H3. Notes on the Image
* The yellow lines represent the audio events that each NPC has received in relation of different sources.
* The blue lines point to the last position when the target has transitioned between being visible and not visible.
* The green lines point to visible objects in the world for each NPC
* The pink lines represent the attention target of the NPC. If the target is visible it points to the entity otherwise to the last known position of the target.
We also made very good progresses on Subsumption. We now have a proper tool developed directly by Tony Zurovec, from Austin, that allows the designers to create Subsumption routines. On our side we process the data created by this tool to actually transform data into behaviors that run in the game. We currently have a first version of NPCs running Subsumption, and the code is very optimised in memory. 50 characters running different Subactivities uses around 12Kb of memory. Subsumption is controlled by our high level behavior tree so that any character can also be able to react quickly to combat scenarios using our systemic combat behaviors.

We then improved several aspects of the Cover usage, we introduce the functionality to blacklist specific cover spots for a specific amount of time, and avoid the effect of NPCs nonsensically selecting covers that have been compromised a few seconds before. We also fixed the selection of the cover based on the actual occupancy size of the character itself so that different NPCs won’t select covers too close to each other.

We completed the ground work to run dynamic behavior trees inside a main high level one, so that scripted requests can be directly accepted and run by the designers only when the behavior tree is ready without conflicting with the main behavior tree. Also we introduced the concept of “Primary” and “Secondary” actions in the AISequences so that we can properly validate the logic setup from the level designers and guarantee that what they want to achieve is correctly communicated to the AI.

Another feature we worked on is the ground work for Assignments, this is the way a designer can suggest specific high level goal to an NPC, something like “Defend a specific area”, “Attack a specific target”, and so on. Along with the above, this should lead to NPCs that can react properly to distractions without completely losing sight of the orders they’ve been given.

In addition to all of that we have continued to improve the stability of the builds in general.

=== Builds Ops ===

We recently switched to use BinXml assets for release builds, this is now the default. Continued work on Trybuild development, deploying and stabilization. We have got a solid db backend now (mysql/postgres), instead of a mere sqlite database, running in a docker container. This allows us to persist data through server and/or service reboots.

We’re doing preparation work to soon switch Transformer to Buildbot Nine. Lots of changes/improvements/fixes have been made across the entire pipeline.

=== Cinematics ===

A crucial cinematic scene right before Admiral Bishop’s speech in the UEE senate got a major upgrade from our side. The work on that is still ongoing.

It seemed crucial to Chris and Hannes that we wanted a bigger canvas for the tragedy of these planetside scenes to play out on. Frank, our Senior Env Artist for Cinematics was quite busy building rubble pieces and other things we don’t want to spoil right now.

For much of the month, Hannes was busy building up these scenes and doing further previs on some Bengal Carrier scenes as UK art is currently jumping on that one. Mike Nagasaka was busy with Chapter 02 and both of us were looking into different holoshader improvement options and did some visual prototyping for a pivotal moment involving alien holo tech during Chapter “X”.

Animation is busy with prepping pcap we have for Chapter “X” which involves the Starfarer and as that ship has progressed nicely to almost final art we can easily tackle those scenes next month.

Bishop’s head model got some refinement, and we tested that as quite some tech issues were fixed since we had him take the stage in the first scene featuring him at the UEE Senate.

As on ongoing side project we are revamping the cinematic timeline module “Trackview” so that it supports the needs for ships and AI characters, as well as major usability fixes. This will go on for quite some time longer and Sascha Hoba or as we call him “the fixer” is doing a tremendous job on that which will help cinematic sequences shine!

=== VFX ===

Over the past few weeks the DE VFX team has been working on getting the Xi’an scout ship ready for release. This includes a full VFX pass, including things such as thruster effects, damage effects, weapon effects and even a new version of the quantum drive based on the Xi’an tech style. You can see the current status in our header image.

=== Tech Art ===

The Tech Art team continued developing the internal animation pipeline, supporting cinematics for various tech setups. The team also worked on the FPS weapons rigs and supported the in-game animation team for finalizing the DCC and engine camera for players and weapons.

=== Engine Programming ===

Our Senior Engine Programmer is Christopher Bolte, and his focus during the last month was on two aspects of the game: data transfer protocols (critical to loading times) and the ObjectContainer System. Most of the time was spent on the new data transfer protocol mentioned last month and we made good progress there.

So far we already have the capability of storing all the assets of the game in a single, very large, pak file and to update this pak file incrementally. The Engine also has the initial support to be able to start from such a pak file. The next steps for the new data patching process is to hook those tools up into our internal build distribution process so that we can test how well the proposed system will perform. Hopefully we can provide updates on how well this worked next month.

The second focus was on providing our UK Engineers with support for the ObjectContainer System. This system is sort of a replacement of our current level format, with the twist that we can load ObjectsContainer when we already have an objects container loaded. Practically this means we can prepare loading a universe scale level with a very large amount of space stations, planets, or large object groups, even where only the parts that are supposed to be visible to the player are resident in memory. This system should allow us long term to scale to extremely large levels containing many interesting and different objects. So far we have initial support working so that we could load levels with ObjectsContainer instead of as levels. This is absolutely critical to providing a seamless gameplay experience with transparent loading times, made all the more crucial by the fact that the client (your) computer actually only has so much memory to work with.

As the next steps we will extent this basic version to space stations and ships so that we can load complex objects more efficiently.

=== Code ===

This month, we made a whole bunch of code related improvements. Including:
* WAF build system rollout. All devs are able to compile the project much faster now.
* Public crash handler rollout with 2.2. Already getting good intel from our community in PTU. Thanks to everybody participating and agreeing to send crash info our way.
* More improvements for code quality tracking (system to track asserts automatically, trybuild on the way to avoid submitting code that doesn’t build against latest code depot).
Additionally:

We’ve made further progress on the much improved patching solution. The plan is to really ever only download files (inside .paks) that changed. In the future we might expose control of data compression on user’s end to allow custom balancing of IO bandwidth vs CPU decompression time. Incorporating a much more modern compression scheme is also planned (much less CPU decompression overhead for similar compression rates). All this will require stabilizing asset file formats so that re-exports of unchanged assets do not invalidate much of the previously shipped content.

Progress started on further improving optimized mesh data storage format. Vertex streams of meshes will get much more aggressive compression of per-vertex normals and tangent frames all the way up to the GPU (decompressed in vertex shader with very little overhead). This will reduce the .pak size, improve load times and streaming, as well as reduce GPU bandwidth which is critically important for the highly (vertex) detailed meshes of our ships, etc.

We’ve also done a good amount of work on the procedural tech, but don’t want to go into the details just yet, we’ll hopefully have a larger update in the near future.

Animation coding was focused primarily on fixing exiting bugs to get the foundation as stable as possible, which will then be easier to build upon.

=== Design ===

At the beginning of the month we had a visit from Chris Roberts and a lot of other people from the all the studios. This was a great opportunity to make sure everyone is on the same track and we are all pulling in the same direction. While this might sound like an obvious thing, it’s actually really easy to lose that focus when you’re involved in problem solving for very tricky ground-level technical challenges for weeks on end. Lots of things got clarified on the design side and are reassured that our goals are aligned and the same processes needed to reach those goals.

On the Level Design side Andreas has taken over the Hurston landing zone. He will be focusing initially on the basic layout, positioning of important landmarks, vistas, landing pads and shops in the three layered zone. The Hurston landing zone is buried within the heavily industrial planet Hurston, owned by Hurston Dynamics in the Stanton system, but besides the actual Industrial Sector it also contains a Civilian Commons Sector and an extensive Business Sector.

The power distribution prototype that Clement was working on proved successful, so now he is moving forward to integrating life support systems and depressurization to this prototype. He is also extending the layout needed as more features get added to this test level.

On the System Design side we’ve been specing out some high priority systems needed for PU. We finished work on the Oxygen, Breathing & Stamina system that will handle the mechanics for how the oxygen travels from the suit’s tank to the suit’s internal capacity, through the lungs and into the blood stream and how the levels of oxygen in the player’s blood affect his actions, and also what happens when he runs out of oxygen.

We’ve also finalized designs on how Quantum Drives & Interdiction function and interact, and are also working on a global universe spawning system that will populate the star systems with content based on dynamic data from the Universe Simulator.

Another system that has been heavily looked at is loot generation and the actual looting system. We are trying to keep this as realistic & immersive as possible while trying to also have it still be manageable and entertaining for the player. This together with the work being done with Player Transactions should help us kickstart an early version of the economy in the PU.

On the AI design side, this month, we’ve started to receive tools that help us greatly in the process of building our behaviours and subsumption tasks so we have started working with these and hopefully our AI will greatly improve because of it.

=== Environment Art ===

This month environment art completed work on the (can’t say) which will feature in the (can’t say) of the game. They also started working on a wrecked version of the (can’t say) that will be used as set dressing in specific cinematic scenes. Making the wrecked version of the (can’t say) will involve taking the existing (can’t say) and adjusting the geometry and textures to simulate a smashed up and burnt look, while also using decals to really make it look like this thing has suffered some fairly intense damage.

They also continued supporting the Engine team on the procedural tech, further defining the pipeline and approach to get the finest level of detail possible.

{{#ev:youtube|https://youtu.be/sh4RzRhqldg}}

== BHVR ==

[[File:MonthlyReport-201602-BHVR-Header-Feb-2016.jpg|300px]]

'''Greetings Citizens,'''

From building the largest environments to growing the smallest space plants, Behaviour’s work ran the gamut this month!

=== Design ===

Behaviour’s Design team has been very busy this February. Starting with Hurston landing zone, we designed, blueprinted and whiteboxed all shop locations for the level, 10 in total and every designers chipped in. Good job guys! They are very different from what we did before as Hurston has its own visual signature and gameplay requirements. BHVR artists are going to start working on them soon and we can’t wait to see the result.

We are also helping out design, scope and plan for shopping which is a big priority for us. Regarding that, we made a few changes to the AR mode and AR labels, the more significant improvement will come with the shopping release but we got some very promising prototype on how this will look and feel. Even the March flair items will have AR information attached.

Talking about flair items, we gave a big push for flair hangar decoration this month, try to forge ahead. March will see the new flair collection revealed which will have 2 decorations: a subscriber one and even a stretch goal one. We even have a few more surprises in bank… To be continued.

=== Engineering ===

February has seen most of us working on polishing, debugging and optimizing various features for the 2.2.0 branch.

These include many fixes on contact list, hangar swapping loadouts, turret display in multi crew and holotable features.

Aside from that Adamo Maiorano has worked on Augmented Reality prototypes for the shopping experience and general AR changes to fit design changes.

=== Art ===

The Behaviour Art team has been finishing the available shops for Levski. Mostly polishing, dressing and creating props to give a distinct look and feel to each shop.

Also, we began work on performance optimisation to ensure a good frame rate for once NPC and players will be populating the level.

Lots of support was given to the 2.2 release, mostly fixing bugs and updating a few assets.

In addition, work continued on generic props for the lowtech style. These will be extremely useful for our many planets and SQ42 needs.

On the Concept art side, we began work on paintovers for the future Hurston shops.

Finally, the next flair objects has been completed for the next release.

{{#ev:youtube|https://youtu.be/WvlnG45Kois}}

== TURBULENT ==

[[File:MonthlyReport-1602-Turbulent-Header-Feb-2016.jpg|300px]]

Greetings from freezing-rainy Montreal! Here’s what we’ve been up to in the last month:

=== Ship Stats ===

With over 70 ships currently listed on the site, the “Ship Stats” page needs a redesign with revamped readability and usability. We have gone back to the drawing board, creating a new user interface with additional search filters, allowing you to quickly find and compare the ships that interest you, as well as give better insight into the ship production pipeline. We are currently in the design phase, so we’ll post a screenshot in an upcoming report.

=== Multi-Factor Authentication (MFA) ===

Last month, we continued our development of multi-factor authentication, i.e. best practices research, prototyping, and data modeling. Our objective is to upgrade our current authentication services and allow anyone to enable this added security feature. On the design front, we finalized the page layouts for the security settings section, which is where the user will setup MFA. In upcoming reports we’ll be able to go into more details about the foreseen short- and long-term options.

=== Communication Platform ===

We began brainstorming on a new communication platform for the site which would be able to aggregate and blend forum threads, chatrooms, private messaging into one hub. Our first step was to benchmark and rate other communication tools used by gamers and we are now starting the actual functional design process. Our aim is that this platform could be the next big functional step for Organizations.

=== Ship Happens ===

Last month, we updated the game packages on the website, so moving forward, Star Citizen and the upcoming Squadron 42 will be sold separately. It is important to note that his does not affect any packages that you already own; it applies only to packages sold after Feb 14.

=== Behind the Scenes ===

The Panic Service is live! Star Citizen devs are now able to access all crash data from this database, making it easier to extract the pertinent information.

Additionally we have been working with CIG to bring about the next big steps in persistence and how it will handle what everyone has on their website accounts. More on this as soon as we’re allowed to disclose anything!

{{#ev:youtube|https://youtu.be/9zZLfUxzGNo}}

== COMMUNITY ==

[[File:MonthlyReport-201602-Community-Header-Feb-2016.jpg|300px]]

[[File:MonthlyReport-201602-2.jpg|300px|right]]
[[File:MonthlyReport-201602-3.jpg|300px|right]]
[[File:MonthlyReport-201602-4.jpg|300px|right]]
[[File:MonthlyReport-201602-5.jpg|300px|right]]
[[File:MonthlyReport-201602-6.jpg|300px|right]]

Community… huh… yeah

What is it good for?

Absolutely everything, oh hoh, oh…

(YOU try starting one of these things…)

February went by in a blur like the short month that it is. Like always, it was a month of videos, forums, live events, perks, and more, so let’s dive right in.

=== Videos ===

The 10 For series reached another pinnacle when we had Sean Tracy and Steve Bender take over the show early this month. We knew it was going to be a spectacular trainwreck when we came up with the idea, and the boys didn’t disappoint. The variety of people it takes to make a game of this scope and quality continuously amazes me, and it delights me in equal measure when we can share those people with you, and show you that having fun in video games isn’t just for the people playing them.

Around the Verse continues to evolve with the inclusion of a more newcomer friendly hosting portion, remote video segments that allow us to showcase our developers around the world, and the return of fun segments like Which Glitch, and the Wonderful World of Star Citizen, where we showcase the community content creators on our flagship broadcast. In the coming weeks and months, you’ll see gamestreamers, youtubers, podcasters, ship builders and more highlighted on Around the Verse, as well as your gameplay videos front and center from now on in the opening of the show.

Reverse the Verse, our weekly informal livestream with the fans, is also evolving! Recent additions to the show include a new graphics and overlay package and a more structured format to the show. Response has been very positive so far, and keep watching as even more additions to the show come over the next few months.

=== Website ===

The RSI website continues to be the heart of Star Citizen-related conversation. Last month’s addition of the Shipyard section to the forums has taken off, small revisions to the Issue Council have helped us better track the bugs that affect your gameplay experience, and after a slight database issue that caused havoc with the upvote system in the Community Hub, that appears back on track. We’re hopeful to have continued iterations to both the Issue Council and Community Hub in the near future, and are even exploring options related to a major upgrade to our forums. No details to speak of just yet, but we continue to explore ways to improve all aspects of the Star Citizen experience during development… because that’s what development is for, yeah?

=== Live Events ===

No live events for the month of February, but we continue to make plans for our Gamescom and CitizenCon presence later this year. For Gamescom (Aug. 17-21) we’ll be on the show floor in our very own booth all five days, and are looking to host a number of pop-up parties in the evenings throughout the week, so stay tuned for more info on that as we get closer to the event. CitizenCon will be October 9th in Los Angeles at the Avalon Hollywood. The specific start time is still being determined, but we’ll have tickets up on the site for that in the coming weeks once all relevant details have been locked down.

=== Perks ===

Subscribers continue to get their monthly flair, and tune into Around the Verse next week to get a glimpse at a new flair series coming to subscribers that has us excited here.

=== Coda ===

That’s all we got for this month. We pretty much leave it all out on the field as they say in Sportsball. We’ll continue doing our best to generate and share as much Star Citizen content as we can with you each and every week. As always, a huge thanks to the 6 studios for taking the time to gather all this info for us to share with you.

See you in the ‘Verse!
Description	What you type	What you get
Italic	''Italic text''	Italic text
Bold	'''Bold text'''	Bold text
Bold & italic	'''''Bold & italic text'''''	*Bold & italic text*