February 6th 2016
2016 is here, and we’re ready to rock! We kicked off the month with a series of summits in the UK and Los Angeles to prepare for the new year. There’s still one more to go, an AI summit in Frankfurt happening next week, but we’re ready to take on 2016! Now that our i’s are dotted and our t’s crossed, we’re ready to continue getting some great content out to the community. Specifically: going forward, you can expect to see regular updates to the Star Citizen Alpha. We are shooting for one significant patch each month. Expect to see this cycle repeated: numerous PTU test patches followed by a live release and then a lull as content for the next patch is prepared and integrated. As I write this, the team is working on content for Alpha 2.2. Expect to hear more about this release very soon! Meanwhile, here are the specifics of what each Star Citizen studio was working on in January…
Now that we have taken our first step into 2016, we have already started the year off with a big splash. January marked the release of Star Citizen 2.1.0, a continued evolution of the ground-breaking 2.0.0 release from last year. Additional world missions were added to the universe; however, the biggest stand-out feature was the additional two flyable ships: the Aegis Vanguard Warden and the long awaited MISC Freelancer. If you watched any of our streams last year, you would have witnessed the unveiling of the AEGIS Sabre. With the 2.1.0 release, for those who purchased the Sabre during its debut last year will find this sleek and beautiful space superiority fighter sitting in their hangar!
Along with the regular gamut of balances, fixes, and updates, below is our monthly report for CIG LA.
January has been a busy month for the CIG LA Engineering team. The biggest milestone for all of the LA teams was the successful release of Star Citizen 2.1.0. Lead Engineer Paul Reindell has made solid progress on the item refactor collectively called Item System 2.0. Other regions are contributing to this new system and many preliminary features have been already released in order to provide a solid foundation for the Item System 2.0 and set the stage for its continued evolution. As mentioned in last month’s report, this feature provides greater control over itemization on the back end of the game. For January, Paul has implemented a physics controlling component that handles the physicalization of objects. This lives as a layer between the items and its physical proxy, interfacing how the physics mode of an object is changed (enabled, static, rigid, ragdoll, etc.).
Engineer Mark Abent has been industriously creating parameters for ammunition. With many of our systems moving away from strict XML and moving towards our own internal data management system, there’s a need to convert projectiles to this new management system. While outwardly, this will have no visible impact on the game itself, it changes how the parameters are loaded and allows us to move away from the XML project path.
Associate Engineer Chad Zamzow has been working on changes on how shields function. By making higher levels of shield health better at preventing damage, well-managed shields should provide a positive benefit over poorly/improperly managed shields – with the end goal of making lasers increasingly effective at depleting shields the more damage a shield takes and providing interesting decisions for players balancing regeneration speed, sheer strength, and signature in their shield generator options.
The new Interaction system has been worked on by our Engine Programmer Allen Chen, changing how interactions function. The current “Use” function in-game prevents us from adding more than one action to a single interactable object. Allen has completely decoupled the interaction logic to allow multiple actors to interact with a single object simultaneously.
“Ships galore!” should be the slogan for the CIG LA Tech Design team this month. With so many ships in the pipeline, it is difficult to decide where to start from.
One of the most anticipated ships so far, the 890 Jump, has just had its technical design documentation completed by Matt Sherman. Creating technical design documentation for the ship provides the artists with a template of specifications. Requisite information such as dimensions, hard points, internal volume, and various functionalities will ensure the artists are incorporating all of the necessary design elements.
Further development on the Xi’an Scout has reached the ‘grey box’ tech design phase. While the technical design documentation is akin to a “letter of intent” in that it is providing an idea of how the ship will function, the grey box stage is where the nitty gritty details of the ship begin to take shape. Lead Tech Designer Kirk Tome has given the Scout its overview such as its variants, characteristics – a comparison of various aspects of performance based on other ships of similar mass and design – and an idea of how the ergonomics of the cockpit will be laid out.
While Kirk continues with his design work on the Scout, he has also taken on the hefty task of refactoring the mass of every ship in-game. Definitely not a job for the faint at heart, Kirk has researched how to properly calculate the mass of our ships, and is now looking to apply these findings. With functional realism an end-goal of Star Citizen, we want to make sure all ships are using calculations ideal for the kind of materials our universe will contain. Whether they are far-future composite materials yet to be discovered or are composed of tried and true iron and steel, every one of these items will affect how ships move through the void.
Balance master Calix Reneau has also taken on a juggling task worthy of a traveling circus show. With our shield system being further iterated upon, Calix has created a metrics system to quantify shield performance. By allowing the Tech Design team to analyze these performance numbers, we can further fine tune how shields function not just as a whole, but also how they respond against various weapon types whether they are kinetic projectiles, energy-based attacks, or other exotic weapon types.
With the team beginning to fill out the shader libraries for MISC, it is no wonder the Reliant is shaping up to be one of our most stunning ships yet while also being one of our most collaborative multi studio efforts. Its unorthodox vertical shape has given our ship team a fresh canvas to exercise creative ideas for a creative design.
The MISC Reliant has been an all-hands-on-deck effort by the CIG LA Art team. Elwin Bachiller and Daniel Kamentsky have completed the exterior POMs and decals as well as generated almost all the geometry require to destroy it.
Concept artist Gurmukh Bhasin has been creating large renders to wallpaper our new building as we are still getting settled in to the new location. Each conference room will be given a different theme based on a ship manufacturer, and Gurmukh has been designing renders for how each room should look when the installations are completed. If you ever come by to take a tour of the place, make sure you check out our giant mural featuring the Vanguard. Given how much time we spend here, the investment in morale is well worth the effort!
Omar “Armani” Aweidah and Jeremiah “Versace” Lee, our in-game fashionistas, are creating uniform and clothing design for characters in-game. Creating an era-appropriate aesthetic for clothing while keeping certain elements familiar allows our players to identify and relate with the universe we have created. Not only do we want our ships to be the most epic spacecraft ever, we want to make sure our pilots, pirates, explorers, and ilk are geared appropriately for their chosen lot in the life of a Star Citizen. Jeremiah completed the medium armor concept, while Omar completed the high-poly geometry for the male navy BDU (Battle Dress Uniform).
Sean Tracy has migrated to the Los Angeles office, transplanting himself from Austin, Texas and has been making his mark with his Tech Content team.
Those who piloted or stood in proximity to a Constellation during the 2.1.0 PTU may have noticed drops in in-game performance. Matt Intrieri and Mark McCall have been fastidiously delving into the root cause of this performance issue. With 2.1.1, pilots of (and anyone standing in proximity to) a Constellation should notice a marked increase in game performance.
Further content refinements performed by Mr. McCall include adding LODs to normalize the mesh count for the Constellation as well as converting thrusters for all ships to .CDF format and add LODs to the thrusters.
Riggers Gaige Hallman and John Riggs (yes, we have a rigger named Riggs…how awesome is that?) have been working on putting processes in place. John has finalized the skinning vertices on characters while Gaige has been spending a little time each day performing some early Spring cleaning, organizing our character outsource submission management in Shotgun.
Finally, Patrick Salerno has also been proactively beautifying the Gladius by adding LODs to the Gladius to normalize the mesh count.
Senior Producer Eric Kieron Davis is truly a man of many talents. One week he is in Austin, TX assisting the production team with Persistent Universe processes then another week he is spearheading the beautification of the new Los Angeles CIG office, all while keeping his eyes on the target of 2.1.0 and 2.1.1.
Mark Hong has fully settled in, another transplant from our Austin, TX office, has taken control of the Art and Technical Content teams as their producer while Randy Vazquez has filled in the much-needed role of Engineering and Tech Design producer. Randy’s familiarity with the design processes gives him a unique perspective on how best to manage the tasks of the Tech Design team, especially since Randy has both production and design experience under his belt. Production Assistant Darian Vorlick now fills a support role for the CIG LA team by providing data analytics, logistical reporting, as well as relieving any extraneous loads that may fall on the shoulders of the other producers.
Our Head of Linear Content John Schimmel, Senior Writer Will Weisbaum and Lead Writer David Haddock were visiting the UK office for a few weeks to sync back up with the designers as well as discuss the production of Squadron 42. They were able to address all of the narrative items of the story and adjust based on new insights as the in-game tech advances. On the Persistent Universe front, as more landing zones are in the process of being built, they have been delving deeper into the look and feel of the locations, characters and even how in-game fictitious products are advertised and branded.
In addition to writing Jump Point articles and News Updates, Associate Writer Adam Wieser tackled a pretty massive S42 task: conforming the scripts to accurately reflect the dialogue recorded during last year’s performance shoot. A laborious process for sure, but now that it’s complete, the designers will no longer need to hunt down footage to see how scenes played out.
Archivist Cherie Heiberg continued to work with our science consultants who have been generating data based on the various planets and systems in the Star Citizen universe while waging her colossal battle against the monstrous hydra known as disorganization and confusion. Our internal wiki is their battlefield. It’s like Thunderdome. Two will enter. One will leave.
With the first 30 days of 2016 behind us, we still have another 335 left to go. That leaves us plenty of time for new ships, new features, new missions, and new art to make its way into the universe. February is looking to be just as exciting and we can’t wait until we can bring you a month in review next time. We are making video game history, and all of you are at the center of it!
The New Year is behind us and teams are in full swing planning, developing, testing, and launching new content for the game. We have had several team members in the LA studio this month for substantial in-person collaboration and planning efforts, and we’ve received a ton of new content for testing and publishing. After substantial testing we launched the 2.1.0 version to the Live server, and have made subsequent updates to tweak and tune the experience. We’re looking ahead to the 2.2.0 update which is soon to come! Here are some detailed updates from each group in Austin.
The keyword for this month has been ROADMAP. Lots of scheduling and planning has been going on this month for 2016, and we’ve made good progress in laying down a roadmap for features and content. Mark Skelton and Tony Zurovec have been in LA the last couple of weeks meeting with Chris Roberts, Erin Roberts, and others to ensure that all of our goals are lined up and clear to everyone.
That being said, roadmaps and schedules weren’t the only thing we worked on this month. We’ve identified the hero landing zones, smaller landing zones, and space content we want to bring online this year, but the ones that are currently in progress are tracking along nicely. The Levski landing zone in Nyx is in Final Art Stage, and we are now putting the finishing touches on the Shops we’ll have there, including Cordry’s (armor), Conscientious Objects (personal weapons), Café Musain (bar), and the Medical Unit. Initial VFX and Lighting passes are under way for those environments and they are looking absolutely beautimous in their own grimy, decrepit kinda way.
Looking forward, we’ve been putting some hard design focus on creating blueprint documentation for the next hero landing zone on the horizon, the Stanton>Hurston>Lorville landing zone (that’s the Lorville landing zone on planet Hurston in the Stanton system, for those of you who’ve been enjoying the Starmap). Rob Reininger has been working with BHVR to layout the blueprints for the various shops for Hurston, as well as the layout for the city of Lorville itself. We’re excited about the design opportunities that have presented themselves for this environment and are taking full advantage. We’ve also been doing some pre-visualization for Hurston. Mark Skelton has been going back and forth with BHVR over the art direction of this environment, and Corentin Chevanne, Art Director at BHVR, and his crew have been doing an excellent job nailing that aesthetic. We’re excited to jump on to this landing zone after we wrap up work on Levski.
In Ship Land, Chris Smith and Josh Coons have been chugging away on the Xi’an Scout (or Khartu-Al). Emre has been working with them to finish up his initial lighting pass on it and it is looking pretty slick. We’re aiming to finish up this ship in the very near future, at which point we will move on to our next focus, revamping the original 3 ships in Arena Commander (the Aurora, 300i, and Hornet) to match our current quality standards.
On the Ship Animation side, in conjunction with Art we’ve been working on enter and exit cockpit animations for the Scout in preparation for its hangar-ready release. These animations are completely unique, since this type of ship is the first of its kind that we’ve done. In addition we are implementing a new cockpit type control scheme for this ship: The Dual Orb. On the PU side, we’ve wrapped up work on the Medical Unit animations and have been making some nice progress on the Nightclub scene animations. We’ve got NPC’s leaning against walls, sitting at booths, drinking at bars, using vending machines, and even using the toilet!
As mentioned previously, Tony Zurovec has been in LA for the past couple of weeks meeting with the other Directors to discuss high-level Design goals for 2016. There are several exciting features that are being discussed that we will aim to bring online this year. I won’t mention them here just yet but look forward to updates on these features soon. Another part of the planning that Tony has been going over with Chris is the Backend Networking/Server roadmap for the year. Jason Ely and Jeff Zhu are fully focused on Persistence right now, and will be for a while longer, but there are several core backend systems that need to be developed this year in order to make significant leaps forward in the PU. For example, Tom Sawyer just finished wrapping up work on improvements to the Party System, and will now be writing a TDD for the work to be done on his next focus, the “True Friends System.” More on that next month!
After a well-deserved break, QA began January with focusing testing efforts on the deployment of 2.1.0 to the live environment. After five deployments to the PTU, we were very happy to finally deploy 2.1.0 to live.
This month we have gained 2 new recruits. Please welcome Jeff Daily and Katarzyna Mierostawska. Jeff comes to us from NCSoft where he worked on many titles as QA Lead. Katarzyna worked with many titles as well including Trion World’s Archeage where she obtained Cryengine testing experience.
Training new additions to the team is a significant undertaking but Tyler Witkin and Melissa Estrada are up to the task and doing a great job.
After deploying 2.1.0 to the live environment QA began testing the game-dev development branch which will eventually become 2.2.0. Todd Raffray headed up a comprehensive test of Party System updates and improvements.
Meanwhile, Vincent Sinatra and Andrew Hesse have completed additional investigations for designer Calix Reneau involving ship speeds, time to kill, and flight mechanics. Vincent and Andrew have also been supporting daily developer playtests in the LA studio which have resulted in very valuable feedback.
This month we had two visitors from our QA team from the Foundry 42 studio in Manchester Glenn Kneale and Andrew Mawdsley. Glenn and Andrew sat down with Jeffrey Pease and learned how to effectively monitor and report issues with our back end services.
Just prior to the month’s conclusion, we tested and deployed a small hotfix (2.1.2) to the PTU and then to the live environment. We are now squarely focused on testing new additions and updates in the game-dev branch which will become 2.2.0. The entire QA team is doing some really great work and we are all looking forward to getting 2.2.0 out to everyone as soon as possible.
January saw the rollout of 2.1.0 (and subsequently, 2.1.1 and 2.1.2) to our players. Chris Danks and Will Leverett in Game Support worked alongside Production, QA, and Live Ops to feverishly put out daily builds to get tested, assessed, fixed, and finally pushed to Live. We’re excited to see the reception it’s received, and we’ll continue to make additional fixes on the road to 2.2.0 next month.
Game Support also has been focused on the general work of catching up from the holidays. Most of this work is complete, and we’re happy to provide faster turnarounds for players who send in technical-related tickets.
On a related note, we’ve also been pushing hard to get caught up on our hacked accounts. We feel this is a good time to remind players that we do not condone buying and selling of pledges using the gifting system, in fact we actively discourage it. This is one area where we cannot promise and you should not expect that we can or must address a given ticket. The gifting mechanism is not intended for this use, and not only can CIG not monitor a third party transaction, you are exposing yourself to a risk where you may not be able to recover your funds if the other party has malicious intent.
Lastly, we’ve been working with company leadership to discuss our plans for growth in 2016. We’re excited about growing our team both in Manchester, UK and in Austin, Texas, and we’ll be looking for some top talent to help us run the BDSSE in the next few months. Stay tuned!
January has been fun for us all here on the IT team. First and most importantly, nothing broke down! We all feel quite a sense of relief over the stability of our networks now with all the work that has been done at each studio to accommodate the large bursts of data for the builds and publishes. Normally, a network of this size and complexity requires constant tuning and maintaining, particularly with all the requirements and overhead involved with secure communications between studios. This year over our holiday however, the IT team didn’t even receive a single alert which is how it should be of course, but this is the first year for us that we’ve experienced such a smooth holiday vacation.
This month went by very quickly but toward the end, we got to meet up with some really great groups of backers. It was fun to spend time chatting with them about some of the details about how the build system works and the cool systems we made which allow us to replicate petabytes of data between the studios. To those of you who were here, thanks for coming and we’re looking forward to your next visit.
Kicking off the first month of 2016 has been very productive in the LiveOps team. We published version 2.1 to the live service 3 times in January with 9 publishes to the PTU. We’ve also reconfigured our desks to make room for more growth on the team and just because it feels good to clean everything at the beginning of the year.
Major progress has been made on tools that support the build process. This month has seen the most impressive updates in the form of interface and usability. These important changes will allow us to push more control out to the dev teams so they don’t have to request every single change from us directly. Additionally, we’ve nearly completed our work on the public crash handler which should be incorporated in to the game in February if all goes well. We expect this will produce a wealth of information for the dev team with regards to any client crashes – this information will help them hunt down and fix those client crash bugs once and for all. Finally, we’re also finishing our work on a new type of build which we hope will have an impact on client load times. If we do well in testing, we’re hoping to get these new builds in to the pipeline in February as well.
Let’s get right to it! Here’s what we’ve been doing at Foundry 42 in the new year:
A relatively slow month of production due to Christmas holidays eating into a good portion of the month, however true to form and CIG style we hit the ground running with 2 weeks of planning meetings for the hurdles we face this year.
One aspect of the planning was trying to give the concept team a smoother ride; in the past we’ve had to adopt a fairly reactive flow, whereas this year I’d like to know 3-6 months in advance – we have the work that’s for sure!
This month the team has covered finishing off the Javelin exterior, Idris/Javelin turrets, Shubin corridor and main bridge, low tech props, asteroid outpost garage interior and Apocalypse Arms rail gun (first pass).
The pressure is on! Forrest has been visiting and giving the guys a good understanding of the new pipeline and has done a stellar job on working with associate producer Andy to get a comprehensive schedule together. In terms of art work, “Randall Graves” is now close to in-game final and the Bridge Officers uniform high poly is looking top notch too.
Most of January has been picking up the whiteboxing phase for the environments in Sq42, we’re making all the big changes to the layout, composition, vistas and flow in this period as everything is very malleable. It’s really promising seeing how all our big set piece events will play out, and how the player will traverse through the various locations in the game. Our PU team has also started whiteboxing out a new location for Crusader which will feature a familiar character. This is going to be a cool one and we’re going to take it into full production next month. Work is also progressing on our testbed for asteroid bases, the look development for the terrain is now complete and now we’re applying this to the rest of the landscape.
There’s plenty of spaceship action going on at Foundry 42! We’re getting in to the final art stages of production with the Sabre and StarFarer. The StarFarer is rather large with lots of interior work so she’s going to take a little longer but we hope to have the Sabre flying around Crusader very soon.
It’s exciting times in the land of Capital Ships. We’ve got resources back on to the Idris to get her ship shape with the Javelin and Bengal getting their whitebox work well underway. We can’t wait to get these babies flying!
We certainly hit the ground running after the Christmas break! Adam has been focusing on some “thruster standardisation” tasks. There are a number of inconsistencies that we want to smooth out across all thrusters in the game; one example would be some thruster effects having no idle effect , where others do (when the ship is “on” but not thrusting) – we are going to make sure all idle thrusters have a glow to show the thing is powered up. Another part of this task is the creation of boost effects, so there is clear visual feedback to show the difference between boost and standard thrust. This wasn’t previously possible, so Adam has been working closely with John Pritchett to give us improved functionality to really enhance our thruster effects.
Away from thrusters, Mike has been working on a cleaned-up, simplified VFX style guide. This is a concise document that clearly lays out the expected visual style for our VFX artists to adhere to, ensuring visual consistency across the whole range of effects we make (and let’s face it, we make a LOT of effects here!) – it also gives us a very clear visual language for different manufacturers and races. Mike has also been working on cleaning up the effects “templates” and building up our libraries so designers and artists have a greater range of effects to choose from when fleshing out their levels, weapons etc.
Collectively, the VFX team have begun looking in earnest at the effects requirements for Squadron 42 – no spoilers here but suffice to say we have some spectacular scenarios throughout the campaign. I can tell you there will be explosions. Lots of explosions. Did I mention there are going to be explosions?
The Props team has been continuing to focus on the ship components, we are just putting the finishing touches on the third. We have however had a slight change of heart with how we approach the materials. After consulting the Character and Weapon teams we are now looking to use the same layer material they use, this allows us to achieve a much higher quality surface on the components and it has the added benefit of being much cheaper rendering wise. We will need to revisit our original components but the work is fairly quick and the benefits are well worth it.
We also hope to make use of this layer material in other areas of prop production which will ultimately mean we can throw more on screen than before, a bit of investigation work is in order next month.
With the prop audit coming to a close we have started to do a polish pass on some of the older and commonly used assets, with the aim of improving the quality and performance in one hit.
Work had begun on supporting the Squadron levels and we are working closely with the environment team building some of the key props they require.
Finally work has commenced on the next set of flair assets for our subscribers hangars, we are planning something a bit different in the next couple of months so we are trying to get a head start now.
Wow! January went past at 100 miles-an-hour and the UK design team have been busy in all areas of the game. Systems design is still refactoring the UI for the HUD to give new players a less steep learning curve into the game. It’s not just the HUD that needs an easy option as we are also looking at all of the usability aspects of the game in relation to new players, such as USE prompts, inner-thought, controls unification, better on-foot navigation aids and augmented reality.
As part of this process we are giving mobiGlas some much needed design love, doing a full sanity pass through all of the apps we will need, the priorities being the ones required for the military version for Squadron 42 and the shopping experience.
With the StarFarer coming out soon, we are looking to get the fuel collection gameplay tiered up so Players will have some interesting things to do with this beast of a ship in the coming Live releases.
The Tech designers are still bashing away on all of the new ships and having some extra bodies in that department is starting to pay off in terms of getting the ships flight ready sooner.
From this month we are going to have a dedicated Ship Balance Designer who can act upon feedback in terms of where ships fit in the overall game. This is going to be a very important role going forward and will require a lot of trial and error before the ships feel how they are supposed to, but it’s great that someone is now going to be responsible for this on a daily basis.
I can’t say too much about S42 as you know, but we had Chris Roberts and the writing team over here for the first two weeks of January and we are very happy with how the campaign is paced for design now.
Some good progress has been made on some of the core systems this month which will all go and help make the game easier to maintain as well as fix some of those annoying little bugs that crop up from time to time.
The hardest part of the job sometimes is just knowing what to call something. For example, in the current version of a game when vehicles get created, either when you or somebody else requests a ship, or when AI spawn in, it’s actually quite an inefficient process on the networking side. The client first comes up with a list of what the required loadout is and sends it to the server, the server then creates the ship with all the individual items (which can be over 100 depending on the ship), the server then serializes all these items to all the clients (a fancy way of saying it makes sure they both are synchronised with the same information) one at a time. This has led to a lot of pain in past to get all of this working, as the CryEngine wasn’t designed to dynamically create vehicles like this, and it ended up with a lot of hard to track down bugs. A number of these were caused because the ship on the client could be built in a different order than on the server depending on what order the packets came through. We’re now doing away with all of that and coming up with a solution where we just have one packet of information which describes the whole vehicle and how it is set up. This packet is sent to the clients in one go and used by both the server and the client to build the ship. Now we have the advantage that there’s a lot less network traffic required, and because the server and all clients build the vehicle in exactly the same way it is completely deterministic which means it’s a lot more robust and easier to track down any problems. We were going to call this new packet a Spawn Bundle, but that that got confused with the AISpawnBundle we already have, we then started calling it Dependent Entity Spawn Helper, which doesn’t exactly trip off the tongue, so now we’re using the Loadout Helper, which we’re not really happy with either. So it’ll probably change again. (If you don’t think this is a big deal, consider that the name of a module or subroutine may be employed across multiple files across millions of lines of code across different code development branches being used by different teams that need merging before a release. And yet, a reliable and ordered naming convention is extremely important for internal consistency because if the names don’t make intuitive or engineering sense, it’s harder and slower for newcomers to get up to snuff on a system that’s become too idiosyncratic.)
The Object Container work (which similarly had gone through numerous renames) is making some good progress. We’ve now got proof of principle where we can export a level as an object container and get it to load into the game correctly. Now we begin the fun part of trying to split the level up into multiple containers and getting them to stream in and out of memory, which is where we start to break everything. We’ll also be working on converting the prefabs over and getting the containers working with the Zone System. Once all of that is in it will allow us to greatly expand the scope of a level.
Otherwise it’s pretty much carrying on as usual. The audio guys are currently trying to track down a really nasty audio corruption bug which you might have heard. It’s proving really tricky as it’s very hard to reproduce, our QA only hear it after playing the game for around 4 hours in a session with a full server so we might only get it once or twice a day. It ends up that the turnaround time between creating a new build with some additional debugging, or potential fixes, and seeing what happens becomes very drawn out. We have started to narrow down what is going on though and we’re confident we can get it fixed shortly.
Last month a lot of our focus was on improving performance and we’ve managed to make significant improvements on existing scenes/ships but also on our newer and more complex assets that are still in production. Some of our recent big wins have come from fixing various issues on the Constellations and Retaliators room setup to ensure they’re properly occluded from outside the ship, and to heavily optimise the UI of both ships (we now render less than ¼ of the number of meshes for the holo-UI for the exact same visual result).
This month the leads have been planning the long term schedule for the year, and the graphics team have had to determine the graphics requirements of all the other teams (art, vfx, design, gameplay) and ensure we’ve planned out all the required features. While doing this the rest of the graphics team have been focussing on newer features, starting with our revival of the gas cloud tech that will be vital for both Squadron 42 and the PU. The gas cloud tech will continue to be one of our main priorities for the next couple of months, and at the moment we’re focussing on researching efficient volumetric lighting techniques and trying to get the look and feel right before getting into the optimisations and polish stages further down the line. Other new features we’re starting on are improvements to some of the shaders such as glass and skin, a new version of our LOD merging tool to optimise space stations and FPS environments, improved fire/glow on particle effects, and a completely new physically based glare & lens-flare system.
Here in the UK we have been working on core FPS player mechanics. We’ve been setting up some of the aim pose requirements for technical implementation of cover low and cover high systems. We’ve also been reworking the no weapon locomotion turns to add in some weight to the animation in 3rd person while keeping the camera steady in first person. An interesting challenge in itself when gameplay requires turning on the spot!
Further adjustments to core gameplay requirements have been lowering the crouch locomotion set to better fit the height metric set by design. This will allow idle and locomotion to keep below cover height, instead of your head popping up when you start to move. We’ve also started to look in to implementation of the vault and mantling mechanics, reviewing the motion capture data and working with design and code on the best way to break it up to allow for a smooth gameplay experience.
Other than that we’ve been planning for the year ahead, and providing some body data for cinematics over in Frankfurt to unblock them.
Here in CIG Audio, we’ve spent a lot of time tracking down an issue that’s affected the sound experience in the live release; wholesale and rather nasty distortion, that typically happens only after a reasonably lengthy play session.
It’s been difficult to discern the cause up until this week, but we think we have a solution and we’re rolling that out as soon as we can. We’ve had help from the community in tracking this one down, and have to thank all involved who went above and beyond the call of duty in sending us their data files and reporting the issue in such detail – it’s awesome to work hand in hand with you all. We’ve also had some great assistance from Audiokinetic’s support department who’ve pitched in wherever they can. It’s been a trying time for Graham, Sam and Mikhail in doing the necessary detective work and our QA team have also been of great assistance here. We’ll write up a more detailed report of it for those interested later once we have a fuller picture.
As you can imagine, this has curtailed some of our progress on the system side and has highlighted just how much we need audio programming engineers; as well as this issue bringing this to the fore, we’ve put together our entire audio engineering roadmap to feed into the wider code schedule and it includes much of what is discussed on the Ask A Dev forum and far more besides – there are a lot of foundations still to put down to cater for a universe as huge as ours, lots of variables to cater for and you can never quite know what they might be until the game hits the live servers.
So on the topic, we have a role available here at Foundry 42 for a Senior Audio Programmer, and one can apply via the CIG website!
Otherwise, work has continued where possible on Squadron 42, with Ross putting down as much as he can there, setting some markers for how that workflow should be, and continuing on the music logic system with Sam. Ship work is continually ongoing via Darren and Luke. Stefan’s been refining the impacts of ship-based weapons – he’s looking at making them more dangerous when you’re in EVA or generally unshielded by a ship. Matteo’s continued with Foley work for characters, Phil has been putting together one of the most awesome rigs ever for p-cap dialogue capture purposes, Bob’s been hard at it speccing up our dialogue system/database. Jason’s been assisting with that and looking to proximity based VOIP tech. I’ve been arranging as much as I can for a forthcoming orchestral performance session, and also working with everyone on a bit of everything.
Hopefully with this nasty bug out the way we can get back to more gainful work in building up the systems and content. Thanks for listening!
UK QA have been split between the testing of Star Citizen Future and Present this month – with us covering the current release streams of 2.1.0 (via 2.1.1 and 2.1.2) as well as the more developmental stream where the new upcoming features work is being done. At the time of writing this, 2.1.2 is about to go LIVE – so we’re all feeling happy in the knowledge that it’s been a good months’ work well done!
In terms of our biggest, most difficult to catch bug this month; we’ve been devoting a lot of time to the reproduction of the audio corruption and subsequent crash that’s been happening in 2.1.0 and 2.1.1. This has been some quite involved work for the UK test team – which has required frequent communication with the audio programmers as well as needing us to be sat in the PTU and LIVE servers, trying to force the issue to occur – with the help of many a backer. So thanks again!
This is also Andy Nicholson’s last month working as the QA Manager in the UK – Phil Webster will be taking his place in the coming week. Andy’s SC journey will continue, albeit in a new form with the Design team – but as QA Manager he leaves a legacy of creating a really great QA team.
And now it’s time to sign off. SPACESHIPLAUNCHSFXNOISES!
Hello from Frankfurt! Our main focus for January has been to re-iterate on the goals set throughout December and ensure we are still on track with them. For that we had a few meetings to discuss priorities so everyone was on the same page what to work on next. We slowly ramped-up on the focus so everyone could get back into their zone and work without interruption as much as possible. FPS, PU design, Cinematics, AI and core engine development progress so far within the first few weeks of 2016 has been quite impressive and you can find more details in the respective reports from our team.
The production team started the month with a lot of planning sessions. Having ended the year with our massive 2.0.0 update, introducing some key features of our game, we want to ensure that 2016 will be aequally as exciting for everyone. We met with the Directors and the team to talk about what high level goals we want to achieve, and when they’ll be completed, throughout 2016. We then prioritized and matched the tasks against our available resources. Talks with the team are still going on to break the goals down into achievable steps. Going through this process is taking a lot of time and since we also have to continue working on the updates/bug fixes for the live game it’s something that needs to be scheduled carefully to allow the team to prepare properly while keeping interruption on their current work as low as possible. On the AI side we are almost completed and will have a first draft roadmap ready within the next few days. This will cover all requirements for S42 but also PU and we have a lot of really interesting features and systems ready to be worked on. Follow-up discussions will happen with other departments of the team where dependencies need to be clarified. FPS, PU design and core engine development are on a good way, but all need prioritization and breaking the work down further before we can pull together a final plan.
Hi everyone, a new year starts with new technological challenges. We released 2.0 in December and 2.1 in January, each accompanied by a PTU phase before they went live. Star Citizen nowadays has a size of ~30GB, which means that with the current patch model, the backers have to download a load of data (Especially on the PTU where we want as many people as possible to make the game stable prior to going live). The size is the same internally for us, as even a 1GBit LAN connection cannot transfer 30 GB instantly. Hence we in Frankfurt collaborated with our Austin engineers on how to tackle this problem. We came up with a good solution in which we all believe in and have started to implement. The idea is to design a system which knows your local data, knows what data should be in the build, and then selectively downloads and updates your local data set to match the one of the build. For example, if between two PTU release, zero textures are changed, then no texture will be downloaded, reducing the required download by several GB. We hope to start testing this system soon internally and then extend it to our public releases as well. Unfortunately, as this is part an integration process which often tend to have many small issues which add up to a lot of time, I can only give you Soon™ as an estimate.
EVA was also a major focus! For extra vehicular activities (EVA) the player model is basically a ragdoll which is 100% controlled by physical impulses. This type of “ragdoll” can be driven by animation and is able to perform all actions needed for a player character. All physics-based control models can be unpredictable in certain situations: for example, whenever legs collide with an obstacle the character is doing somersaults and sliding along walls always makes the view spin around. This behavior is physically correct and pretty much identical to what happens when parts of a ship collide with an obstacles in space. But if this happens in first person view, then it’s not exactly what a player expects. In the last weeks we investigated (with the help of UK and LA) different control methods for the EVA suit that preserves the physicality of the ragdoll simulation and while still giving the player more precise controls for navigation and EVA combat. This includes:
Finally, we continued working on the procedural planet environment and trying different combinations to improve the planets overall appearances. We’re making great progress and look forward to showing things off in the future.
Since AI didn’t provide a large update for December due to the holiday, we’ll focus on the general progress we made since last month.
On the character side we completed the first pass on the implementation of the functionalities required to allow enemies to use covers during their combat behaviors. Animators have provided us animations for staying in cover, shooting from cover, peeking from cover, and firing blindly at their target. The behaviors can now correctly request functionalities such as peeking or shooting from cover. The system will take care of analysing the current position in relation of the target position selecting the proper posture to use.
We also started to refactor the character perception. We’re basically creating a perception system that can be modularized directly in the game code. Components will register the different entities into the system that will allow them to perceive through different senses. Vision has been the first to be tackled, we started using the CryEngine VisionMap and we created a game component that registers an entity as an Observer or Observable. This allow us to specify what we’re interested in seeing, and how other characters can perceive us so the vision map can take care of making physical checks and caching information for queries. We will share more details about this in the upcoming weeks!
On the behavior side we have exposed a lot of functionalities through new behavior nodes and extended the current behavior we’re using. We also started using the TokenSystem we previously talked about to create the foundation for the first coordination. With the TokenSystem we’re experimenting with coordinating agents during the investigation of dangerous sounds, having one person going to investigate while the other covers him and wait for his information, etc.
Regarding the spaceships AI, we have moved all the spawning logic from LUA to C++. This will allow us to maintain the system better and it already helped us by properly supporting the asynchronous entity spawning.
In addition to all of that we have been working on a lot of stability improvements and we have worked on the creation of a development plan for 2016 and beyond!
Our Senior Build Engineer has been busy in general working on the build system, trybuild and automation. This month a good amount of time was spent on general build issues that generally come up throughout development. He also worked on a few changes that will allow us to switch over to updated software once it’s released.
This month Chris Speak has been progressing on Automated testing setups for CryEngine, primarily focused on AI and the way it handles obstacles within a level as well as the Usables such as vaulting over walls and climbing ladders using a relatively simple Flowgraph module. He setup a test-map that contains several feature tests that can be triggered via the console within both the Editor as well as in Client mode that tells an AI character to move towards a specific target location, and upon entering that location the FeatureTest node in Flowgraph marks the test as complete. The AI has to determine how to navigate to that target area using the obstacles in front of it, so in the case of the screenshot below it needs to climb two 4 meter ladders to reach the target.
He’s also been recording timed demos for the purposes of automating end-user-experience testing to give us daily feedback relating to everything from ship boarding and flight, to FPS combat etc. This should give us a good foundation for future changes, and make changes to the game-code a bit less risky and painful.
Cinematics is currently at work on several scenes that happen during S42’s story’s beginning. We’ve done a first pass on our Navy hospital scenes and are currently doing previs on a few others that we can’t discuss just yet. Our Sr. Environment artists are busy building up terrain, as well as environment and key props for a dramatic planetside scene. The scene is fairly prominent and we need to make room for an Idris to land. We also started with a major facelift, as well as under-the-hood work, on the Trackview editor, one of the main tools use by the cinematic designers. Sascha Hoba is currently busy bringing the toolset up to speed for what we need it to do, both in usability and feature set. The additional functionality will make certain areas more efficient for the team, and allow us to assemble scenes quicker.
For Level Design work continues on the prototypes for the Modular Environments and the Power Management Systems, we are pretty close to having the latter ready for an internal play test to verify the concept. It should turn out to be a pretty interesting, a dynamic and fun way for the players to interact with the environments in everything from Space Stations to planetary outposts, just make sure you don’t turn off the lights while someone is still in the SpaceLoo™, bad things might happen.
As with development life in general we sometimes encounter bugs and blockers that might temporarily halt our work in one area, but there is always work to be done fill those small gaps, so in the last month we have also been doing some work on a small multiplayer map, defining game rules for multiplayer (line of sights, density of obstacles, height variations, scale) as well as scheduling and planning for 2016.
This last month System Design has been focused on getting a thorough breakdown of all the systems that we need for Star Citizen, past, present and future. This would allow us to verify and better see what systems are used the most and in which specific situations so we can better prioritise them.
Besides that we’ve been working on various cargo prototypes to decide what is the perfect balance between doing things as realistically as possible while making sure cargo movement and management is still fun and exciting to do. Other systems that we are pushing for right now are looting and resource spawn management as these will allow us to improve the PU experience greatly. We’ve also had a new addition to our team, Grégoire, a great designer from France, he’s been trying to catch up with the massive amount of documentation so that next month he is 100% up to date, while at the same time trying to get familiar with all the internal tools we use on a daily basis.
On top of all this we are continuing to interview great applicants and talent to fill the ranks of the expanding Frankfurt Design team.
We have been working with the concept art team on a new FPS weapon, it’s going well and looks good, but It is still in a very early concept stage.
Also the updated metrics for ship mounted and personal weapons have been completed after being evaluated by various departments and are ready to be used.
This month Mikhail spent most of the time on bug fixes and refactoring AudioSystem so that it uses the ZoneSystem for all relevant positional information. It turned out to be a fair bit of work, because, like most currently existing audio systems, CrySoundSystem was designed under an implicit assumption that audio sources are mostly static, and the ones that aren’t inform the audio system explicitly when their positions change. This works well for the majority of 3D-engine-based games in existence. Naturally, like with many other things, Star Citizen is a different case. Since a lot of action in the game happens inside the spaceships, there is no reason to expect the audio sources in any particular frame to be static, in fact, more often than not they are all moving, and, sometimes, for example when landing on a capital ship, there might be several clusters of audio sources all moving at different speeds relative to the listener. This not only applies to the permanent audio sources like thrusters, ship weapons, doors etc., but also the transient ones, like footsteps, object collisions, electrical sparks. As you can imagine, when the standard approach is used, the number of position updates required quickly adds up and starts to affect the overall performance. On the other hand, the Zone System provides the engine modules with a centralized and efficient way to keep track of the positional information for the objects they need, so querying it once per frame for the positions of all audible sources based on the current listener’s position is definitely a much more scalable solution.
This month Robert Stephens has been concentrating on the escape pod used in the Javelin Destroyer. Even though it’s only a small / minor craft in comparison to some of the larger ships, we’re spending the time we need to give it the level of detail fans and backers have come to expect. A good amount of time was spent on how the pod doors will open / close, we want to have both a complex and accurately stylize locking mechanism that the player can easily use and recognize. Some of the challenges with something like this is making it look as though it would work if it existed in real life, and also balancing that with the requirements of other departments such as animation so that the character can actually get in and out of the pod easily.
Pascal Muller has been working on art for the procedural planet tech. This involves a lot of iterating and figuring out what works on a technical level as well as getting it to look as good as possible. The main difficulty is to make it read visually no matter how far or how close you are to the planet. To make this work there are multiple levels of detail which blend in and out depending on your distance to the surface in a very particular way. Can’t say much more about it at this point except that we can’t wait to share it with everyone.
As part of our character pipeline, this month we divided or character data files into three separate units, _SRC, _PUB, and _BND files. The SRC file stores the render mesh and skeleton data, PUB stores the puppet rig, and _BND file helps us to map our FBX animation data to our puppet file. Currently we’re smoothing out the pipeline and developing tools to communicate with different files and systems with metadata nodes. We also provided some Tech support for EVA animation as well as some rigging for a weapon prototype.
For the past few weeks VFX in Frankfurt has been prototyping the visual looks and styles of some of the Xi’an tech. This tech differs visually from the other races and In order to get this visual look it required us to integrate some new tools into our texture creation workflow.
2016 is off to a great start! We began this month with great excitement for what’s coming next. Here’s what BHVR worked on in January:
January was very successful for the Behaviour Design team. Francois Boucher and Jesse Kalb went full steam ahead on the blueprints and the whiteboxes of Hurston shops. Working with our friends at ATX, we quickly iterated on Hurston locations and are about ready to hand most of the whiteboxes to the Art team.
We also updated our shopping prototype and put it in situation in both Casaba Outlet and in Nyx/Levski bazaar market, proving the concept even more, highlighting our future needs but also its current flaws.
Lead Designer Guillaume Bourque is working with a bunch of team members, both in Montreal and in other studios, setting the next collection of flair items on the right track. All I can say is it’s going to be real nice. We are also looking forward the next location we are going to work on, possibly a space station.
Lastly, we are helping setting up the Bar Citizen Montreal event which is going to take place early February here in Montreal.
This month, well rested from our holydays, we began R&D for a brand new planet. The work consisted mostly on creating a distinct feel and ambience to make sure that all our planets don’t look alike. Furthermore, working on a new planet is a great opportunity to apply the latest techniques that we’ve learned from the previous planets. Hopefully with this in mind, we can improve even more the visual quality of our new assets.
On the building sets, we moved to the polishing phase of the industrial/mining set. Also, we continued work on the different shops that we will be able to explore in Levski.
There was also a lot of work done on industrial props and on the next month flair objects.
This new year, there was a lot of work done on different game features. Simon Jambu worked on the Party System, to help you pick up the right instance to play with all your friends.
John Corbett, has been continuously at work on the datastore system, to allow temporary modifications on ships. This will be handled through a holotable on Port Olisar
Martin Poirier is working with other studios on in ships’ display screen optimization: reducing the memory and CPU footprints of ship UI (especially multicrew ships) as well as making the system ship component driven.
Adamo Maiorano and Fabien Poupineau are going full speed ahead on shopping experience. Going through different prototypes to make sure you have the best experience.
Greetings from Montreal! Here’s what we’ve been up to in the last month:
Last month, we launched the new Organization invitation template. We refreshed the look-and-feel so that it gives more prominence to the Organization’s own branding, and also added color schemes to match the type of Organization. You can find this feature under My Account > Organizations, in the left menu.
We wrapped up the QA phase for the upcoming Subscription campaign and will be launching in the beginning of February. Subscribers are a key part of the Star Citizen community, as they support the production of “10 for the Chairman,” “Around the ‘Verse,” “Bugsmashers,” “Meet the Devs,” and more. In addition to re-designing the Subscription section of the website, we produced some logos and animations that can be used in videos. We’ve also added new exclusive rewards (for Centurions and Imperators) in an easy-to-read matrix. If you haven’t already done so, now’s the best time to become a Subscriber!
This was an exciting month for ship production, as three ships were brought into the game. With the release of 2.1, the Sabre became hangar-ready, giving players their first in-game look at this agile fighter. As for flight-ready ships released in 2.1, we had the Freelancer base as well as the Vanguard Warden. During the release of 2.1, a sale was launched alongside it featuring the Sabre, Warden and an Aegis Fighter Pack featuring both the Sabre and its big brother, the Vanguard Warden. The following week also saw the sale of the alien ship, Xi’An Khartu Al, to coincide with Gillian Anderson’s interview on Squadron 42. To close out the month, there was a Free-fly to coincide with the weekend of PAX South.
We have begun development on the core mechanism for multi-factor authentication, which will greatly reduce the number of hacked accounts. In addition, we’re updating our design layouts to match the current look-and-feel of the website. Once MFA is in place, you will need a second authentication factor besides your username and password in order to access the game. You will decide how you receive this second factor (by email, SMS or a third-party app such as Google Authenticator). We are still in the early stages, so keep checking back for more updates!
We began discussions with the Star Citizen dev team to decide on the best way to integrate the Starmap into the game. A lot of factors have to be considered, such as visual integrity, performance, code maintenance, star system updates (synching), and what technologies should be used for the in-game version. Each month, we will provide more details on the process. In the meantime, you can check out our web version at: https://robertsspaceindustries.com/starmap
What happens when the game crashes? Well, we have been working with the Star Citizen dev team to build something we call the Panic Service. The Panic Service is responsible for receiving game client crash data and cataloging them in a centralized database where they can be accessed by the devs. Game crash data is sent to us via the “Receiver”, which is then processed by the “Worker” and stored in a database. From now on, Star Citizen devs will be able to access all crash data from this database, making it easier to extract the pertinent information. This will save time in troubleshooting.
For those of you who live in or near Montreal, we hope to meet you at Bar Citizen Montreal! All the details can be found on their Facebook page.
The start of 2016 has been a fantastic one. Right out of the gate, the response from you guys to Star Citizen Alpha 2.0 and 2.1 has been tremendous, and it always makes our jobs just a little more enjoyable when we see all of you enjoying your Star Citizen experience.
The 10 For series that airs every Monday made another evolution when we started incorporating hosts from different disciplines. With the addition of 10 for the Developers, we can answer questions provided by our development subscribers with more than one perspective. This has been providing us with what we feel are answers that are both more informative, and hopefully more interesting as well.
Around the Verse continues expanding to include coverage of other studios like Austin and Manchester, while addressing the production challenges inherent in trying to coordinate, produce, and direct segments through Skype and email. We’re hopeful to have a chance to visit our European studios in person this year and delve even deeper into the amazing work being done on the other side of the world.
To facilitate the production of these segments, we constructed three free-standing sets to improve overall production value. While only one of them is currently decorated, we have plans to bring the other two online in the coming weeks to months. This in conjunction with upgrades to the audio and lighting equipment, we’re slowly working to make our weekly productions all that we want them to be.
January also saw the release of two videos detailing Gillian Anderson’s work on the upcoming Squadron 42. Gillian is an exciting addition to the cast and we look forward to sharing more behind the scenes looks with other members of the cast in the future.
We recently added the Shipyard sub-section of the forums: an area dedicated specifically to the discussion of your favorite ships in Star Citizen. This change, like any change, often takes time to get used to, but the developers have taken to the dedicated nature of the feedback they’re looking for, and information is flowing from Citizens to Designers more easily than ever, so we definitely feel this is a huge win for everyone involved.
While we didn’t have an official presence at any conventions this month, we were able to send a single infiltrator to PAX South to meet with fans and shake his head at the litany of “when” questions that assaulted him. Our intrepid Community Manager even managed to unexpectedly find himself on a panel with the Community Manager for Elite: Dangerous, much to the delight of fans in attendance.
We launched our new Subscriptions landing page this month that you can find here. It’s a brief look at all the things becoming a development subscriber gets you. This month’s Subscriber flair was the AV8 Battle Armor Replica from the Puglisi Collection, and looking at the numbers appears to be a big hit with you guys. We’re constantly looking for ways to improve our Subscriber flair, so if you have a fantastic idea, please share it with us in the Subscriber forums.
We’ll keep it short and sweet this month, as by the time you’ve gotten to this section your eyeballs may be ready to burst. As always, we want to thank the other studios and departments for taking the time to gather all this info for us, as we appreciate it just as much as I’m certain you all do.
See you in the ‘Verse!
SettingsOne column Two columns Oldest first Newest first Most appreciated first