Greetings Citizens,

Summer is here (in the northern hemisphere, anyway) but we aren’t on vacation: big things are happening at CIG! Watching from the inside, it’s gratifying to see the moving parts that will form Star Citizen starting to come together. Important pieces of long-talked-about technology, like large world maps, are coming online internally and there’s an air of excitement among the development teams as the reality that a lot of what we’ve been planning for and working towards is finally happening sets in. We’re eager to share our progress with you, which means a push to get not just the Star Marine FPS module out, but to start sharing more about multicrew and the persistent world. Watch this space! As always, we’ve asked our project leads to put together individual reports for the community to let you know exactly what every part of the company has been doing. Read on!

Hey everyone! It’s been an amazing month chalked full of exciting work here in sunny Santa Monica. We love sharing with you everything we’ve been working on so enjoy and always let us know if you have any questions or thoughts!

Engineering

Our engineering team has been really busy this month. Everything from datastore clean up to the new character material system creation to large world updates. So let’s dig in:

We did some early implementation of the vehicle parameters where we were off loading the vehicles from parsing an xml on every spawn to parsing a single xml once and using it from then on to build a vehicle. Also, the only way we knew how to build a ship is to spawn it then look at what it contains. Now, other systems can just look up the parameters to build out a ship. We no longer need to spawn every ship below the hangar which was a massive change. We also had lots of integration bug fixes for FPS & Arena Commander. We continued working on the Radar 2.0 system where we moved the system from entity-only-based to practically anything the designers need to show on the HUD. The back end work is built, now we need to change HUD and other vehicle components to handle those objects so the designers can go nuts! We also did a lot of vehicle code clean up by deleting unused code which sped up a lot of the slow bits but this is going to be an ongoing process.

UI has been working tremendously hard on upcoming ship designs and implementation. Specifically, the glitch effects and boot up for the Vanduul. We reviewed a proposal for improved cockpit interaction and began preparation for HUD to support different seat actions and roles.

We’ve been doing some datastore cleanup, removing duplicated code, unifying different spread out code into single pass, and began preparation for Multicrew spawning/MP hangars. We separated object spawning from player spawning to move Hangar loading into level loading phase.

We’ve also been working on multi-layer material system. The goal is to end up with a fixed library of base materials that are blended together (up to 4 layers) to create more complex materials with minimal draw calls. Texture library and core shader functionality are mostly done, now working on the base material library that would bridge the render resources with the blended materials.

On the AI side, we’ve been doing a lot of ship bug fixing, particularly in regards to the pilot an AI ship creates and maintains. We also did a bit of work on the “defend target” wingmen command, creating an AI ship aspect that keeps track of nearby threats so that escorting ships will know what to attack.

On the Large World side, we fixed various trigger area issues in LW maps such as removed the +/- 16km limit for all the trigger areas and additional boundary conditions fix-up. We did a bit of interface clean-up for Matrix34 / Quat and established the prerequisite to make the rotational part of all those primitives to float. We also fixed the position info bar and GOTO position dialog and increased camera move speed in Sandbox while authoring LW maps. Lastly, we finished thread-safe texture loading with thread-safe shader parsing and thread-safe shader resource creation almost done. Phew, we had a great month and are looking forward to more!

Design

The design team here are keeping incredibly busy with all the upcoming ships, modes, gameplay needs, and so on. One of the bigger focuses for us was on the Genesis Starliner. We wanted to make sure we thought everything through to be ready to bring this awesome ship to you. We had a lot of work to get through this month such as establishing the initial gameplay balance plan which includes potential updates to stats, features, game modes, hud, controls, missiles, etc. Here are some of the in-depth details of this month:

We fixed an issue with the RSI Constellation Andromeda where the old Hangar Ready version would crash the hangar. Oops! We also switched the main elevator entrance from being a door to a switch to allow for entering/exiting via different doors without resetting the animation states. We also fixed both upper and lower turret hand positions. Also, in an effort to make the Constellation flight ready we overhauled thrusters.

For the Scythe dogfighter we dove into an issue in which the multilight was not loading into the light port and the archetype was crashing the client. We also removed unnecessary AI Space Ships and updated the Scythe to utilize “Scythe_Swarm” modification block to adjust AI Scythe health.

On the Hornet F7CM, we fixed an issue in which one of the thruster hard points was misnamed, preventing the thruster from loading onto the ship. We also combined the bound geometry and Weight Transfer Tool while refactoring controls design quite a bit.

On the Mustang Delta, we removed inclusion of default animations, which were colliding and causing problems (such as misplaced hatch and open/close animations not playing). We also implemented the AEGS Retaliator enter and exit Pilot Seat and updated the Interiors to use latest from Production level. That’s quite a bit of how our month went and are ready to go for the month of July.

Art

Overall, it’s been a very busy month for our art team in Santa Monica. Specifically, the vehicle artists have been busy focusing on the Merlin that just went through its final art pass and delivered to design to get flight ready. In addition, our Senior Vehicle Artist, Paul Forgy kicked off the first stages of getting the Bengal Carrier exterior white boxed and in the game engine. Can’t wait for those capital ships! With the new damage tech coming online, LA artists have been working hard to make sure the flight ready ships support the revised system. The Scythe is one of the first and has been setup for full damage support. Be sure to look for that in the near future. Now that’s not the only update to the Scythe. The ship’s cockpit has been retrofitted for human flight. Be expecting that in AC soon!

Alongside our ATX comrades, the LA studio has been working on revamping characters for not only the FPS, but for characters across all modules. Omar Aweidah is nearing finalizing the first gold standard to fully utilize the new character shader tech powered by Multi-LayerBlend written by our very own, Okka Kyaw. Now, we are ready to step up the character’s visual fidelity and take the massive leap into the future of character development for the Star Citizen universe.

Speaking of characters, our Production Designer of character concepts, Rob McKinnon is really ramping up our concept development quite heavily. We’re making great strides in developing looks for the characters of Star Citizen. 3D sculpts provided by Rob McKinnon and his team have given us our first 3d look at marine uniforms. Whether it’s a bridge office or a BDU, the marines are looking top notch. The Navy has tons of roles and responsibilities and we now have an outfit for each of them. From Officers on deck, to medics on call, the Navy uniforms are sharp and ready to begin 3d production.

With all the excitement of getting to ride the Meridian Transit, we have made sure you weren’t without a drink. The Genesis Starliner now has the very first concept designs for flight attendants. Also, the Vanduul just got a lot tougher with new images created from the concept team showing off new armor sets. The Vanduul now look meaner than ever. Under the armor has gone through revisions to attempt at finalizing the skin of this Alien race.

And that does it for the Santa Monica studio update for this month. Thank you so much for taking the time to look over all of the team’s hard work and supporting the creation of the game. None of this would be possible without your continued support and we’re honored to be able to make this game with you. We value your feedback and thoughts so keep them coming.

Hi Everyone!

It has been an unusually rainy and cool June in Texas and we’ve been enjoying it. We have hosted a number of visitors from other studios this month and we’ve been very focused on a number of different production priorities. We’ve made good progress on a number of fronts, and have a lot more work to do on the hard push to the end of the summer. Here are some detailed reports from the head of each team.

Persistent Universe Team

Art

This month the PU Concept Art Team spent the majority of their time fleshing out details of major features of the game. Ted Beargeon and Ken Fairclough crafted pieces that defined hero props for the Nyx>Delamar>Levski landing zone. We sent concepts of statues and large machinery over to BHVR to take to modeling. Likewise, some time was spent on fleshing out the Levski market area to help define the shopping experience there, as it will be different than anything we’ve done so far. Megan Cheever spent her time this month doing detail passes on various concepts of military personnel. She helped define the badges, medals, and materials you’ll see in the final game. Megan also concepted the flight attendant characters you saw in the Starliner sale this month.

Our PU Environment Team has been wrapping up the final detail passes on Levski as well. Lee Amarakoon and Emre Switzer have been providing VFX and Lighting support, respectively. Levski is beginning to look properly dark and gritty as a result of these guys’ work. Lee also got to work on revising the Customs Scanner effect you saw shown off at CitizenCon last year. Our Environment Leads, Cort Soest and Patrick Thomas, have been working with BHVR to optimize the environment itself and bring it the last 10 percent to completion. Next month Levski should be wrapped up and ready to show off somewhere down the road.

The Stanton>ArcCorp>Area18 landing zone has also been a huge focus for us this month. The environment has undergone some layout revisions to aid in optimizing it for release with the Social Module. Mark Skelton has been working in tandem with Tony Zurovec to provide direction for the changes. This environment is going to look better than ever as result.

The Character Team here in Austin just recently wrapped up the SATABall character and helmet, and it looks amazing! This was one of the first characters we took from start to finish utilizing our new Next-Gen Character Pipeline, and the new techniques have proven effective in making stellar characters for Star Citizen. We look forward to showing off David Jennison and Billy Lord’s work very soon!

The Austin Animation Team has had their hands full in several different areas of the project this month, per usual. We’re wrapping up work on the new female skeleton this week, which will allow us to finally get some ladies into the game proper! We’re also supporting Illfonic in implementing and polishing FPS animations, as well as polishing animations for Social Module. In addition, we’re working on standardizing animation templates for ship cockpits and enter/exit sequences to cut down on ship modeling time going forward. One thing you should see fairly soon are the updated G-Force animations in the cockpit. Jay Brushwood, Sean Tracy, and Jeff Zhu did a fantastic job bringing those to the next level.

Design

This month the PU Design Team spent much of their time brainstorming and fleshing out designs for upcoming player occupations in the PU. With Tony’s guidance, we have revamped the initial designs for the Bounty Hunter, Mercenary, and Piracy occupations. We’ve also drafted up designs for Smuggler and Search&Rescue occupations. The big one this month though was the Passenger Transport occupation designed by Tony Zurovec. If you haven’t had a chance to read the post from the Starliner Sale, you should totally check it out HERE.

Another thing our designers have been doing this month is testing out the new Usable Editor. The Usable Editor is part of Tony’s “Subsumption” peaceful NPC AI system. It’s the first major step towards achieving Tony’s vision for how NPC’s will interact with objects in Star Citizen. It’s been an iterative process, with the designers playing around with the Usable Editor and giving feedback, gameplay programmer Tom Davies adjusting based on that feedback, and repeat. We’re excited to see the Usable Editor in action for the first time and testing out how far we can stretch its limits.

Lastly, we are starting to dive in to the initial layouts/designs of the next planetside landing zone we want BHVR to tackle after Levksi. We’re focusing on another planetside landing zone in Stanton, going back and forth between Hurston, MicroTech, and Crusader. Which landing zone do YOU want to see come online next?

Engineering

June was spent continuing progress on a lot of longer term tasks, as well as planning and support for our upcoming releases and Gamescom demo.

There was a lot of focus on investigating ways to optimize server performance and we made some great progress on that front for upcoming Arena Commander, FPS and Social Module releases. As reported last month, our Generic Instance Manager (GIM) is in the works and incoming. The GIM will be a huge revamp of our party and matchmaking systems and it will go through multiple iterations until we’re happy with it. This first iteration has been with our QA team and they haven’t been shy about sending us bugs. We’ve been handling them quickly and getting closer and closer to what will eventually be GIM v1.0. We’re excited to reach the point when we can share it with you all, and it’s a highly anticipated system here within CIG.

Over at Wyrmbyte, in addition to being an important contributor to our server optimization investigation, they’re been deep in their iPredictor code…working diligently on hammering out the remaining kinks. Meanwhile, our tools team has been super busy with bugs and tool feature requests to help our team make the game. They never get a free moment as there’s no shortage of tools requests…and they’re happy to deliver! We also have some game-play programmers continuing to work on some proof-of-concept functional prototypes for some ofour occupations. It’s exhilarating to start seeing the early formulations of what will end up as our occupations in the Persistent Universe.

So unfortunately it’s a bit shorter of a report this month. However, it’s not due to anyone sleeping on the job, the team is mostly on long term tasks and have been making great progress on them! Many of these hope to be rolling out to you in the coming months.

Stay tuned!

Live Operations

QA

This month Star Citizen QA successfully conducted three cross-studio FPS playtests with development. Tyler Witkin has done a great job coordinating the playtests and gathering subsequent feedback.

Automation development has ramped up. Melissa Estrada and Tyler Witkin are using the Sandox Editor and Flow Graph Editor to build levels that utilize what’s known as the Feature Tester. These levels will be used to automate various ship and FPS related functionality testing.

Thanks to very informative feedback from Senior Technical Designer Rob Reininger, we have significantly improved our editor testing to include more tests related to tools and level design.

Social Module and Planetside testing continues thanks to the efforts of Todd Raffray. As soon as a system or tool is developed, Todd ensures it is added as a test case in our comprehensive Planetside testing. The latest addition is the Usable Editor. The Usable Editor is utilized to give NPC’s the ability to interact with objects. The Usable Editor is a big part of the overall Subsumtion (Peaceful NPC AI) System.

Jeffrey Pease is ensuring that the General Instance Manager is properly tested during its official implementation into Alpha 1.2.0. The General Instance Manager is our revamp of the back end lobby and matchmaking systems. Jeffrey is also leading an investigation into the prevention of potential hacks and exploits and has provided very valuable information to our engineering leads who now have a plan of action to address these issues.

Congratulations to Andrew Hesse who has transitioned into the role of QA Lead for the Austin Studio. Andrew has done an amazing job testing all aspects of the game and has been a huge help to our ship technical designers as our resident ship specialist. This month we welcome our newest addition to the QA team, Andrew Rexroth. Rex has extensive QA experience and is already a huge help with specialized Star Marine testing.

Next month, we will be continuing our testing of Alpha 1.2.0 while also looking towards testing multiplayer hangars, significantly larger play areas, the multi-crew system and much more.

Game Support

The month of June for Game Support was spent largely on designing, reviewing, and building infrastructure and processes that are going to help our backers on a service-wide level.

Particularly helpful will be our system-wide administrative broadcast tool which will allow us to provide a communication method to all players connected to a live service, which is essential to informing you with up-to-the-minute information while playing the game. We’re also working on replacing our current forum-based Live Service Notification page with its own webpage, which will ultimately include a Server Status page for all environments (Arena Commander, Star Marine, PTU, patching, etc.) and gives us an effective tool for communicating the health of the service to all players.

We’ve also continued to help triage the issues from May’s 1.1.3 release. We’ve identified and communicated the issues from the current release and actively worked with Production to get these issues highlighted and fixed, including some of the missile and ship damage state problems that we’ve been seeing.

Lastly, we’ve begun and flesh out ideas and designs for what we’re going to need to support our different environments, and particularly the Persistent Universe. Supporting gamers usually depends on the type of game, but Star Citizen will have all three (singleplayer, multiplayer, and PU)! We’ve begun to ask ourselves: What technical inefficiencies do we have in supporting our players today? What will be the expected behaviors inside the game, and what will they require from us as a service? How do we manage the raft of attempted account takeovers that occur in every PU, and what tools do we need so that players can protect themselves? How do we manage the players’ ability to go onto the secondary gray market without completely restricting it?

We don’t have the answers to all of this today, but we’re heavily invested them. These are important questions to ask in the formation of any online community, and especially the BDSSE!

IT/Operations

June has been an exciting month for the IT team. We’ve continued to make performance optimizations to our build systems and while each improvement brings great pride, we feel like we’re getting to the point where each new improvement, while important, bears smaller and smaller gains. Not all gains will come from hardware though so we’re again working closely with certain members of the DevOps team to reduce the size of data we’re moving and just as importantly reducing the number of times we need to move data. One of the remaining challenges is our asset build system. These are the graphical assets that must be rendered for each build and with the fidelity targets we’re working with, this is a very big portion of the build process. This month we’ve started the work to break that job in to many smaller jobs so we can run more of this work in parallel in order to get the overall build time down for this portion of the build. The DevOps team manages the build system logic and the IT team supplies the hardware for the jobs.

In addition to build system tuning, IT has been doing some extra travel this month. Paul from Austin and Hassan from Manchester have been traveling back and forth to our office in Frankfurt helping to plan the logistics of that studio’s office move. A good amount of planning and preparation goes in to a move like this and all is on schedule so far.

They’ve handled everything from electrical and cooling to IP addresses and VPN tunnels. Based on their hard work to get everything to fit in to a weekend, the dev team will not experience any down time.

Dennis from LA and Chris from Austin continue to build out custom configurations for testing based on feedback we’re receiving from the forums. We’re no longer just supplying reported gear to QA for one off testing. Dennis and Chris are now building and rebuilding custom systems in order to match reported systems in cases where we think hardware could be a contributing factor. They’ve also initiated early testing of Windows 10 in our test labs.

June has been an exciting and rewarding month for IT but we’ve got some even bigger things planned for July.

Dev Ops

June has been mainly consumed by 3 large projects for DevOps. The new Launcher, the new build server, and our “Phoenix” environment project.

The new launcher has already been broken into several code versions being worked on simultaneously. While the current public launcher is version 1.6, version 2.0 is in testing with the company and being used for the FPS playtests. Version 2.1 is being working on for roll out next week and will allow for faster downloads, smaller incremental patches, and some download speed improvements. Version 2.2 is coming right after that with a bunch more features, and version 3.0 is being worked on while all the rest of this process happens. Version 3.0 is a complete UI overhaul, and should be much closer to the final product.

The new build server is close to being done. We still are aiming for a mid-July release to the company with the first builds from that system going out to the public in September. For the players, they shouldn’t see any difference at all from this switch over. However for the company and the developers the improvements from this system should be huge. Not only should it allow us to run more builds at the same time, increasing the throughput of work, but reducing the amount of time developers wait for build, it will also lower overall build speeds. Currently, it takes 4hrs to make one build and we need to make around 6-8 builds a day for development to progress. As you can probably see, this is more time in the day than we have. So builds get backed up, skipped, and work slows down. The new build server will allow us to run 2-4 builds at the same time, and should reduce the 4hrs. We still need to do accurate measurements to figure out just how fast the builds will be.

As Chris Robert’s mentioned in his Letter from the Chairman, we have been working on the what we’re calling the “Phoenix” dynamic environments system. Each time the team kicks off a new build of Star Citizen all the data that the servers need is automatically copied out to hard disks in Google; this is a snapshot of our game data. These disks are broken into two to three conceptual parts: Base Image (the OS plus a few other things), Logs, and Server Data (Code and Assets). When we build an environment, we mount duplicates of these disks to each Virtual Machine (VM) that we bring up. Duplicates of the snapshot are created very rapidly, around 45 seconds for 200 gigs of data. We’ve written some automation code to automatically run commands on the VM to configure it appropriately for what type of server it will become (Game, Matchmaking, Party, etc.) During this process, a new DNS entry is assigned to the server based off the version of the data uploaded. When a new build is created, and we need to push it to an environment, we trigger a command that automatically shuts down all VM’s, unmounts the duplicated disks of the Base Image and Server Data disk (Log disks are always kept for troubleshooting), and then restarts the server with the new duplicates based of the new snapshot and the environment is running and ready on the new version.

This entire process takes about 8 minutes. When we want to take a QA environment that is built this way, and extend it to become a PTU environment, we send a command to our Provisioning layer and it goes out to Google, requests more VMs, builds more disk duplicates, mounts those snapshots, runs Chef commands to configure it, adds their DNS entries, and connects them to the existing infrastructure to be used. At that point we have a PTU environment. We repeat this process to build Production. Each time we expand an environment it takes about 8 to 10 minutes depending on the type of environment and the configurations we need.

The benefit of this dynamic creation and the environment expansion is threefold. First, any changed configs, misplaced settings, or broken processes are completely removed when the VMs are rebuilt using the new disk duplicates. Any configuration changes that need to persist should be made at the Chef level. Second, we can make absolutely sure that PTU and Production are the exact same environments that QA tested on, so there will be no strange differences we failed to catch in QA when we go live. The third benefit is simply speed. It is much faster to dynamically recreate environments on the fly than to recopy data each time. Those last two points are a pretty big deal. If our experience has taught us anything it is that having a consistent test environment that can be rolled out quickly is critically important, and this new system is pretty quick. It’s a huge force multiplier for our ability to rapidly iterate our test versions, which means QA and ultimately our backers will be able to do more varied testing more quickly. The more accurate we can get versions to our QA and to our backers the better we can ultimately make the game. July should be a very exciting month, with some of these major projects moving out of development and into production.

Greetings Citizens,

Foundry 42 is energized and ready to keep working hard! Between supporting the p-cap shoot in London, working on Squadron 42 in its own right and continuing engineering tasks for multicrew Arena Commander, we’ve been busy! Here’s the details from our department heads:

Animation

We’ve started work on breaking up some of the systemic Ai animations for enemy actions. These include things like stepping and running in to cover from various angles. Reacting to grenades and moving out of the way. As well as that the team has been working on refining some of the mechanics that are currently implemented in game to try and achieve a more responsive feel while keeping the realistic motion captured data. As always we’re on hand to provide any block out mechanics and environmental animations for the art and design teams here at Foundry 42.

Engineering

Two areas I’d like to talk about this month, which we’re getting more heavily involved with here in the UK, are the UI and AI.

On the AI front we’re taking a more active role in its development and have been doing a lot of the ground work getting our new CIGAI system up and running, alongside our colleagues in Frankfurt and Moon Collider. We have been looking at a new communication system, and how we can use it in conjunction with our current dialogue logic, to expand on the ground-work laid by the DFM survival mode’s Warlord and Vixen AI characters, as well as using it to make the cockpit audio system (a.k.a. Bitching Betty) smarter.

We’ve also been moving over some of the functionality from CryAI into our system and then amending it so it works better for our requirements on Star Citizen. So recently that has included the Tactical Point System, which includes things like cover, and the Group AI system, which allows better and easier handling of multiple AI objects, especially in the visual gameplay scripts (or the flow graph, which ever you prefer!)

On the UI we’ve been doing work here for quite some time now, but have recently started taking a bigger responsibility and taking on more of the work. We’ve been expanding the team with a new artist and a new engineer. Having the new engineer means that we can now have someone concentrating solely with bringing the User Interface requirements of Squadron 42 to life. Some of the many features that we have thrown his way are to develop the interface for the Tactical Visor and Looting. These will require various augmented reality overlays and post process effects to highlight people and objects, giving the player additional information about the world around them. We have also been performing an iteration on the visor displays for Star Marine, as each of the helmet types will have their own unique look and feel which require their own their own individual UI setup.

Our new artist is currently working on look-dev’ of the ship manufacturers, in parallel with this the ship UI code is undergoing lots of planning work so it can deal with multi-crew ships and all the challenges that throws our way, such as a captain being able to delegate (or lock out) various controls to the co-pilot or turret gunner. Planning is also underway to allow players to be able to customize their display outputs in their cockpits, giving them the ability to transfer various output to different displays. All of this planning is because, to support the functionality we require, the underlying structure that the UI code sits upon is going to need a bit of a refactor. We’ve already taken a lot of the hard coded setup of the UI and made it much more data driven (using our DataForge tool), but also were changing it to make it much more flexible, so any part of the HUD can be attached to anything else in the game that can take UI. So all of a sudden moving the radar from your visor and onto one of your cockpit displays becomes easy. This is going to be awesome!

Graphics

This month the UK graphics team have been focussing on several areas in parallel. The work on the mesh-merging tech continues, and is being trialled in larger environments such as asteroid fields to ensure it can handle any number of objects. This is coming along well and will be ready for production very soon and will start being used in public releases soon to give you better performance on new levels.

We’ve got a new senior programmer who’s been working on volumetric gas cloud rendering, investigating rendering dense clouds and soft fog with anisotropic lighting (the bright rim you get on the edge of clouds). This will be a very long term task as it’s hugely complex but is something we really want to push in our game. We’ve also been looking into facial animation technology, profiling various setups to see how far we can push the technology while maintaining a decent frame-rate. This includes trying different polygon counts, number of joints/bones in the face and the number of poses/blend-shapes that each character can use. As part of this we’ve also been investigating what we could do to push the rendering of our faces, which is no easy task when you also have to support many characters on screen. We’ll hopefully be starting this face rendering R’n’D next month and look forward to sharing the result (good or bad!).”

Design

June has been a busy month for design here with GamesCom looming. We are still flat out on Squadron 42, supporting the performance capture shoot with last minute level tweaks at the studio site to make it look at as fantastic as possible. All of the levels are looking more and more polished with a steady stream of great looking building tiles coming from our environment team that are iterated on until they look fantastic, while still allowing the level designers to layout the environments in a believable way.

We had an internal “Show-and-Tell” this month as a lot of the new staff had not seen the full depth of the plan for Star Citizen and it’s safe to say that it went fantastically well, with lots of jaw dropping amazement at depth of the game. It was great to see just how much work has actually been done in such a short period.

The technical design team has grown and is now covering tasks from FPS weapon balancing all the way to getting the Vanduul fleet operational in the engine, capital ships to fighters.

The Arena Commander team have now got the “large-world” code from the engineering team and are starting to realize what can be achieved in terms of universe size, suffice to say you should be seeing the fruits of their labours soon.

The systems designers have been finalising the specification for the “multi-functional displays” in the cockpits so that the functionality can be extended across all ships and is totally scalable from single-man ships up to larger capital ships. This is another one of our urgent tasks needed for GamesCom and will hopefully be shown in more detail very soon.

We are also trying to get a first implementation of “Quantum Jumping” ready to allow a more speedy way of navigating around the new “large-world” technology, which is looking very promising.

All in all a big month for us, but I’ve got a feeling we will be getting a lot busier in the next few months. Might be time to string up a hammock in the office soon. Thanks to everyone as always.

Art

Concept Art

Biggies this month have been the Bengal Bridge update and the Mining Bot, additional work continues on the Behring Ballistic shotgun, Xi’an transport ship, Vanduul fleet and further prop concept definition to add to the Shubin mining base and a few pirate bases needed for the Sq42 storyline (no spoilers!)

Ships

The Retaliator has been worked on this month to continue getting it ready for Flight – exciting times! Argo RUV is reaching Final art (excluding the pod which needs revisions for the cinematics), the Idris is looking very good in places, can’t wait to reveal some of it. Cutlass started its new greybox taking in to account design revisions, mining bot going to texture and material stage, Starfarer – going slower than we’d like, it’s a matter of resources, and we need more talented folk to help build this ship as its more complex than expected. Bengal Bridge will start once concepts are signed off.

Environment Art

A short update this month as much of what we’ve been doing must be kept secret for now. Progress is continuing with our VS environment which has hangars, control rooms, corridors, airlocks, and exterior landing pads – all of which can be traversed seamlessly. Hopefully we’ll be able to show you some of the really cool things we’ve been working on in the not too distant future, so stay tuned!

Props

We are getting clear documentation ready for outsource, dialling in with the techniques needed for materials which causes us most problems and then next month, we should be rolling.

VFX

The VFX team have been hard at work getting more ships “flight-ready” – this includes effects for thrusters, weapons and damage. In particular, the Scythe’s effects are looking pretty badass! We’ve also been continuing to iterate on environment effects – interior as well as exterior – for the Vertical Slice. We also began to focus on Star Marine’s weapon VFX, to make sure they’re matching the overall quality of the levels, characters and of course weapons. Truly exciting times to be a VFX artist at Foundry 42!

Audio

Hey everyone! This CIG Audio community report might meander a little, there’s a lot going on but think this should cover most of the interesting parts.

Firstly, Wwise. We’re nearly there as far as our mass of asset conversion/re-engineering is concerned; at least, the end is in sight. So Stefan, Darren and I have spent some time thinking more about how to set things up so we can mix the game well. Our game is on-going, constantly being revised of course, so the strategy we need to take is not typical to that we’d pursue for a one-shot release title. We think we have the basis of what should serve us well, and we’re changing the project structure to reflect this.

On the audio engineering side, much of it is still making sure things that used to work, work again; and ironing out any more emergent bugs/foibles that are still present. A certain ironic twist to what we’re doing is that the more we get individual sounds working, across all sorts of systems, the more we’re contributing to the problem of too many sounds playing, or being processed at some level, at once. Wwise has some ways of handling this situation, but the ideal is to make sure Wwise doesn’t get bogged down processing elements that are outside the player’s sphere of interest. At the core of it, if something is too far away to be heard, then we put it into a suspended-animation state where audio is concerned, but only to the extent that we need to so that when it comes back to life, it works as expected. There are all sorts of things to consider with this but that’s where we are right now in terms of core audio engineering. It’s not glamorous I know but it will keep things running smoothly if we get this right sooner rather than later.

We have a couple of new ships coming, one of which Darren’s been working on a lot. This had to have new dialogue recorded for its ship computer too and he’s been looking at the UI aspect, designing sounds and seeing how best to get them in. So much game UI these days is based somehow in Flash and that can be problematic for implementing sound in a way that we can iterate upon easily. So while we’re doing that we’re thinking of ways to improve this pipeline.

Incidentally, regarding the Origin ship computer, I’m holding my hands up on this one and admitting I failed to capture the previous essence of what made the ship computer so great for the Origin models. Basically, we’ve listened to you and absorbed the feedback you provided regarding the new one – and I’m absolutely determined that we’re going to win this one back. I’m not happy with it and this will be fixed!
Persistent Universe. We can’t say too much about this as yet but been ongoing support for the environmental audio for this.

FPS. So much of this is tied up in Wwise, there’s been plenty of new content required for FPS in terms of weapons, character Foley and dialogue and that’s coming along nicely. We’re getting a bunch of new music content down for FPS too. Thus we tested out a workflow where our composer, Pedro Macedo Camacho, works from his studio within Wwise, and we import what he sets up of his music into Wwise at our end. It’s not practical in terms of logistics to provide access to our own Wwise project (which is growing all the time), so testing out this workflow where he passes us a project file, has proved really valuable.

It was actually surprisingly easy to import his work-units into our Wwise project, and made me think that this might be an avenue for those of our modding community who wish to import their mods/material into Star Citizen. New assets could feasibly be produced by modders within Wwise, then passed to us for integration in the Wwise project, thus we export to sound banks etc. and pass the event triggers back to you for use. It might be a little unwieldy on the face of it, but I think ultimately working together with the modding community is the way to go to ensure a quality experience, and I’d love to try this out.

Arena Commander (or dog fighting module); a whole host of material has been converted, or some cases entirely re-created to work better than before. As Audio Director I don’t often get to do much sound design at the moment, which is obviously something of a shame as it’s what I am, at my core. So it’s been so good to be able to fit in some time for working on some ship thruster stuff and contribute in a material way to some thruster design! Luke’s taken what I’ve done and fixed it up a bit too, he’s very into the spaceship audio aspect of our game so that’s been reassuring for him to fix up my implementation. Generally a lot of this material is taking up time for all our sound designers, as it’s the lion’s share of Star Citizen right now there’s simply a lot to do but we’re whittling through it nicely.

Re: dialogue support for the Squadron 42. Our Dialogue Superman (not an official title) Bob Rissolo has still been hard at it down in London. It’s wrapping up soon, at least for now, which means he’ll be moving in-house permanently here to Foundry 42. A big move for him, we’re still hugely grateful he’s swapping sunny San Diego for the more, well, variable climate of Manchester!

Regarding our sound studios. By the time you read this we’ll have actually had our new doors installed for these. I know, doors seem like such an obvious thing to have, and of course, they are when you’re trying not to assail the rest of the studio with FPS gun sound effects, explosions and the like. But we’ve been waiting a while for a particular set of doors to be manufactured, simply we’ve been on the wrong end of some manufacturer-side production issues with them they’re each a different colour. I know that seems frivolous but when you have a number of isolated rooms and coming from another discipline, it saves time to be able to direct someone to the ‘orange sound studio’ rather than specify a room by who may or may not be there. Also means we can swap rooms to some extent. My own room is going to be a reference room for the rest of CIG Audio to test our surround mix, for instance.

Right now, tools improvements is something we’re considering. The better our tools, the easier it is for us to keep improving things. Wwise is an event-based system, and is reliant on external events of some form to trigger sounds in certain ways. For instance we want to trigger certain one shot-sounds when a thruster is transitioning from zero thrust to full thrust, on top of what we trigger for thrusters generally. And then trigger different one-shot events when the very same thruster transitions from full thrust back down to zero thrust. This is actually something that’s tricky to do ‘in the box’, the box being Wwise in this instance, so we want to be able to set-up these events more easily as sound designers rather than as programmers, so there’s a whole tool-set that we’re considering for defining logic to cater for this. This is just one tool out of many we can see a real need for.

We’re arranging to go back down to Pinewood, to record a whole bunch of duress elements for the ships. You might recall that they’ve worked with us on character Foley for FPS. There’s a new library of this sort of rattling, bone-shaking material that we’re also looking at (you can never have enough source) but we also want to make sure our stuff is that bit more individually tailored to our requirements. We’ll be taking down the Butt-kickers for this, for sure.

I’m sure there’s more stuff I’ve missed from this update, do feel free to ask us more on the Ask A Dev part of the community forums and we’ll continue to do our best to respond. Thanks for listening!

QA

UK QA have had to split our efforts this month to deal with the upcoming major events and releases. Star Marine (the FPS module) plus preparing for Gamescom, are on the cards for the near future, and Squadron 42 testing continues as normal.

Star Marine has had a lot of focus in order to root out major multiplayer bugs and try to find any general polish issues. Glenn Kneale from the UK and Tyler Witkin from ATX QA have been collaborating to make sure this game mode gets thoroughly tested. There’s been a lot of cross studio stress testing to help ensure that it should be stable once it gets released.

We’re focusing quite heavily on testing the sections of the game that will be shown at GamesCom. Unfortunately not too much can be mentioned there, but we’re all very excited about how what’s currently planned to be shown will be received.
Finally Squadron 42 is getting more testing time dedicated to it, as the game progresses we need to ensure the new mechanics are and alpha level run throughs can be completed. We also spent some time creating some more documentation to address our current plans to expand testing on S42.

Steven Brennon has continued to compile feedback from you guys and making sure it gets appropriately compiled and sent to the relevant people.

Sadly we’ll also be losing Chris “Chill” Hill at the end of the month. We wish him all the best as he’s been simply fantastic since he joined us last year, but looking forward we’re training up Steve Brennon to be a replacement lead.

June has been a busy month across all disciplines, and the team is building up in momentum. A large amount of strong applications have come in this month and we’re slowly getting through them 1 by 1. We continued to plan out our new office space, all things are set to get the keys to our new permanent office July 1st. We’ll make sure to share the new location with everyone in case anyone wants to stop by and say hi, with advanced notice of course.

Engineering

In June, Frankfurt Engineering deployed to the main codebase some major items that were planned for this month. As mentioned in the last monthly report, the Large World (moving the codebase to 64 bit coordinates), Camera Relative (rendering coordinates relative to the camera thus allowing galaxy size rendering without loss of precision), Zone system (the new Star Citizen spatial partitioning scheme, replacing Cryengine Octree) were close to hit the Star Citizen code mainline and have now been deployed, and will find their way into the various Star Citizen game modules soon.

The integration of relevant CryEngine 3.7 SDK parts, combined with our new changes, is being deployed into our codebase as we are writing this. Additionally a large effort this month was spent on supporting multi-crew vehicle ships: local physics grid, physics debugger, entities and prefabs, support for new 3D VisArea shapes, all this combined with the Zone System, are being worked on in the context of operating moveable ships. Amongst the other things, the multi-crew development process exposed a few bugs and incorrect functionalities that have been living in the CryEngine codebase for years …

We continued to work on optimizations, improved storage formats, bug fixing, clean up and general engine support to other CIG studios.

AI

During June, the AI development team has been focused mostly on the basic systems required for the human character to navigate through the full game world.

We completed the first pass on integrating the CryEngine MNM Navigation System and the multithreaded MNM Pathfinder. We also have completed the first pass on interfacing CryEngine Movement System with the current behaviour tree system. The Movement System takes care of analysing a path returned by the MNM Pathfollower and creates a plan on how to execute the movement.

Let’s imagine a character that needs to move into a cover position, the NPC will have to follow a path until the cover spot and then enter the right stance to actually position himself behind cover. The movement system allows us to have the proper context from the request to the execution of the movement, so that we can predict the necessary step the NPC has to take to correctly end up in a “behind cover” position.

We are in the middle of integrating the CryEngine Tactical Point System with our new behaviours. The Tactical Point System (or TPS) is a query system that allows us to query special position with specific properties.

In addition to the development of the systems we are taking care of creating all the glue code between the systems to allow the NPCs to have the best looking quality.
And we are also continuing coordinating the improvements on the Kythera Behavior Tree and its integration with Dataforge.

Design

This month the DE Design team has spent much of their time working on four initiatives: building a level for Squadron 42, assisting with the FPS module release, building AI behaviour trees for FPS, Squadron 42 and the Persistent Universe and then working with the UK team on Squadron 42 level feedback. We’re reviewing the missions and encounters they build for pacing, use of mechanics throughout the level, level flow and moment to moment gameplay ideas.

Animation

Currently the DE office only has 1 animator, fully focused on supporting cinematics. This month they worked on starting to set up scenes for scripted events and in-game cut scenes, getting pipeline tools identified and documented and a review of the Squadron 42 script (with the Cinematic director) to sort out which scenes will be owned by cinematics.

Cinematics

Hannes is back from the long cinematic shoot. He’ll be able to contribute to the monthly report starting next month. They had some truly talented actors on stage that gave amazing performances. We all internally look forward to pulling these together, as I’m sure the backers do as well.

Audio

Not much new for audio this month, still working on Wwise conversion that started last month. Hooked up the EVA thrusters and Ship Shield impacts to use the Wwise audio system, fixed several audio-related bugs. Started work on improving the distance-based culling of active sound emitters to let the sound designers create more detailed soundscapes without overloading the sound engine.

Build System

In June our Senior Build engineer visited our Austin studio (ATX) for 3 weeks and worked close to the Dev-Ops /IT teams on many aspects of our builds process, optimization and cross studio delivery. Among many things, the main goal was to reduce the amount of time it takes to put together a build, make patches, deploy servers and so forth.

We’ve decided to move away from the current build system in favor of something that we are confident will give us much more customization capabilities to better tailor it around our game’s needs. This is still work in progress, a lot of work has been done, and even more will be done in the next upcoming weeks.

VFX

For the past month we have been working hard on various squadron 42 effects. One of these effects has been a giant plasma drill. It is used to break up asteroids into smaller pieces for resource extraction.

Greetings Citizens!

Another whole month has gone by and we have been busy!

Engineering

As usual, a portion of the team has been focused on development for short term deliveries such as support for FPS Lobby & Flow. We’re also slowly moving away from that, now that it supports most of what we need for the first version, and have been starting to add support of multi-crew ships in the Lobby UI.

The month of June has brought us a few great features from other studios which has allowed us to work in tandem in order to add a bit more functionality to online hangars. We’ve been working hard on the current Holotable implementation in order to reduce the need for ships to be spawned in the game for them to be used in Arena Commander. This will allow us to reduce loading times as well as to facilitate management of server hosted Hangars. We have also been reworking part of the flairs implementation and Hangar spawning to work properly in such a context.

The planetside experience hasn’t been left to itself either as we’re still working on adding some features and a level of polish to the Augmented Reality (AR) experience with mobiGlas as well as the shopping experience as a whole.

Design

The design team has been setting up elevators and doors for Nyx, as well as setting up various functions (such as dynamic spawning, mobiGlas AR tags, and text string localization) for the items that will appear in Casaba outlet. We have also been doing follow-ups on the shopping experience, flair objects, and Level Design blueprints for Hurston, Crusader, and Microtech.

Art

This month we did a lot of work polishing for the Nyx asteroid map, improving materials/textures and dressing the environment to ensure that each room has a story to tell. We’ve also worked on improving one of our previous maps, modifying its layout to optimize navigation and improve performance.

Additional efforts were done on our shop system. We’ve added details on how clothing will be placed on the shelves to allow for good visibility from the player’s perspective.

Finally, as always, we’ve completed next month’s Flair object. Enjoy!

UI

The UI team has been doing quite a bit of spring cleaning (never too late!). We have been working on a thorough pass of the new holotable design flow to smooth out the whole user experience and to unify the various screens. Same goes for the simpod interface (also known as Electronic Access). We have also been cleaning up a lot of low priority tasks that have slowly and steadily been piling up.

Till next time, Citizens!

Hello Citizens!

Another month, another update. Quite a bit has happened over the last month. At the moment we have three guests from CiG (Sean Tracy, Steve Bender and Jason Hutchins) visiting us in Denver and helping out any way they can. We are currently focused on getting core locomotion as solid as we can, while still having the animations look great in both 1st and 3rd person. This isn’t easy by any means, which is why we have the extra reinforcements! You can find additional updates on the FPS module push in the weekly Star Marine update.

Engineering

Over the last month, engineering has been primarily focused on core locomotion and the start/stop/juke system. This has been close work with animators and designers, working out all the edge cases, and trying to find the absolute best balance between control response and animation quality. Everything then needs to work and be polished for both 1st and 3rd person modes. In addition to core locomotion, they have also created rules for Star Marine so that it reports stats in the same way that Arena Commander does for leaderboards and the accruement of REC. Lastly 5 different movement speeds were implemented. This makes moving with a controller very fluid and variable, depending on how much tilt is being applied to the stick.

Animation

The animators have all been laser focused on getting everything looking as good as possible with starts/stops/jukes. This has mostly involved a very quick feedback loop with Steve Bender. Getting his feedback, making tweaks and sending back the results until everybody is happy. It is a lot of work to be sure, but the team here is doing some really good work and the velocity of that work increases almost daily, now that the processes have been figured out.

Art

The art team has been working on optimizing all of the asset pieces for the Gold Horizon Station set, along with tweaking assets to match up with the metrics that are being used over at Foundry 42. This isn’t exactly the most interesting work, but it is something that needs to be done in the long run for persistent universe and Squadron 42.

Design

The design team is making numerous tweaks to the Gold Horizon level at the request of CiG. This includes some tweaks to ammo & energy placement locations, removing some doors and changing the behavior of others through the level. In addition, they are also tweaking the lines of sight throughout the level, and doing a polish pass on cover placement.

That’s all I have for you Guys and Gals this month. Until next time!

Here’s what we’ve been up to in this last month up here in Montreal:

Jump Point interview

First of all, this month our team had the opportunity to participate in an interview for an issue of Jump Point. This gave us the avenue to discuss some of the projects that we have been working for Star Citizen and shed some light on what is coming next. Thanks to David Ladyman for allowing us to go into a bit more details (and in a slightly more informal way) about our process for redesigning the site’s global look.

Starmap

This month, we completed the main art for the Starmap viewer, including Galaxy and System views. In terms of the interface, we made some significant changes to the HUD as well as filtering options (sensors and heat grid).

On the data side, we made good progress on data modeling for the upcoming Galactapedia. We also worked on our own administration tools so that we can import data from the Star Citizen universe. This will allow for having all the data of the different celestial objects already in a Galactapedia format.

On the 3D front, we started production of the different assets that will be displayed in the WebGL viewer (planet, jump point, space station, etc). This is very work intensive and it’s what the user will see on their screen, and so we’ll be working on this for the next couple of months.

Issue Council

As reported last time, we have continually been evolving the Issue Council to ensure that it greatly reduces the amount of time/effort for everyone involved. We have also been working to make sure that it cannot be easily swayed by large groups of users (such as organizations). We have been adding new features, re-organizing layouts, moving things from one page to another, removing pages, and so on — so much so that when we took a step back and looked at it all we realized that the UI was no longer intuitive. So we gathered the team around a big whiteboard and worked on fixing this.

The core update we worked out was an updated flow for the users. Upon arrival at the Issue Council, users will be provided with three ways of approaching the system:

1. Contribute by attempting to replicate issues and flagging invalid tickets (duplicates, feature-requests, poorly written, etc).
2. Prioritize the confirmed tickets to help the developers know what is important to the community.
3. Search all tickets that have ever been created.

We will soon have some designs to share, but to give a bit of insight here’s a photo of one of Benoit’s whiteboard designs.

Community Hub

The Community hub has entered its final stretch, and our developers have been working on actually implementing it for the whole month. The main notable undertaking on this specific project was to set up the submission flows. These will allow you to upload pictures and galleries of your own creations, embed your youtube play sessions, or report interesting links you’ve found elsewhere, which requires a great deal of technical flexibility from the website itself. Even more interesting was that we took some time devising filters and sorting algorithms based on the amount and frequency of content posted and their popularity through upvotes and comments. It’s always an exciting challenge to devise the way a website will display its own content, to keep it as relevant and fresh as possible.

Moderation tools

Another project that we have been working on, which has recently launched, was the new Moderation Tools, for the site’s dedicated team of moderators. These tools now give them more insight into flagged contents, repeat offenders and infamous recidivists, as well as a quicker way to manage forum access. This allows them to keep the forums, comments and Orgs running even more smoothly and efficiently. With their help, we’ve devised a set of tools that will then be expandable to cover all user-generated contents, including all aspects of the upcoming Community Hub as well.

This month’s concept sale was a short story showcasing the Genesis Starliner as operated by Meridian Transit. This quick tear-jerker (go read the postcards) was written by Star Citizen’s own writers, and along with some pretty cool art and voiceovers from the Community team, it gave us a lot of room to have fun with the post. This is why it quickly became one of the site’s most script-heavy pages, with mini components like the Flight board or the flipping postcards. The flight board itself was based on a very early concept for the Events block on the website’s homepage, which we were really fond of but put too much stress on browsers. So we were really happy to be able to use it anyway as part of the short story.

What you didn’t see

Just like for any other month, our programmers were also tasked with improvements and fixes that have gone unnoticed, thankfully. Prominent this June were the payment processors that we use : Amazon migrated their whole payment system, which we had to adapt to, along with transitioning to an entirely new way of handling subscriptions. Another one that shall remain unnamed cough*paypal*cough also had some interesting surprises for us that we had to react to very quickly. We’ve also dedicated some time to providing new tools to the Customer Service team, to help them deal with problematic cases even more efficiently.

It’s been another busy month at Moon Collider, so let’s jump straight into it:

Engineering

It’s a well known saying that no plan survives contact with the enemy, and I think an equally valid saying would be no tool survives contact with the designers! No matter how well you design any new tool, the moment designers start playing with it you’ll find out very fast what needs improvement. Last month we gave designers the ability to write behavior trees using an editor built into DataForge, Star Citizen’s custom data management tool. We tried to get it into designer hands as quickly as we could, so we already had a decent sized todo list of improvements we knew were needed, but a few hours of real use of a tool by a designer always helps to clarify which issues are minor annoyances, and which ones frequently interrupt their workflow or straight up make them unable to do some task.

We spent some time this month getting feedback from designers and working through their prioritized list of issues with the new editor. This included things as simple as writing up more documentation on how certain features worked; renaming, recategorizing and recoloring BT nodes in ways that are more intuitive to a designer; and even moving certain advanced pieces of functionality out of the standard workflow so that it’s a little more laborious to use those rarely needed features but it makes the common features more streamlined. We expect to continue improving this tool next month as the feedback from designers keeps on coming through.

With the designers now working on behavior trees with DataForge, it was also perfect timing for adding a behavior tree live view to our Kythera Inspector web based debugging tool. This is a web page that designers can bring up that gives direct access to the state of the AI in their game, and we’ve been constantly added features to it in order to make debugging AI easier. Up to now we’ve been relying on some simple on screen text debugging to help us understand the current state of an AI’s behavior tree, and while this worked reasonably well for a small and simple tree, it was much less useful for larger trees, and also limited in the information provided.

The new live view in Inspector allows designers to see the state of the behavior tree of any AI while the game is running. We have some new features coming next month that will allow this view to help them track down configuration errors with their trees, which, when combined with the already existing ability to record and play back the behavior trees of the AI, should give designers a comprehensive suite of tools for debugging their behavior trees.

One issue we’ve been trying to sort out for a while is a technical feature we call a string hash. This is something that is built into Kythera and basically allows us to convert any text string in the code into a numerical identifier at compile time. This makes it cheap and efficient to pass strings around in the code and use them without worrying about it being expensive to do comparisons, which is usually the case with strings. And this means that you can have a lot more descriptive text being passed around in your code rather than simple numbers, which can make code that’s easier to work with and easier to debug.

Because this is such a useful feature, a similar version has been added to the rest of the Star Citizen codebase. What we’ve been trying to work out is how best to unify these two different versions of string hashes, so we can avoid the cost of converting between them. There are various details that make this trickier to solve in a satisfying way than it might initially seem, so we’ve been spending time working this out with coders in some of the other studios and are currently testing some possible solutions to try them out and see if they cause problems in practice.

Now, let’s talk ships!

Last month we added in the feature that allows ships to reliably join splines. This month we started making good use of that feature in the form of retreat stunt splines. Stunt splines are paths that are laid down by designers in a level and allow AI to fly through tight areas where their collision avoidance would otherwise stop them from going, such as through a tunnel in an asteroid or gaps between sections of a space station.

One of the main goals of these stunt splines is to set up opportunities for players to chase AI through interesting and exciting paths. We’ve added them to AI retreat behaviors so that when an AI ship wants to break away from a pursuer, if there is a stunt spline nearby it will try to make use of it. To keep things believable, the AI will only pick a spline if it can get onto it quickly, so they won’t use one if it requires a major change in speed or direction to get to it.

We can also use them to distinguish elite AI pilots from rookies by having a skill level attached to the spline. So a really hairy maneuver can be marked as only available to the best pilots. This also means that if you go to chase a fleeing elite ship, you may find yourself in a chase that you’re not good enough to pull off, and you’ll need to make a quick decision on just how crazy a pilot you’re willing to be!

Once designers have had a chance to work with this feature, we plan to make some refinements to the spline selection process to get a good balance so they’re not overused or underused. It’s important that the AI don’t become too predictable to a player who is familiar with a map, but on the other hand, seeing a ship break off and head towards that tunnel you know is great fun to fly through can be something to anticipate as well.

As is always the case with new features, we’re looking forward to seeing this one get into the hands of real players and hearing the cool stories that come from it!

Greetings Citizens,

We always say that it has been a busy month for the community team, but at this point… what month isn’t busy?

We were very happy this month to celebrate the first anniversary of Around the Verse! AtV has been an interesting project for us; last year, we went into the s how dreading the need to replace fan favorite Wingman’s Hangar… and we took time to find our feet and figure out what was important. Thanks to your feedback (and your support!) we’re proud of what the show has become… and we’re going to try and keep making it better. Episode 50, aired last week, had one especially standout segment in which designer Randy Vasquez showed his process for building Starliner interiors. Expect to see more segments like this in the future, as we felt it was our strongest piece yet.

We’ve also asked the community team to be more interactive on the forums. We’re just as eager to see Star Marine release as the rest of the community, and we’re going to do our best to get out there and not just show the flag but share our answers and thoughts with all of you. A Community Manager can’t always answer your questions… but we’re here to address what we can and also listen to your concerns and make sure developers are aware of them. Even better, we’re working on a relaunch of the ‘Ask a Dev’ process, which will hopefully result in a system for getting your questions answered by the experts.

The whole team also had a field day with the Genesis Starliner sale. We wanted to get across just how much depth there was to the ship, and the whole team worked together to add pieces to the presentation that we thought would interest the community. From Jared’s postcards to Ryan’s safety card, we wanted to show you more than just how big the guns were (and if we’re being honest, the guns are not that big in the first place.)

Finally, we’re very sad to lose one of our own: Chelsea Day, manager of the Customer Service team, has left CIG to relocate. Chelsea was a good friend and a great CS manager; we’re all going to miss her! Patrick Probst, who you may have seen on the forums, will be taking over the CS manager position in the UK. So congratulations – we know you’ll live up to the example Chelsea set!