Greetings Citizens, It’s hard to believe June is already upon us! Work on Star Citizen continues at a frenzied pace at our studios and outsource partners around the world. This month, we’re excited to introduce our latest studio, Foundry 42 Germany, to the report. You’ll be seeing a lot from Germany in the coming months: they’re charged with tackling many of the programming challenges facing Star Citizen on the road to the persistent universe. Work continues in those areas, and on our many modules and milestones, from Star Marine (now being readied for its PTU debut) to Squadron 42 (cinematics currently being directed by Chris Roberts in London!) Your top-level view of exactly what we’ve done this month can be found below.
Welcome back for another edition of the Monthly Report! This month has been an eventful one with lots of development news to cover. As always, we’re super excited to share with you what we’ve been up to over this past month! So settle in and get comfortable because here goes the development update!
Design ConceptArt-AtmosphericFlight One of the biggest developments from May was the reveal and concept sale for the MISC Reliant. This sale was a big accomplishment for us, and really felt like we had every department firing on all cylinders to get the sale ready. Everyone involved in the sale really pushed to make sure that it wasn’t just ready on-time, but it was ready early. It’s been a great example of our various departments pooling together to help bring another of these incredible ships to life. We’re also pretty confident that the community liked it as well, with over 19,000 sold during the concept sale. Thank you all so much for both supporting this great new ship from MISC, as well as the on going development of Star Citizen.
We’ve taken a balance pass over the current roster of missiles, specifically by increasing the vulnerability of all CS-lock missiles (Tempest, Stalker, StrikeForce) to noise emitted by chaff, thus allowing those fired upon a better chance at escaping the wrath of these powerful munitions. Additionally, missile lock on times have been increased across the board (from 2 to 5 secs.), so pilots, brush up on those maneuvering skills! Keeping eyes on target just got that much more important. Fire-and-forget missiles also become more practical with this change. Happy hunting!
On of the ships coming down the pipeline is the Crusader Industries Genesis Starliner. The Starliner is a big ship, being a bit larger than a 747. This ship is unique in that it is one of the first Passenger ships tackled by the Star Citizen team. With it being the first ship of its kind, it has made us question our designs within regards to passengers in space. For instance, some of the questions still being answered is passenger capacity, safety of those passengers, and max flight times. The exterior concept is in a solid place, but the interior concepts are still being worked on. We are really excited to show you all what we have come up with. Soon, the Starliner will sail the stars with you at its helm, or as a passenger on your way to that vacation spot you wanted to check out.
Initially talked about in the March update, we’re continuing to make strides towards our new Physically Based Damage system. This new system is going to help on a number of fronts for current Arena Commander gameplay, as well as helping to setup to great foundations for Squadron 42 and the PU to be built out of. Some of the biggest highlights include a complete revamp on the damage and handling for every weapon with a definite focus on making sure Ballistic and Energy weapons each have their own unique characteristics and gameplay implications. But when you’re changing damage, that’s only part of the puzzle, so also expect a comparable update for every major ship-component to help support this new system: Ship and Shield health, Powerplant output, Cooling rates, the works.
Another big event in May for the Santa Monica office was having John Pritchett and Pete Mackay in the office as we started to really dial in some of the flight and thruster handling for the game. While they’ve talked about some of their work during recent Around the Verse appearances, there’s a lot of behind the scenes work their visit helped us to streamline. Now, we have even better tools and data setup to make building out new ships and components smoother and more consistent than before. This work already helped with the lead up to the Reliant sale and let us rapidly build out the mass and thruster requirements for the ship faster than ever.
Art For the HUD & UI, we’ve done some work to improve CPU / rendering performance by optimizing the amount of draw calls that the scaleform aspect of the HUD was contributing as well as a refactor of the holo-objects which should go towards improving rendering performance of holographic items and entities. Overall, the amount of CPU resources that the HUD / UI takes up should now be considerably less, and we will continue to optimize it for the best performance possible.
This month Josh Coons and Mark McCall have created and implemented new helmet interiors that will be used for all FPS characters. This new direction for the helmets is a big step in realizing Chris Roberts overall vision for Star Citizen characters. The new helmet interior design will give the HUD team more flexibility and add to the realism of our universe.
What makes our helmets unique is that they have an effect on the player’s field of vision, improving the versimiltude in our FPS gaming experience. Equipment in our game should feel real and substantive – not just a set of stats and numbers to be min-maxed in gameplay, with characteristics that give different players choices based on their own subjective preferences and adding to the diversity of player choices.
For Technical Art, our focus this month has been on Ship Destruction, Salvage and Optimization. We’ve been tasked to find balance between the most optimized damage approach while at the same time making sure our Gameplay Design remains intact.
In the past, for ship damage we would build out five versions of every part of a ship. These were the 0%, 25%, 50%, 75% and 100% damaged versions. Blowing ships to bits looked very cool, but this solution was extremely labor intensive, used a lot of system resources and wasn’t scalable to allow CryEngine to render the epic armada of ships battling that Chris has envisioned.
We needed a new damage solution. So, Ali Brown, Okka Kyaw, Geoff Birch, and Mark Abent all helped to create our new Damage Shader and Squib tech that allowed for the destruction of our newest ships without the high resource cost. But even as we accomplished this great feat of optimization, our Designers were planning new gameplay mechanics such as Debris Salvage and Ship Repair, each of which adds costs to the overall processing demands of our ship model.
The real enemy of performance in Star Citizen with so many high-fidelity assets being rendered is “Draw Calls”. For those unfamiliar, Draw Calls are the amount of render passes on each piece of geometry to create the final image. If your spaceship hull has Diffuse, Specular and Normal textures, then that would equate to 3 draw calls. And if your ship is divided into a 50 pieces, that would be 50 × 3 = 150 draw calls. And add some high-quality self-shadowing, and you can double 150 to a huge 300 Draw Calls! Our ships being rendered with PBR (Physically Based Rendering), with the Damage Shader, Paint Variations and Decals requiring more like 15-30 draw calls per piece. So, to optimize Draw Calls, we needed to reduce the number of separate pieces. But, this means, to be truly optimized we would need to have fewer animated pieces and fewer debris break off of the ship! Quite a conundrum because we want those things!
In speaking with Ali about these optimization issues, he suggested a new debris approach that we’ve have now been investigating. Instead of cutting the ship into separate, damageable areas and breaking debris off of the ship, he suggested we could hide parts of the ship using the Damage Shader and spawn Debris that would then fly away from the ship. This new approach still looks like debris is blown off of the ship, but allows us to reduce the number of ship hull meshes which also reduces draw calls significantly. And furthermore, this solution allows us to create debris that will contain Salvageable Components! So, that gun you just shot off that Cutlass in the PU? It’s yours now. You’re welcome.
There have been many other breakthroughs like this one. And this month has brought us closer than ever to realizing the space opera of our dreams. Now, our job is to implement the full optimization plan across all ships in the game, the goal being that we release Squadron 42 with amazingly fun gameplay and a silky-smooth frame-rate.
Engineering Radar 2.0 work has been completed. Anything can be registered to be shown on the radar so long as there is a matching IRadarObject struct. What this means in laymen’s terms is that as long as an item/object has the proper information in it, that object will be picked up and displayed on the radar based off its physical properties. Yes, we can even give EMP grenades an EM signature and have it show up on the radar if your radar is configured to detect EM.
We’ve also made it so that radars are capable of filtering for any kind of signature type and detected objects now have an instance of them created. The creation of this instance allows for us to do things like stutter position updates and/or show decay/falloff without affecting the actual detected object. This lets Design and Art do cool and interesting things to the instance version that is displayed without breaking the underlying logic that drives the radar/signature. As part of this we’ve also improved the performance of occlusion checks.
Last but not least we’ve added support for “decibels” as a new signature type. While on foot in Star Citizen your radar can display audio from the surrounding environment such as footsteps and weapons fire. These events are now properly hooked up into the signature system so that your footsteps and weapons fire creates “decibels” which are scanned for and displayed by the player radar. You’ll see this debuting with the FPS.
Our LA Engineering team has also been helping out on handling player/character clothing, customization, and attachments using the item port system that we’ve developed. The item port system allows the attaching of items to bones defined on 3D objects. This is how we attach all our ship parts and ship items. This system is being expanded upon for characters to support dynamic skeleton extension using skinned attachments.
What this means in real terms is that we have the pieces of the body that are able to equip items. I.E. Feet, hands, left hand, right hand, torso, etc. marked with corresponding bones which define where attached items are attached. From there, if you were to equip a chest piece that allows a tactical shoulder light, oxygen tank, and chest holster each of those additional attachment points require additional bones. The system allows any of the extra bones that come in a skin (skinned object, not actual skin) attachment to extend the base skeleton by dynamically updating that skeleton with the additional bones.
That wraps up the update for the Santa Monica studio! Thank you as always for taking the time to read our story and for your support in making this game! We couldn’t do this without each and every one of you and your support is highly valued by each of us here at Cloud Imperium. Thanks again and we’ll see you for next month’s update!
April showers have turned into May floods in Texas! We’ve been hit with severe weather and major flooding as you may have seen in the news. Thankfully our studio has been mostly spared from this destruction and we’ve been moving ahead as usual. We’ve been testing new builds of Star Marine and hard at work on the Persistent Universe and many technical activities. Here are some detailed reports from the head of each team.
Persistent Universe Team Art The PU Art team has had its hands in a lot of areas of the project this month, as usual. One of our main focuses has been moving the Nyx>Delamar>Levski landing zone into Final Art stage. We’re passed Greybox stage now and the environment is looking amazing. Art Director Mark Skelton, Lead Artist Patrick Thomas, and Global Environment Lead Ian Leyland have been working closely with BHVR to make this environment truly something to behold. VFX artist Lee Amarakoon and Lighting artist Marc Toscano have been busy adding that extra touch of fog, smoke, and lighting to breathe life into this environment. We can’t wait to see you guys participating in shady back-alley dealings, selling things on the black market, and traversing the winding asteroid tunnels that this environment has to offer.
Another major focus has been optimizing the Stanton>ArcCorp>Area18 landing zone for better performance in preparation for the Social Module release. The extremely high level of detail and fidelity that makes our environments so amazing are pretty taxing on performance, but with new tech in place from our Graphics team we are able to greatly improve our performance through various means.
Concept artist Ken Fairclough finished up a concept of a security turret prop that will eventually be found on landing zones like ArcCorp. These security turrets will be there to punish players who draw their weapons in areas that don’t allow them. They will also act as a deterrent for trolls and griefers who think it’s a great idea to open fire on random civilians.
Our Character Team has been wrapping up support on the FPS characters. The Marines and Outlaws are at a point where we have bid them adieu and now our attention has shifted to creating the characters that will be seen playing SATABall in Astro Arena. We’ve got some pretty slick new concepts we’ve been working from and should be wrapping up in the next couple of weeks. Our character team has also been doing some R&D on Hair and Swappable Clothing for the upcoming Social Module release.
The Austin Animation Team has been supporting various areas of the project as well. We’ve had our hands full retargeting old PU, FPS, and Arena Commander animations to our new skeleton. We’ve also been providing support for improving the G-Force animations and testing out the Grabby Hands system. Senior Animator David Peng has been focusing 100% of his attention on updating cockpit and gunner templates to match the character’s new proportions. We now have 7 cockpit types and 20 button combinations for our artists to choose from when creating cockpits.
Design Much of Design’s time this month was spent on fleshing out some of our other occupations that players can eventually choose to adopt in the PU. Tony Zurovec spent much of his time working out the ins and outs of the Pioneer (formerly exploration) occupation and how it relates to the functionality of an upcoming ship. Rob Reininger completed a first pass of how the Mercenary/Escort occupation would work, while Nate Blaisdell and Evan Manning tackled the Bounty Hunter and Smuggler occupations, respectively. These designs are now sitting with Tony Z for review and once approved will be moved over to the queue with Andrew Nguyen for gameplay implementation.
Tony Z also finished his first draft of the new Universe Simulator (formerly the Economic Simulator) and forwarded it to the team over at Wyrmbyte. The new design incorporates much more than just the economy system that will be in the PU, now including things like the ability to create elementals and composites, the ability to create a planet within a solar system and assign it data, and the ability to create occupations for NPC’s and specify execution logic for each occupation.
Mark Skelton and Tony Z, along with Lead Writer David Haddock, met with BHVR to go over designs and layouts for upcoming planetside locations. Specifically this month our attention has been on Magnus>Borea>Odyssa and Helios>Tangaroa>Mariana. Both of these locations will offer several new exciting opportunities and diversity to our already impressive stable of landing zones. We’ll share some exciting look development with you guys as it comes online. Next month we will turn our attention to the other landing zones within the Stanton System: Crusader, Hurston, and MicroTech.
Engineering The month of May was a very busy month for the Engineering Team here in Austin and for the Wyrmbyte Team. A lot of big ticket items were completed and ready for initial testing. One big item that everyone has been waiting for is our new Generic Instance Manager, which promises to bring notable improvements to systems such as matchmaking and party. This was architected by Jason Ely, and he brought it home with strong support from Tom Sawyer. We will run initial testing on this new system, which is intended to be a part of the upcoming FPS release.
Meanwhile…over at Wyrmbyte…Scott Brown, Nathan Gray and Ryan Seabury have been working on our Universe Simulator and are about to deliver a proof-of-concept iteration with base functionality in. The next step is to continue to expand on this until we can create a working demo to share internally for further discussion on how to further build upon it. At the same time, Ian Guthrie is working on the first iteration of our Solar System Server, and will be wrapping up an initial iteration of that soon. The Wyrmbyte Team has also delivered a rewrite of our Player Info Server and our Presence Server in May and are continuing to work on their iPredictor ships and missiles movement system.
Our other engineers have been busy, too…Tom Davies has finished v1.0 of our Useable Editor for our NPC AI needs, and Jeff Uriarte is making solid progress on the Character Archetype Editor, which is another tool for our design team. Andrew Nguyen has been in R&D Land prepping for the initial prototyping of another occupation (tentatively called the “Discover” occupation), and he has just wrapped up an initial prototype for the Mining occupation.
Brian Mazza has been deep in crucial work needed by the team at large, such as implementing Google Brakepad for better crash reports, porting our Universe backend, and fixing server bugs that were blocking team progress and preventing build stability. Across the hall from Brian, James Wright has been working closely with QA on profiling and analyzing performance on our various builds, including a recent PTU build and our pending FPS build. This data is helping us determine problem areas that need attention in order to improve overall performance. And James has recruited the aid of Clive Johnson (who is close to wrapping up his work on implementing our Unique Global Entity ID system) and George Kidd from the UK Team to help investigate some of the critical performance issues uncovered in his profiling results.
On the tools side of things, Benjamin Bechtel has rolled out a new improved version of his Asset Validation Tool with an all new user interface. This tool is used daily by our artists. Benjamin is also awaiting a visit in June from UK tools engineer Ashly Canning to work together on our Dataforge Tool. Sean Tracy and Jeffery Zhu have rolled out the first phase of their stream restructuring, which will greatly help streamline our stream flows in getting our development streams all the way out to our live product. Lastly, these two gentlemen have spent a great deal of time and effort supporting Cort Soest on our much needed and super long task of cleaning up our Perforce data. The first two phases of this task have wrapped up in May.
The team is anticipating June and looking forward to offering their support on the upcoming FPS release, as well as continued work towards our upcoming Social Module.
Live Operations QA For the QA team, May began with testing and releasing 1.1.2 and subsequently 1.1.3. With help from our Senior Engine Programmer James Wright, we conducted a specialized PTU test that utilized a separate server CPU thread to calculate physics. The results showed significant performance improvements during matches.
Changes have been made to how we utilize different streams and branches with Perforce, our versioning control software. This will help with a much more structured and smooth release and feature integration process. This has also resulted in an increased workload for QA to ensure these additional streams or branches of the game and editor are properly tested. However the team is doing a great job rising to the occasion to ensure this additional testing requirement is met.
Our FPS specialists have been very busy ensuring Star Marine is properly tested each day. The team was fortunate enough to be able to provide feedback directly to design director Todd Papy. Todd was very responsive to each point raised. After discussing these points, Todd tasked up and prioritized any agreed upon changes. As QA, it is very fulfilling to be able to be a part of the direction of development in such a way.
Meanwhile, Todd Raffray has been making sure the Social Module is properly tested. Todd has been doing a great job ensuring all features are documented into a comprehensive checklist and continually tested as they come online.
Congratulations to Miles Lee for transitioning into an official Associate Engineer role with our DevOps team! Miles has done a great job helping to create a framework for test automation. We can now capture performance data and automate the majority of our stability checks for each build as soon as they are available.
The team filmed their first episode of a special QA segment with Community where they showcase some of their favorite bugs.
The team was also fortunate enough to attend the University of Texas Denius-Sams Gaming Academy’s launch party of their first official release called “The Calm Before”. We had a lot of fun playing the game! Their team is very talented. Feel free to check out their free download!
It has been a busy month for us in QA. Next month we will be intently focus testing Alpha 1.2 in preparation for its imminent release.
Game Support This month was quite busy for Game Support as we continued to build upon some of the work done in March and April.
The month of May also saw the publish of two Arena Commander updates (1.1.2 and 1.1.3). Update 1.1.2 greatly helped players with the dreaded Match Not Found, Kicked Back to Lobby, and Infinite Load Screen issues, and 1.1.3 assisted with the persistent “rubber banding” issues that saw players jump around the map. This is only the start of our optimizations, and we know you’ll be excited to see how we continue to use your information to help improve the game experience.
On that note, we also ran an incredibly successful playtest on PTU using 1.1.2. Players crammed into the PTU service to help us stress test and gather important server analytics, and along the way we had an absolutely EPIC 8v8 round of matches, which has set off a round of discussions and assignments internally on what we can do to start increasing the player cap.
In terms of continuing to build and scale our support operations for you, one of the bigger items this month was the creation of an internal workflow and knowledge base that greatly expands our ability to help you. By internally publishing a full matrix of possible problems, troubleshooting methods, and resolutions, we’ve been able to train more people in the company to help with technical issues. This means that we can help a greater number of people in a shorter amount of time, and provides a fantastic foundation for growing our team as we head into Star Marine, Social Module, Squadron 42, and ultimately the Persistent Universe.
We’ve also begun to work with Turbulent who is driving two big initiatives for Game Support: The Community Bug Council (a MUCH improved way for players to submit and see what bugs are active in the system) and a new revamped version of the Live Service Notification page, which will include a much-desired Server Status page.
You’ll see more about both of these in the coming weeks, but both of these are alignment with our larger goals of getting you more accurate information as quickly as possible about the state of the service.
IT/Operations May has been a month of speed for IT. The IT group works hard to keep up with the expanding infrastructure needs of the development teams and performance of central storage systems at each studio continues to be one of our priorities. Last month we focused on internal build replication to studios from the build system in Austin. This month we’ve shifted our focus to the performance of the underlying hardware in the Austin build system itself. The goal of this project is to significantly reduce the time it takes to generate builds. Reducing build times speeds up development and internal testing but the entire build pipeline is large and complex so we have been approaching this from several angles.
First on the list has been the performance of the storage the build systems run on. The build system compiles code and assets for the game of course and most of this work really pushes the disks hard. I/O wait times can go through the roof on normal systems and since our build system is compiling many builds in parallel we saw a great deal of time being lost just waiting for disks to catch up. To solve this problem we built a custom server with all flash storage using special controllers to push our IOPS well beyond our current needs. This one improvement to our build system has shown impressive results with a 66% reduction in build times.
Next we plan to move more secondary systems over to fast storage which should result in additional reductions. Finally, we’ll incorporate parallel processing methods to bring more cpu cores in to the build process. This step plus some potential resource caching should bring our build times down from hours to minutes.
We’ve also been working closely with DevOps to improve our build automation systems which will add stability and usability to our current system. We’re hoping to roll out the rest of these changes over the next few weeks. For now, we’re very pleased with the early results and I think everyone is anxious to see how fast we can make these builds go now.
Dev Ops We released two patches this month, Patch 1.1.2 and 1.1.3, and neither were on a Friday! Our team will continue to work with the company to attempt to corral these deployments to Tuesdays as industry standard, and then hopefully, move into a continuous deployment pipeline over the course of a few years which should eliminate the need for downtime (a lot of this will depend on our final database design).
We have been assisting in the deployment playtests of the FPS and using those opportunities to test our new launcher and patcher. So far the tests have been positive, but we have several more polish passes to go through before we move it to PTU for everyone to use. The Launcher development will be broken into three phases. The first, a PTU phase has already been mentioned. This takes the existing UI and combines it with our new patcher. The second phase will incorporate a complete re-write of the launcher into C++. Combined with the new patcher and the old UI, it will have stability improvements but will look and function much like the current launcher, and the upcoming PTU launcher. The third phase will be a complete new UI on top of the C++ core and patcher. These phases will take several months to roll out, and more information about each will be coming up soon.
Finally, a ton of work has been going on how data in the company is created, stored, and consumed. We are looking at how we use branches in Perforce, how data is copied to the build server, what data is excluded, how development leads look at that data. Initiatives on better Perforce tools, an Exclusion tool, and a new build server have been additionally occupying the teams time. The build server is an especially large project, that we are aiming to have the core phase done by July 14th. To that end, one of the engineers in the Frankfurt studio has flown out to Austin to work with us over the next three weeks so we can collaborate on implementation ideas.
Work on finalizing our database model and containerizing the servers has had to be put on hold while we finish our tools that handle all the data used by the studios. We will be returning to these topics when our tools currently in development are finished, and when our server team moves onto working on the Persistence Service that will be the main interface layer to the database. Hopefully, this work will be included in the June report!
Hello everyone! Here at Foundry 42, we’re working on everything from Arena Commander (multicrew) to Squadron 42. Chris Roberts has spent the past month in another part of England, shooting performance capture for Squadron 42… and we’re working closely to make sure that the data generated there turns into cinematics that will blow you away! Here’s the department by department breakdown of what went on in Manchester this month:
Animation Here in the UK we’re still working to support the needs of our designers. Whilst the Directors down at Imaginarium continue to capture the data we need we’re busy providing block out animations for the design and code departments to start prototyping and implementing mechanics.
We’re also working with the various studios globally to streamline the tools we all need to be able to work efficiently and effectively to achieve the goals set out for Squadron42 and beyond. - UK Lead Animator, Uisdean Ross.
Engineering In previous reports we’ve briefly mentioned some of the general game mechanics we’re working on here in the UK. This month we’ve decided to do a little bit more of a break down on a few of them, what they are, and how they’re coming along.
Conversation System: As usual there’s been plenty of work to do on the conversation system this month, the highlights being the fix up of NPC to NPC conversations and the multiplayer aspect of the conversation system getting a first pass in preparation for the social module. The subtitles font has also been improved and work on revamping the player choice UI for branching conversations is underway. For Squadron 42 we now have text-to-speech in place which is highly useful for prototyping conversations as more dialogue gets added to these levels. Work on the animation side of the system is also in progress, with help from the Austin studio, to get the system ready to receive all the lovely motion capture data available to us.
PAW (Personal Arc Welder). This weapon/gadget is something special, because due to its behaviour, could be used for multiple things. We have been focused in both technical and design point of views. Speaking about the technical part, the cutting tech has been improved to use our damage system so now everything is more realistic, in fact now you can see how surfaces are being cut are affected by energy from the PAW. In addition, a complete review about the aim system has been made, allowing us to, for example, activate or deactivate the laser sight, changing its behaviour, etc… Finally, speaking about design and redesign, we have changed different effects like the beam and the dot in the aim system (laser sight) and we have added new ones like the impact effect and other particles.
Looting System. In this case we have been focused in some technical changes. The previous Looting System was based on items, so for us, an entity was a group of items that we could take. But we wanted something more powerful, to not only take items, but place them too, so we decided to use the item port system (the item port system is a very powerful, flexible way of defining how items can be attached to each other). As a result, now we loot an entity, not necessarily a body, and search what kind of ports does it have and we can take items from those ports and place items on them. In summary, we turned a specific system into something more general and powerful.
Hydraulic doors. The hydraulic doors are an extension of a normal automatic door. These now have the option of being “computer controlled” so we can have features where we can lock the door going in either direction. We’ve now added a new security method for players with the correct security privileges being able to lock and unlock doors and refining the lockdown and manual override mechanics. The override mechanic on certain of the doors allows the player to use their PAW to cut out a section and reveal a manual hydraulic pump to open the door by hand. These doors have also been rolled out into the hangers, unifying them to use the same system everywhere.
Medpack: A medpack item has been added for use in the FPS game modes, it’s purpose to help restore the player’s health. When used the player will perform a combat heal, grasping the syringe like item in their hand and injecting it into a port in their armour. Healing in this manner will distribute the recovery equally across all limbs.
Collectibles: Collectibles come in two forms, either items that can be picked up in much the same way as the looting mechanic, or items scanned for information, both of which get added to your inventory. Examples of which can be pieces of tech that can be scavenged for a monetary value, or dog tags that can unlock character profiles. These items can be found scattered around various areas in Squadron 42.
Graphics This month the graphics team have been primarily working on several different areas in parallel. We’re close to completing an automated system for the artists that intelligently finds meshes it can merge together in the environment to improve performance. Because large parts of our level are built from modular kits (so that we can produce the quantity needed for the PU) we end up with more meshes than CryEngine, DirectX and the graphics driver can handle. Merging meshes reduces the overall number of objects in the level but doing so naively would cause a single level to take several gigabytes of RAM, and so our algorithm evaluates all potential merges operations we could take, and only executes the one that would save us the most performance for the lowest memory cost. The algorithm continues to merge the best candidates until it reaches a fixed memory budget or performance threshold specified by the artist. The end result is a massive saving in the number of objects and therefore performance, all for a minimal memory cost and no extra effort from the artist.
The VFX team have been hampered by various limitations and bugs in the particle lighting system in recent months, and so some of our team have been busy improving the particle lighting system and this should result in the VFX artists being able to create effects that sit much better in the environment. The rest of our team have been handling the many bugs we get prior to each release, and this time it’s FPS related bugs relating to performance, streaming and depth of field improvements. We’ve also been fitting in some fixes to the ‘large world’ rendering which will allow the CryEngine to work with practically unlimited map sizes.
Design This month UK design have been continuing their work on several chapters of Squadron 42 getting them closer to greybox. The main priority for the team right now is the mocap shoot currently taking place in London. Each designer has been able to witness the amazing performances of our cast play out in their own levels which, even at a whitebox stage, look incredible and bring the world we’re building to life that much more!
The internal Vertical Slice is also undergoing massive progress, helping us answer key questions about our core gameplay mechanics and develop our features for experiential, dogfighting and FPS scenarios.
On top of all this, the UK design team are also assisting in all the other areas of Star Citizen, as you have no doubt seen, with Arena Commander, weapons, ships and the upcoming FPS module keeping us all busy!
Art Well, what can I say, for those who dared to looked at the leaked content you can certainly see we are putting your hard earned dollars to good use to make the best content we can! If you were good and are saving yourself, well good on you! We’ll certainly deliver you something worthwhile for your prolonged abstinence.
Every month is busy here, there’s not a minute that’s not packed with decision making or poly or pixel pushing, ship concept work is starting to reduce, its mainly the odd image here and there to clarify any areas we have missed earlier on, Vanduul fleet all concepted out with just the weapons/turrets to be worked out. We’ve had some good work done by Jan Urschel and AtomHawk on environments too which is really helping shape the Sq42 storyline.
Environments Our main focus for this last month has been pushing ahead with our Vertical Slice level, and supporting the shoot happening in London. For the VS we have been striving to achieve a level of detail which is fitting for Star Citizen, particular focus has been placed on player traversal through the scene, rewarding exploration, great vistas and composition, and of course top quality artwork. For the shoot we’ve been making sure that scenes in which performances are being captured in are working correctly on set, and making these ever important last minute tweaks and changes. Excitement is high both on set and in the studio, we can’t wait to show it to you guys.
VFX We’ve had a full month of code support from the graphics engineers, who have cleared out an impressive backlog of bugs and feature requests. We’ve also gained another VFX Artist, so the team is growing! This has enabled us to push forwards in several areas, including:
Squadron 42 environmental VFX variants, namely:
Sparks
Steam
Fire/damage
Space storms (be careful, it’s dangerous out there!)
R&D for large turret VFX – muzzle flash, tracers, impacts etc.
R&D for Squadron 42 cinematics, testing typical workflows and pipelines.
Various ship effects.
On a slightly less exciting note (but important nonetheless) we’ve also been working hard behind the scenes to solidify our workflows and pipelines, and fleshing out the VFX roadmap, to allow us to keep well on top of the multitude off effects requirements across all areas of the Star Citizen universe!
Ships Oh the ships, the ships – always keeping our top artists on their toes – the Idris, yes, its coming along nicely, maybe even a few surprises (i know you love them/hate them), there has been a lot of work to tie the ships design language into a coherent form so that further down the line it’s clear what manufacturer does what, has what style of panel lines, what kind of lights, the list is large but at least it will be clear for internal and external artists on what they need to achieve.
Starfarer interior blocked out, ARGO needs a shader pass, Mining Drone continues, yes, the Jav hasn’t been started, we are at maximum capacity until we find more staff – c’mon join us and make the BDSSE :)
UI The team has expanded a 100% – we have gone from one to two artists! Work has continued on FPS UI and now exploring the style and look for Shubin, Aegis and Vanduul – watch this space.
Characters The character team has been on site in London alongside the Imaginarium shoot with the camera rig and we have had an absolute blast! Every scan session has been fun and exciting and we have managed to capture some truly world leading data on some truly world class talent. They say you should never meet your heroes, but I completely disagree and every one of them have been friendly, professional and enthusiastic.
The data has already begun to be processed and some of you may have already seen some of the action from our scan session with Sandi, which is a good example of the energy and drive we have on this project.
I only wish I could tell you who has sat in our rig!
Audio Hey everyone! On the CIG Audio side we’ve mostly been continuing with our push towards releasing with Wwise. Still a lot of core stuff to do but we’re making progress.
I think it’s fair to say we’re finding a lot of clean-up work has been required as far as engineering is concerned. We’d (perhaps optimistically) figured that most systems would simply need Wwise events created, that triggered in much the same way as their equivalents in FMOD, and away we go, all done! However that’s rarely been the case and the more you dig, the more you find that needs doing.
So it’s been as much a matter of taking stock, cleaning up, removing loose ends in terms of sound data, code and logic, as it has been making sure Wwise events and sounds simply exist. There are certain things that worked under FMOD that kind of worked, but more in spite of things rather than by design. This isn’t down to the fault of anyone particularly, just that often audio has been reacting to project changes late in the day as the game has developed.
So as much as possible we’ve been taking the opportunity to ensure this move over to Wwise is a shift from short-term, reactive thinking and design, and moving more towards how we aspire to approach things – getting ahead of the game (literally) as much as we can: coming up with templates in Wwise for instance, keeping everything clean and hack free. We’ve brought our code team together again as well as our Austin-based tech sound design so we can bump heads most effectively in the run up to FPS. Having to engineer that new system as well as bring on the dog-fighting module back up to speed and support various aspects of the persistent universe – those things would be hard enough to do without the new audio engine to worry about. But we mustn’t grumble too much!
Sadly one of our senior sound designers, Tom, left us this month. He’s missed, as he had a wealth of experience in CryEngine particularly, but he was presented with an opportunity to move closer to loved ones and it’s hard to argue with that. So he leaves on good terms – we wish him all the best in his future efforts, he won’t be easily replaced.
In other news, we have our newly built sound design rooms, mostly ready to be occupied. We still need to apply our acoustic treatment properly to the walls, and we’re waiting on some furniture and monitors (monitors is what audio people call speakers, just to confuse everyone) to arrive, but it’s nice to see these rooms coming together. We’ve tried to give each of them their own colour scheme which will either cause creative sparks, or mild insanity. Depends on the room really. Maybe we’ll witness a little of both! They’ll need some tweaking and tuning to try to ensure sonic neutrality. They’re admittedly a little small, which makes it hard to ensure they’re free of standing waves etc. that can misrepresent certain bands of the audio spectrum. We’ll get as close as we practically can, but will just take a bit of time to get to where they need to be.
We’ve been trying to fit in time to experiment with processes pertaining to alien vocals, which we’ve started looking at while the linguists keep pinning down the alien language aspect. It’s always a tricky area but it’s proving very interesting to see what you can do before you get into the aural equivalent of the uncanny valley.
As well as the above we’ve been on-hand to support the ongoing shoot for ‘Squadron 42’, which obviously I’m going to say nothing about, so don’t ask me. ;)
Thanks for taking the time to catch up on all things CIG Audio. Please do post a question or two on the Ask A Developer forum and we’ll do our best to answer. Bye for now!
The Frankfurt team is steadily growing in size and active across numerous disciplines, base tech, AI, design, cinematics, Audio, Animation, FX, etc. As seen in our office video last month our temp space was filling up, we rented out an another room to accommodate additional hires. We’ve also been preparing to move into our new office, the official move will be in early July, and we’ll most likely put out a new video once we get settled in. We’ve only been part of the global team for a few months now, but the momentum and progress across the game from all studios and offices is great to see, and we’re glad to be part of it.
Engineering For the month of May, Frankfurt Engineering has been busy on multiple fronts. We made a lot of progress on Large World (moving the codebase to 64 bit coordinates, thus allowing galaxy size (literally) levels to be created and explored in Star Citizen) . The main task being worked on Large World this month was making the rendering Camera Relative: in fact the move to 64 bit required all rendering code to be changed to be relative to the camera and not simply in absolute world coordinates any more.
There has also been lots of progress on the Zone System, which is our new spatial partitioning system, replacing the old CryEngine octree spatial partitioning scheme. The Zone system is especially fit for a game like Star Citizen which features large, dynamic maps, huge amount of entities and large moving ships. Speaking of multicrew ships, we have also been working on ship-local physics grids (so players can walk around in moving ships), runtime prefabs, and investigating entity optimizations and streaming. We are initially testing those new systems with the Retaliator.
We also started implementing optimized asset storage formats for vertex data to reduce overall data size, improve lead-time and memory, as well as CPU/GPU performance. These optimizations will be rolled out shortly.
We’ve started some initial R&D discussion on the topic of procedural generation, which will get some dedicated time later down the line, after the big ticket items mentioned earlier are all in place. There has been a lot of clean-up of outdated CryEngine functionalities that we don’t need any more for Star Citizen, like the old level heap, obsolete render nodes, and many other smaller items. Additionally we have been working on integrating the relevant parts of the new 3.7 SDK into our codebase. All those major tasks are now close to hit the Star Citizen code mainline. Additionally, we have been providing general engine support, features and engine bug fixes.
We’ve also updated our memory profiling tools, removing related old cruft from the entire engine code.
AI In the last month we’ve put a solid basis for all the future development related to the Artificial Intelligence in Star Citizen.
We started unifying CryEngine Communication System with the CIG Contextual Reaction System. What are those two systems?
The Communication System is used to allow AI characters to speak: the behaviour (or other system) can request to play a specific communication line (for example “GreetThePlayerInFronOfYou”) and the system is going to take care of and choose an appropriate variation for that concept (for example “Greetings my friend!”) and it’s going to check if the defined pacing is actually allowing the audio to play. The system is also responsible to correctly handle a case in which a communication line playing on a high priority channel needs to cancel the current message if it’s playing on a lower priority channel.
The classic example is the NPC being punched or shot while he is speaking. His scream of pain should definitely interrupt anything he was previously saying! The Contextual Reaction System is used to trigger a communication line based on specific events triggered by the game. A ship that is heavily damaged may broadcast a “ShipsDamaged” signal that is picked up by the CRS and it will choose a proper variation of that audio that must be played. CRS is already fully integrated into Dataforge so the writers are able to create new content without the need of code support. During this month we have started the merging of the new systems to take the benefit of both!
We also started working on the CryEngine Cover Surface System to connect it to the Kythera behavior system and to allow the support of large world. The Cover Surface System is able to sample a physical object and automatically create data to store cover positions.
Moreover we have laid down the basis to extend the CryEngine MNM Navigation system to support large world and local navigation meshes. We have started prototyping the functionality to have a navigation mesh attached to a moving spaceship, so that we will be able in the next months to have the ship’s crew members navigating in the internal spacecraft environment.
We also focused in coordinating the work of Moon Collider related to few improvements of the Kythera Behavior Tree system. The BTS is now connected to DataForge to allow system/game designers to create/prototype fast new behaviors without the need of writing C++ code. Also new behavior nodes have been introduced to support basic functionalities as state machines, timestamps and signals. All those functionalities will empower us to implement more complex and interesting behaviors.
In general we are planning lots of new features and we will prepare some cool videos/pictures to show more details about our progress next month!
Design On the design side, we’ve been working closely with the UK team and taking ownership of a level for Squadron 42. We’re active in every aspect of Star Citizen’s development, from working on the FPS module release to developing high level AI behavior tree feedback that will span all of our game areas. Other challenges include building and setting up turret gameplay, providing the UK with high level Squadron 42 feedback and working on unifying FPS suit customization to make it work more like we currently do with the ships.
Cinematics A few members of the team have been on set in London for the full month with Chris Roberts shooting scenes for Squadron 42. The cast is amazing and we can’t wait to announce who we have and show off their performances. We’re ramping up the cinematics team and starting to get more traction on the internal pipeline and workflow.
Audio Our Audio Engineer has spent the full month in the UK working with their Audio Team to get the Audio up and running on Wwise for the next release.
Continued work on converting old FMOD based code features to use the new Audio System. Spent some time helping develop the asset conversion scripts to automate the more straightforward parts of the process, so that the sound designers can focus on tuning the sounds and the way they are triggered in game, instead of having to worry about porting the current implementations. Rolled out the set of new audio asset pipeline tools to be used by the sound designers and the build servers to simplify and speed up the day-to-day audio asset production.
FX For the past month we’ve been focused mainly on researching various types of fire to include in the game. These range from small fires and debris, to towering flames and huge explosions. Smoke is also an important part and getting them to blend together in a realistic way has been one of the focuses for the current R&D cycle.
We’ve also done some work on lightning for some of the squadron 42 missions, which will mainly be used as a long distance background effects.
Good morning citizens! …or Good evening pirates? …what time is it in space anyways!? Post the correct answer in the comments to win a thumbs up.
Because it takes more than a month to create anything of importance in a game as huge and detailed as Star Citizen you might find that this month’s report is similar to last month’s report but described with different words :) Nevertheless, that does NOT mean that the month was devoid of progress, far from it! Here’s the monthly report for the BHVR team:
First off, a lot of our efforts went towards polishing, debugging, as well as supporting other studios on various game modules. As we are approaching the FPS module release and the social module delivery (prepare your excitement bags!) the time is not so much spent on adding new features, but rather on polishing and consolidating what is already in there.
Here are the most notable modules, systems, systemic modules and modular systems that have been debugged, polished and/or supported this month:
The in-game chat
The emote system: /dance /dothebender
The FPS Module
The Lobby: Multi-Seat
The Lobby: FPS Loadout
Let’s talk about the social module a bit. We’ve added more functionality to the chat system in order to make it easier and more fun to use. We’ve implemented the first version of filtered conversation tabs which allows you to have multiple conversations either private or public in an understandable and ordered manner. We’ve iterated on the interface and its experience taking it to a lock-down state for this first iteration.
We also spent some time fixing interactive items such as flairs, the holotable and doors on the client & server sides. This is obviously pertinent for every in-game location, not just the hangars.
Engineers have been debugging the replication and instantiation of the hangars while level designers have been fixing all sorts of problems inside them. I don’t know what you are doing in those hangars guys, but they seem to break all the time! Please stop smashing your buggies all over the place. ;)
The creation of the base spawning module is complete which, believe it or not, handles spawning of multiple players simultaneously in hangars & planetside locations. With it we can spawn you (well not you, but your character) at the proper position, depending on where you’re coming from (Hangar -> Planetside, Space -> Planetside, etc). Didn’t think loading and spawning could be that interesting but we’re excited to see the videos you’ll post about your first time spawning planetside.
Okay now let’s get to the fun bit: planets! This month in the Art department we’ve completed all the set pieces for an industrial mining planet. The plan is to use this set across the galaxy, primarily but not exclusively for Delamar in the NYX system. Our main goal is to make the set pieces as versatile as possible to enable any art team on this project to create different locations. This took quite a large amount of time to complete, but we are very happy with the end result.
We’ve also started work on legacy objects to make them comply with the new visual and technical standards. As we make more locations we update our techniques and since these “old” pieces will be of use in the future, we need to make sure they are compliant.
Our level Designers are exploring and refining other locations like the blocks on Terra Prime, Marianna and Odyssa as well as creating new interior locations and polishing/supporting older locations. A bit like the legacy pieces in art, some interactive objects also changed and needed to be update to be on par.
The mobiGlas has seen lots of polish and progress. We’ve implemented animations to make it extra slick. Some refinements and updates have been made on the shopping flow as well. We can now display your UEC balance and you’ll also be able to buy stuff and things for real!
In the same vein, we did a first pass implementation on the UI, code and visuals of the microTech Kiosk. “What the Hull is that?” you may ask. Well, some shops and other locations around the verse have microTech kiosks which are used to show holographic representations of extra large products that don’t fit the location. Kiosks are also used to get access to an inventory catalog with the help of the mobiGlas. The mobiGlas is also a microTech product, so now you see the connection. Our first kiosk will be used in Astro-Armada, where it can be interacted with to browse and buy ships.
The kiosks are part of the first phase of the ship shopping experience. We’re planning on more immersive and interesting ways to shop ships for the future that were impossible to deliver right away.
Another interesting object we are working on is the personal locker. Don’t be fooled, this has nothing to do with flairs. The personal locker can be found in your hangar and is where you will store your FPS gadgets and weapons. Later on down the road, this locker will be used to not only display weapons but to prepare loadouts in order to quickly change your character’s equipment for the right job.
As always, we’ve completed this month’s Flair object along with other secret merchandise work, which we won’t spoil the surprise, because spoiling surprises is not fun at all.
Thank you for your attention! Now go destroy some ships will ya!
Greetings Star Citizens! I’m sure most of you saw the massive post concerning Star Marine, and the reason why it’s taking a little longer than expected. Thank you for bearing with us! Most of May was spent executing on the items listed in that post. See below for the details from each team.
Engineering In addition to squashing lots of bugs, the engineering team has been focused on supporting the animators with the new jukes, starts and stops system. There are unique animations for each direction shift to another, and also for each state and speed the player is traveling at. This can add up very quickly! Work has also continued to zero-g movement and SATA Ball features. After playtesting SATA Ball, we realized that there would need to be some specific cases to help with managing the ball in such a large space.
Design The designers have been hard at work getting SATA Ball up and running. This mostly involves working on playabilty and visual cues to the player for what’s happening. Making sure the players can easily find the ball, making sure the players can easily grab and throw the ball with accuracy, and making sure they can navigate to it effectively. They have also been doing lots of testing with the base set of weapons and tweaking how breathing plays into accuracy.
Animation The animation team is currently focused on getting all of the jukes, starts and stop mocap data cleaned up and ready for implementation in game. As mentioned above, it is A LOT of mocap data, so they have their plates pretty full.
Art The art team has been focused on two primary goals over the last month. One is reworking the assets for the gold horizon station to be compliant with how things are setup for the persistent universe. This will allow teams across all studios to use this set in their various levels. Sharing is caring!
The second goal for the art team has been polishing the existing weapons and creating a unified rail system for attachments. This will make creating attachments much easier moving forward, since everything will be universal.
VFX Some new VFX were created for SATA Ball, effects for the goals so players don’t get confused and also some effects on the player for when they are shot and disabled. A polish pass was also done on all existing effects with feedback from Chris. Thanks for reading Citizens! Illfonic Out!
Here’s what we’ve been up to here in Montreal for the month of May :
Starmap Outstanding progress was made this month in the actual art for the web star map module. We now have full artistic designs for the top-level Galactic Level view where all star systems are laid out, showing their Jump Point connections. The main challenge here was to find a way to represent the jump points that was stylistically beautiful but also functional to represent the wormhole sizes and directions where applicable. Great progress was done in a 2D HeatGrid type display to show (at any level) the political influence, crime and economic levels of areas of the galaxy. Though this is still experimental ; the visuals proposed by our artists inspired expanding this feature.
One major UI component included in this art pass is the control disc ; which is a very interesting design because we think it could also be used as an in-game component. This disc is how you will be able to interact with the different items you see on-screen while browsing the galaxy. Our mock-up set from the artists also includes the “Space Object Overview” screen which is basically what happens when you request more information of an object, be it a planet, asteroid belt, nebula or wormhole. This general purpose view will serve as the primary display for information on anything from within the starmap as well as the jump to the Galactapedia entries for each of them.
Design of the Starmap is now at a state where it can be intertwined with actual plans for the Starmap in the game, which is why we’ve also designed our interface to be unified with the game controls and experience.
Community Hub We completed the interfaces mock-ups for this new section this month, merging its design with the new website look, and attaching it to actual data-driven views. We’ve spent a lot of time making sure that we could feature as much content from the fans as possible : images and galleries, but also videos from varied providers, streaming channels, podcasts… The Hub is still in intense development, we’ll be able to show more soon.
Issue council The Issue Council, our new “crowdsourced” bug report system, went through a month of heads-down coding. The core of the system has been completed including data models and system level API. Meanwhile, the design crew has been working through the motions on the actual UI. We gave a demo to the QA team in Austin and everyone is excited to start using it. In June we’ll be testing it by actually entering bugs about itself in it!
Launcher This month we completed a prototype rework of the Star Citizen launcher in conjunction with the DevOps crew in Austin. The new launcher is just internal for now, only for CIG testing, and is based on BitTorrent technology. This allows the patching process to be more efficient in size and speed, and is a first step towards a web-driven launcher which will in turn lead to having more configuration tools directly in the launcher (hangar configuration, future inventory, REC activation…).
Chat The Chat system has seen some improvements this month also. We’ve revamped its look to bring it closer to the rest of the site, and we’ve introduced “sticky” room subjects for better legibility.
And more! This month also came with its own content slew updates on the site. We actually saw 2 concept sales with both the Starfarer Gemini and the new MISC Reliant mini-hauler, and we also brought you the Montreal-produced minigame Hyper Vanguard Force IV by Dave Richard and Christine Marsh. Apex Predators unite!
On a more silent note, we’ve also implemented the new Amazon “Login And Pay” payment system for north-american users.
Having done lots of planning and design work over the last few months, May was light on these for a change, so we got the chance to really get stuck into some cool engineering work. There were several big designer tool features that we worked on, and we’re looking forward to seeing them get put to use.
Engineering Last month we spoke about the fancy spline joining improvements that we were working on. This is a feature that enables designers to specify a spline that they want a ship to fly along (in order to do some fancy maneuvers or fly really close to obstacles that the AI would otherwise keep a distance from), and the AI will figure out an optimal path to get on to the spline as quickly as possible. To do this the AI needs to figure out a path from its current position and direction to the start of the spline and to end up facing down the direction of the spline path once it gets there. This can then get more complicated because designers can specify the speed that they want the ship to be moving when it starts the spline, so this can affect the path that the ship takes, since it might need to curve the path a bit to add some extra run up if it needs to get up to speed or slow down by a lot. And, of course, we want all this to look fairly natural as well.
We finished the feature off this month and got it to the designers to make use of. Now that ships can reliably join splines from anywhere, it makes designer setup easier, but more importantly for you, it will let us use them far more in systemic behaviours. So far we’ve had to be quite restrictive about when ships choose to join a spline, but this gives them far more freedom so – when we’ve adjusted the behaviors – you’ll see them used much more in future versions of Arena Commander.
The biggest feature we worked on this month was a complete change to the way we author AI behavior trees. Up to now, we’ve been authoring them directly in code. Using Kythera’s runtime C++ recompilation, this was actually quite efficient and allowed for fast iteration while running the game, but was not accessible to designers without a programming background. So we did a lot of work to allow behavior trees to be authored inside DataForge.
You will have heard a lot of mention of DataForge in the past, as the custom data management tool used by designers for all kinds of different data in Star Citizen. It has been engineered from the start to allow different views for different types of data, so where applicable, you might edit data in a spreadsheet style format, while for other things, a graphical node editing view is more appropriate, and so on.
We now have a behavior tree data category in DataForge that allows designers to create and edit behavior trees using a friendly GUI interface, and then apply these behaviors directly to an AI character without having to write any code. Plus they can modify the behavior trees at runtime and see the results immediately, which is fantastic for fast iteration.
What made this a particularly interesting feature for us, though, is that we expect new behavior tree nodes to be created regularly in the future, and we wanted to support adding them into DataForge as easily as possible, so we did some work to create a simple console command in the editor that will automatically generate new definitions for DataForge, plus new C++ binding code that connects DataForge behavior tree structures with the underlying Kythera behavior tree code. So when a coder creates a new node, it’s just a quick console command and the node is now fully integrated into DataForge!
So it’s still possible to create AI behaviors in C++ just like before, but now we have this alternative GUI creation method, which then gets translated into equivalent C++ code when the behavior runs. We’re excited to see the designers start to work with the new tool and create great behaviors. We expect to have to make small improvements in the near future to make the interface even easier for designers, but we think it’s off to a great start. And we definitely have to give a huge shout-out to Ash Canning at Foundry 42, the mastermind behind DataForge who did lots of tweaks for us on really short notice to help DataForge support editing behavior trees better.
Finally, we did some work inside our Kythera Inspector debugging tool to enable designers to debug their behavior trees a lot more easily, by getting a live visual representation of what the tree is currently doing at any time. Last month we added the ability to record and playback behavior trees states, but that’s more useful for tracking down bugs. For developing behavior trees a live view of what they’re doing is really handy. We’re putting the final touches on this feature and will be getting it out to designers soon, so we’ll wait for next month’s report to go into more detail about it.
Ladies and gentleman, boys and girls, citizens of all ages, Thomas, cinematographer and editor extraordinaire, here to bring you the monthly report for May. Reporting as always from what can only be described as heaven on earth, aka the simply sublime paradisiac known as Santa Monica, California.
And just like our splendid locale, May was a positively stupendous month for us. We debuted a new segment on our flagship show, Around the Verse, dubbed Ship Shape. Hosted by the effervescently and always alluring Lisa Ohanian, it affords us the opportunity to share with our fans and backers a compendious glimpse into the Ship Pipeline.
Speaking of Around the Verse, Ben Lesnick did a fantastic job hosting solo while co-host Sandi Gardiner was called upon to exhibit her thespianic skills at the Squadron 42 motion capture shoot in London, and we were treated to an array of talented developers all proving to be distinguished facsimiles, in our illustrious Chairman’s absence, on our weekly 10 for series.
May also saw everybody’s favorite Bugsmasher, Mr. Mark Bartholomew Abent III making the leap from Around the Verse sub segment to bi-weekly standalone show. His pilot episode was met with rave reviews, and it is with grand exuberance that I am pleased to announce that the network has indeed placed an order for a full season of shows.
On a completely unrelated note, May also begat us the much anticipated and long awaited grand opening of Fuddruckers Santa Monica, and the CommuniTeam wasted no time in visiting it for lunch, and I will just say this, we were not disappointed.
And that, my fellow citizens, was the month of May. Thank you to all of our fans, without you, none of this would be possible, and it is truly an honor and a privilege to be able to do what we do.
Until next time, I will always and forever be,
Your humble servant,
Thomas