Monthly Studio Report: May 2015
Undefined Undefined Monthly ReportsContent
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
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
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
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
us reports haben wir kurz einige der allgemeinen Spielmechaniken erwähnt, an denen wir hier in Großbritannien arbeiten. Diesen Monat haben wir beschlossen, ein wenig mehr über einige von ihnen zu erfahren, was sie sind und wie sie vorgehen.
Konversationssystem: Wie üblich gab es in diesem Monat viel Arbeit am Konversationssystem zu erledigen, wobei die Highlights die Korrektur von NPC-zu-NPC-Gesprächen und der Multiplayer-Aspekt des Konversationssystems waren, der einen ersten Durchgang zur Vorbereitung auf das Sozialmodul erhielt. Auch die Schriftart der Untertitel wurde verbessert, und es wird an einer Überarbeitung der Benutzeroberfläche der Player-Auswahl für verzweigte Gespräche gearbeitet. Für die Staffel 42 haben wir jetzt Text-to-Speech im Einsatz, was sehr nützlich für das Prototyping von Gesprächen ist, da mehr Dialog zu diesen Ebenen hinzugefügt wird. Die Arbeiten an der Animationsseite des Systems sind ebenfalls im Gange, mit Hilfe des Austin-Studios, um das System bereit zu machen, alle schönen Bewegungsdaten zu empfangen, die uns zur Verfügung stehen.
PAW (Personal Arc Welder). Diese Waffe/Gerät ist etwas Besonderes, denn aufgrund ihres Verhaltens kann sie für mehrere Dinge verwendet werden. Wir haben uns sowohl in technischer als auch in gestalterischer Hinsicht konzentriert. Was den technischen Teil betrifft, so wurde die Schneidtechnologie verbessert, um unser Schadenssystem zu nutzen, so dass jetzt alles realistischer ist, und zwar jetzt kann man sehen, wie Oberflächen durch die Energie der PAW beeinflusst werden. Darüber hinaus wurde eine vollständige Überprüfung des Zielsystems durchgeführt, die es uns ermöglicht, z.B. das Laservisier zu aktivieren oder zu deaktivieren, sein Verhalten zu ändern, etc.... Schließlich, wenn wir über Design und Neugestaltung sprechen, haben wir verschiedene Effekte wie den Strahl und den Punkt im Zielsystem (Laservisier) geändert und wir haben neue hinzugefügt, wie den Aufpralleffekt und andere Partikel.
Plünderungssystem. In diesem Fall haben wir uns auf einige technische Änderungen konzentriert. Das vorherige Plünderungssystem basierte auf Gegenständen, so dass für uns eine Entität eine Gruppe von Gegenständen war, die wir nehmen konnten. Aber wir wollten etwas Stärkeres, um Gegenstände nicht nur zu nehmen, sondern auch zu platzieren, also haben wir uns für das Item-Port-System entschieden (das Item-Port-System ist eine sehr leistungsfähige, flexible Methode, um zu definieren, wie Gegenstände aneinander befestigt werden können). Infolgedessen plündern wir jetzt eine Entität, nicht unbedingt einen Körper, und suchen, welche Art von Ports sie hat, und wir können Elemente aus diesen Ports nehmen und Elemente darauf platzieren. Zusammenfassend lässt sich sagen, dass wir ein bestimmtes System in etwas Allgemeineres und Mächtigeres verwandelt haben.
Hydraulische Türen. Die hydraulischen Türen sind eine Erweiterung einer normalen automatischen Tür. Diese haben jetzt die Möglichkeit, "computergesteuert" zu sein, so dass wir Funktionen haben, bei denen wir die Tür in beide Richtungen verriegeln können. Wir haben nun eine neue Sicherheitsmethode für Spieler mit den richtigen Sicherheitsprivilegien hinzugefügt, die in der Lage sind, Türen zu verriegeln und zu entriegeln und die Mechanik der Verriegelung und manuellen Übersteuerung zu verfeinern. Die Überbrückungsmechanik an einigen Türen ermöglicht es dem Spieler, mit seiner PAW einen Abschnitt auszuschneiden und eine manuelle Hydraulikpumpe zum Öffnen der Tür von Hand zu entdecken. Diese Türen wurden auch in die Kleiderbügel gerollt, um sie so zu vereinen, dass sie überall das gleiche System verwenden.
Medpack: Ein Medpack-Element wurde für die Verwendung in den FPS-Spielmodi hinzugefügt, um die Gesundheit des Spielers wiederherzustellen. Bei Verwendung führt der Spieler eine Kampfheilung durch, indem er die Spritze wie einen Gegenstand in der Hand greift und sie in einen Port in seiner Rüstung spritzt. Eine solche Heilung verteilt die Erholung gleichmäßig auf alle Gliedmaßen.
Sammlerstücke: Sammlerstücke gibt es in zwei Formen, entweder Gegenstände, die auf die gleiche Weise wie der Plünderer aufgenommen werden können, oder Gegenstände, die nach Informationen gescannt werden, die beide zu deinem Inventar hinzugefügt werden. Beispiele dafür können Technikelemente sein, die nach einem Geldwert durchsucht werden können, oder Dog Tags, die Charakterprofile freischalten können. Diese Gegenstände befinden sich verstreut in verschiedenen Bereichen der Staffel 42.
Grafiken
In diesem Monat hat das Grafikteam vor allem an mehreren verschiedenen Bereichen parallel gearbeitet. Wir sind kurz davor, ein automatisiertes System für die Künstler zu entwickeln, das intelligent Netze findet, die in der Umgebung zusammengefügt werden können, um die Leistung zu verbessern. Da große Teile unseres Levels aus modularen Kits bestehen (damit wir die für das PU benötigte Menge produzieren können), haben wir am Ende mehr Meshes, als CryEngine, DirectX und der Grafiktreiber verarbeiten können. Das Zusammenführen von Netzen reduziert die Gesamtzahl der Objekte in der Ebene, würde aber dazu führen, dass eine einzige Ebene mehrere Gigabyte RAM benötigt, und so wertet unser Algorithmus alle möglichen Zusammenführungsoperationen aus, die wir durchführen könnten, und führt nur diejenige aus, die uns die meiste Leistung bei geringsten Speicherkosten ersparen würde. Der Algorithmus führt die besten Kandidaten weiter zusammen, bis er ein vom Künstler festgelegtes Speicherbudget oder eine vom Künstler festgelegte Leistungsgrenze erreicht. Das Endergebnis ist eine massive Einsparung der Anzahl der Objekte und damit der Leistung, bei minimalen Speicherkosten und ohne zusätzlichen Aufwand für den Künstler.
Das VFX-Team wurde in den letzten Monaten durch verschiedene Einschränkungen und Fehler in der Partikelbeleuchtung behindert, und so waren einige unserer Mitarbeiter damit beschäftigt, die Partikelbeleuchtung zu verbessern, was dazu führen sollte, dass die VFX-Künstler in der Lage sein sollten, Effekte zu erzeugen, die viel besser in der Umgebung sitzen. Der Rest unseres Teams hat die vielen Fehler, die wir vor jeder Veröffentlichung erhalten haben, bearbeitet, und diesmal sind es FPS-bezogene Fehler in Bezug auf Leistung, Streaming und Feldverbesserungen. Wir haben auch einige Korrekturen für das Rendering der "großen Welt" vorgenommen, die es der CryEngine ermöglichen, mit praktisch unbegrenzten Kartengrößen zu arbeiten.
Design
In diesem Monat hat das britische Design seine Arbeit an mehreren Kapiteln der Staffel 42 fortgesetzt, um sie der Greybox näher zu bringen. Die Hauptpriorität des Teams liegt derzeit auf dem Mocap-Shooting, das derzeit in London stattfindet. Jeder Designer konnte die erstaunlichen Leistungen unserer Darsteller in ihren eigenen Levels erleben, die selbst auf einer Whitebox-Bühne unglaublich aussehen und die Welt, die wir bauen, noch viel mehr zum Leben erwecken!
Der interne Vertikalschnitt macht ebenfalls große Fortschritte und hilft uns, wichtige Fragen zu unseren Kern-Gameplay-Mechanismen zu beantworten und unsere Funktionen für Erfahrungs-, Nahkampf- und FPS-Szenarien zu entwickeln.
Darüber hinaus unterstützt das britische Designteam auch alle anderen Bereiche von Star Citizen, wie Sie sicherlich gesehen haben, mit Arena Commander, Waffen, Schiffen und dem kommenden FPS-Modul, das uns alle beschäftigt!
Kunst
Nun, was soll ich sagen, für diejenigen, die es gewagt haben, sich die durchgesickerten Inhalte anzusehen, können Sie sicherlich sehen, dass wir Ihre hart verdienten Dollar sinnvoll einsetzen, um den besten Inhalt zu machen, den wir können! Wenn du gut warst und dich selbst rettest, dann sei es gut zu dir! Wir werden dir sicherlich etwas liefern, das sich für deine anhaltende Abstinenz lohnt.
Jeder Monat ist hier sehr arbeitsreich, es gibt keine Minute, die nicht voller Entscheidungen oder Poly oder Pixel-Push ist, die Schiffskonzeptarbeit beginnt sich zu reduzieren, es ist vor allem das seltsame Bild hier und da, um alle Bereiche zu klären, die wir früher verpasst haben, die Vanduul-Flotte hat alles mit nur den Waffen/Türmen konzipiert, die ausgearbeitet werden müssen. Wir haben von Jan Urschel und AtomHawk gute Arbeit auch in Umgebungen geleistet, was die Sq42-Handlung wirklich mitgestaltet.
Umgebungen
Unser Hauptaugenmerk für diesen letzten Monat lag auf der Weiterentwicklung unseres Vertikalschnittlevels und der Unterstützung des Shooting-Events in London. Für die VS haben wir uns bemüht, einen Detaillierungsgrad zu erreichen, der für Star Citizen geeignet ist. Besonderer Wert wurde auf die Spielerdurchquerung durch die Szene gelegt, lohnende Erkundungen, großartige Ausblicke und Kompositionen und natürlich hochwertige Kunstwerke. Für das Shooting haben wir sichergestellt, dass Szenen, in denen Auftritte festgehalten werden, am Set korrekt funktionieren und diese immer wichtigen Änderungen in letzter Minute vornehmen. Die Spannung ist sowohl am Set als auch im Studio groß, wir können es kaum erwarten, es euch zu zeigen.
VFX
Wir hatten einen ganzen Monat lang Code-Support von den Grafikern, die einen beeindruckenden Rückstand an Bugs und Feature-Anfragen beseitigt haben. Wir haben auch einen weiteren VFX Artist gewonnen, so dass das Team wächst! Dies hat es uns ermöglicht, in mehreren Bereichen voranzukommen, unter anderem:
Squadron 42 Umwelt-VFX-Varianten, nämlich: Funken Dampf Feuer/Schaden Weltraumstürme (Vorsicht, es ist gefährlich da draußen!) F&E für große Turm VFX - Mündungsfeuer, Leuchtspuren, Stöße usw. F&E für die Staffel 42 Kinematiken, die typische Arbeitsabläufe und Pipelines testen. Verschiedene Schiffseffekte. Auf einer etwas weniger spannenden (aber dennoch wichtigen) Seite haben wir auch hinter den Kulissen hart daran gearbeitet, unsere Workflows und Pipelines zu verfestigen und die VFX-Roadmap zu konkretisieren, damit wir die Vielzahl der Off-Effekte in allen Bereichen des Star Citizen-Universums gut im Griff behalten können!
Schiffe
Oh die Schiffe, die Schiffe - immer unsere Top-Künstler auf Trab halten - die Idris, ja, es kommt gut an, vielleicht sogar ein paar Überraschungen (ich weiß, dass du sie liebst), es gab eine Menge Arbeit, um die Designsprache der Schiffe in eine kohärente Form zu bringen, so dass weiter unten in der Linie klar ist, welcher Hersteller was macht, welchen Stil die Panel-Linien haben, welche Art von Leuchten, die Liste ist groß, aber zumindest wird es für interne und externe Künstler klar sein, was sie erreichen müssen.
Starfarer-Innenraum blockiert, ARGO braucht einen Shaderpass, Mining Drone fährt fort, ja, die Jav wurde noch nicht gestartet, wir sind an der maximalen Kapazität, bis wir mehr Personal finden - kommt mit und macht den BDSSE :)
UI
Das Team hat sich um 100% erweitert - wir sind von einem auf zwei Künstler übergegangen! Die Arbeit an der Benutzeroberfläche des FPS wurde fortgesetzt und nun wird der Stil erkundet und nach Shubin, Aegis und Vanduul gesucht - schauen Sie sich diesen Raum an.
Charaktere
Das Charakter-Team war neben dem Imaginarium-Shooting mit dem Kamerarigg vor Ort in London und wir hatten einen absoluten Spaß! Jede Scan-Sitzung hat Spaß gemacht und war spannend, und wir haben es geschafft, einige wirklich weltweit führende Daten über einige wirklich erstklassige Talente zu erfassen. Sie sagen, dass man seine Helden nie treffen sollte, aber ich stimme völlig nicht zu und jeder von ihnen war freundlich, professionell und enthusiastisch.
Die Daten wurden bereits verarbeitet, und einige von Ihnen haben vielleicht bereits einige der Aktionen aus unserer Scan-Sitzung mit Sandi gesehen, was ein gutes Beispiel für die Energie und den Antrieb ist, den wir bei diesem Projekt haben.
Ich wünschte nur, ich könnte dir sagen, wer in unserer Anlage gesessen hat!
Audio
Hey zusammen! Auf der CIG-Audio-Seite haben wir hauptsächlich mit unserem Bestreben, mit Wwise zu veröffentlichen, weitergemacht. Es gibt noch viel zu tun, aber wir machen Fortschritte.
Ich denke, es ist fair zu sagen, dass wir feststellen, dass in Bezug auf das Engineering viele Aufräumarbeiten erforderlich waren. Wir dachten (vielleicht optimistisch), dass die meisten Systeme einfach nur Wwise Events erzeugen müssten, die auf die gleiche Weise ausgelöst wurden wie ihre Äquivalente in FMOD, und los geht's, alles erledigt! Das ist jedoch selten der Fall gewesen, und je mehr du grabst, desto mehr findest du heraus, was getan werden muss.
Es ging also ebenso sehr darum, eine Bestandsaufnahme zu machen, aufzuräumen, offene Fragen in Bezug auf Sounddaten, Code und Logik zu klären, wie sicherzustellen, dass Wwise Events und Sounds einfach existieren. Es gibt bestimmte Dinge, die unter FMOD funktionierten, die in dieser Art und Weise funktionierten, aber mehr trotz aller Dinge als durch Design. Dies ist nicht auf die Schuld von jemandem zurückzuführen, nur dass Audio oft auf Projektänderungen spät am Tag der Entwicklung des Spiels reagiert hat.
So weit wie möglich haben wir die Gelegenheit genutzt, um sicherzustellen, dass dieser Wechsel zu Wwise eine Verlagerung von kurzfristigem, reaktivem Denken und Gestalten ist, und dass wir uns mehr darauf zubewegen, wie wir die Dinge angehen wollen - dem Spiel (buchstäblich) so weit wie möglich voraus zu sein: zum Beispiel Vorlagen in Wwise zu entwickeln, alles sauber und frei von Hacks zu halten. Wir haben unser Code-Team wieder zusammengebracht, ebenso wie unser in Austin entwickeltes Tech-Sound-Design, damit wir im Vorfeld von FPS am effektivsten Köpfe schlagen können. Das neue System zu entwickeln sowie das Dog-Fighting-Modul wieder auf den neuesten Stand zu bringen und verschiedene Aspekte des persistenten Universums zu unterstützen - diese Dinge wären schwer genug, um ohne die neue Audio-Engine auskommen zu können. Aber wir dürfen nicht zu viel meckern!
Leider hat uns einer unserer Senior-Sounddesigner, Tom, diesen Monat verlassen. Er hat ihn vermisst, da er über einen reichen Erfahrungsschatz in CryEngine verfügte, aber ihm wurde die Möglichkeit geboten, seinen Lieben näher zu kommen, und es ist schwer, damit zu argumentieren. Also geht er gut miteinander aus - wir wünschen ihm alles Gute für seine zukünftigen Bemühungen, er wird nicht leicht zu ersetzen sein.
In weiteren Nachrichten haben wir unsere neu errichteten Sound-Design-Räume, die größtenteils bezugsfertig sind. Wir müssen unsere akustische Behandlung noch richtig auf die Wände anwenden, und wir warten auf einige Möbel und Monitore (Monitore sind das, was die Audioleute Lautsprecher nennen, nur um alle zu verwirren), um anzukommen, aber es ist schön, diese Räume zusammenkommen zu sehen. Wir haben versucht, jedem von ihnen eine eigene Farbgebung zu geben, die entweder kreative Funken oder leichten Wahnsinn verursacht. Kommt auf den Raum an. Vielleicht werden wir von beidem ein wenig Zeuge! Sie müssen etwas optimiert und abgestimmt werden, um die Klangneutralität zu gewährleisten. Sie sind zugegebenermaßen ein wenig klein, was es schwierig macht, sicherzustellen, dass sie frei von stehenden Wellen usw. sind, die bestimmte Bänder des Audiospektrums falsch darstellen können. Wir kommen so nah ran, wie wir es praktisch können, aber wir brauchen nur ein wenig Zeit, um dorthin zu gelangen, wo sie sein müssen.
Wir haben versucht, uns rechtzeitig anzupassen, um mit Prozessen im Zusammenhang mit fremden Vocals zu experimentieren, mit denen wir begonnen haben, während die Linguisten den Aspekt der fremden Sprache immer wieder festhalten. Es ist immer eine knifflige Gegend, aber es erweist sich als sehr interessant zu sehen, was man tun kann, bevor man in das akustische Äquivalent des unheimlichen Tals kommt.
Außerdem waren wir vor Ort, um den laufenden Dreh für'Squadron 42' zu unterstützen, über den ich natürlich nichts sagen werde, also fragen Sie mich nicht;)
Danke, dass du dir die Zeit genommen hast, dich über alle Dinge bei CIG Audio zu informieren. Bitte stellen Sie ein oder zwei Fragen im Ask A Developer Forum und wir werden unser Bestes tun, um diese zu beantworten. Auf Wiedersehen für jetzt!
Das Frankfurter Team wächst stetig und ist in zahlreichen Disziplinen wie Basistechnologie, KI, Design, Cinematics, Audio, Animation, FX, etc. tätig. Wie in unserem Bürovideo letzten Monat zu sehen war, füllte sich unser Zeitarbeitsraum, wir haben einen weiteren Raum gemietet, um zusätzliche Mitarbeiter aufzunehmen. Wir haben uns auch darauf vorbereitet, in unser neues Büro einzuziehen, der offizielle Umzug wird Anfang Juli sein, und wir werden höchstwahrscheinlich ein neues Video veröffentlichen, sobald wir uns eingelebt haben. Wir sind erst seit ein paar Monaten Teil des globalen Teams, aber die Dynamik und der Fortschritt im gesamten Spiel aus allen Studios und Büros ist großartig zu sehen, und wir sind froh, dabei zu sein.
Ingenieurwesen
Für den Monat Mai war Frankfurt Engineering an mehreren Fronten beschäftigt. Wir haben große Fortschritte auf dem Gebiet der Großen Welt gemacht (Verschiebung der Codebasis auf 64-Bit-Koordinaten, so dass Galaxiengrößen (buchstäblich) in Star Citizen erstellt und erforscht werden können). Die Hauptaufgabe, die diesen Monat an Large World gearbeitet wurde, war es, die Rendering-Kamera relativ zu machen: Tatsächlich musste durch die Umstellung auf 64 Bit der gesamte Rendering-Code so geändert werden, dass er relativ zur Kamera ist und nicht mehr einfach in der absoluten Welt koordiniert.
Es gab auch viele Fortschritte beim Zonensystem, unserem neuen Raumgliederungssystem, das das alte oktare Raumgliederungsschema der CryEngine ersetzt. Das Zonensystem ist besonders geeignet für ein Spiel wie Star Citizen, das große, dynamische Karten, eine große Anzahl von Einheiten und große bewegliche Schiffe bietet. Apropos Mehrbesatzung: Wir haben auch an schiffslokalen Physikgittern gearbeitet (damit die Spieler in fahrenden Schiffen herumlaufen können), an Laufzeitvorabteilungen und an der Untersuchung von Entitätsoptimierungen und Streaming. Wir testen diese neuen Systeme zunächst mit dem Retaliator.
Wir begannen auch mit der Implementierung optimierter Asset-Speicherformate für Vertex-Daten, um die Gesamtdatengröße zu reduzieren, die Durchlaufzeit und den Speicher sowie die CPU/GPU-Leistung zu verbessern. Diese Optimierungen werden in Kürze umgesetzt.
Wir haben eine erste F&E-Diskussion zum Thema Prozesserzeugung begonnen, die später eine gewisse Zeit in Anspruch nehmen wird, nachdem die oben genannten Big-Ticket-Positionen alle vorhanden sind. Es gab viele Bereinigungen von veralteten CryEngine-Funktionalitäten, die wir für Star Citizen nicht mehr benötigen, wie den alten Level Heap, veraltete Renderknoten und viele andere kleinere Elemente. Zusätzlich haben wir daran gearbeitet, die relevanten Teile des neuen 3.7 SDK in unsere Codebasis zu integrieren. Alle diese Hauptaufgaben stehen nun kurz vor dem Erreichen der Hauptlinie des Star Citizen Codes. Darüber hinaus haben wir allgemeine Unterstützung, Funktionen und Bugfixes für den Motor bereitgestellt.
Wir haben auch unsere Speicherprofilierungstools aktualisiert und damit verbundene alte Kratzer aus dem gesamten Motorcode entfernt.
KI
Im letzten Monat haben wir eine solide Basis für alle zukünftigen Entwicklungen im Zusammenhang mit der Künstlichen Intelligenz in Star Citizen gelegt.
Wir begannen mit der Vereinheitlichung des CryEngine Kommunikationssystems mit dem CIG Contextual Reaction System. Was sind das für Systeme?
Das Kommunikationssystem wird verwendet, um KI-Charaktere sprechen zu lassen: Das Verhalten (oder ein anderes System) kann verlangen, eine bestimmte Kommunikationsleitung zu spielen (z.B. "GreetThePlayerInFronOfYou") und das System wird sich um eine geeignete Variante für dieses Konzept kümmern und eine geeignete Variante wählen (z.B. "Grüße mein Freund!") und überprüfen, ob das definierte Tempo tatsächlich das Abspielen des Audios ermöglicht. Das System ist auch für den korrekten Umgang mit einem Fall verantwortlich, in dem eine Kommunikationsleitung, die auf einem Kanal mit hoher Priorität abspielt, die aktuelle Nachricht löschen muss, wenn sie auf einem Kanal mit niedrigerer Priorität abspielt.
Das klassische Beispiel ist der NSC, der während des Sprechens geschlagen oder geschossen wird. Sein Schmerzensschrei sollte definitiv alles unterbrechen, was er vorher gesagt hat!
Das Contextual Reaction System wird verwendet, um eine Kommunikationsleitung auszulösen, die auf bestimmten, vom Spiel ausgelösten Ereignissen basiert. Ein Schiff, das stark beschädigt ist, kann ein "ShipsDamaged"-Signal ausstrahlen, das vom CRS empfangen wird, und es wählt eine geeignete Variante des Audios, das abgespielt werden muss. CRS ist bereits vollständig in Dataforge integriert, so dass die Autoren in der Lage sind, neue Inhalte ohne Codeunterstützung zu erstellen. In diesem Monat haben wir mit der Zusammenführung der neuen Systeme begonnen, um von beiden zu profitieren!
Wir begannen auch mit der Arbeit am CryEngine Cover Surface System, um es mit dem Kythera-Verhaltenssystem zu verbinden und die Unterstützung der großen Welt zu ermöglichen. Das Cover Surface System ist in der Lage, ein physisches Objekt zu erfassen und automatisch Daten zu erzeugen, um Deckungspositionen zu speichern.
Darüber hinaus haben wir die Grundlage für die Erweiterung des CryEngine MNM-Navigationssystems zur Unterstützung großer weltweiter und lokaler Navigationsnetze geschaffen. Wir haben mit dem Prototyping der Funktionalität begonnen, ein Navigationsnetz an einem sich bewegenden Raumschiff anzubringen, so dass wir in den nächsten Monaten die Besatzungsmitglieder des Schiffes in der internen Raumfahrzeugumgebung navigieren lassen können.
Wir konzentrierten uns auch auf die Koordination der Arbeit von Moon Collider im Zusammenhang mit einigen Verbesserungen des Kythera Behavior Tree Systems. Das BTS ist nun mit DataForge verbunden, damit System-/Game-Designer schnelle neue Verhaltensweisen erstellen/prototypen können, ohne C++-Code schreiben zu müssen. Außerdem wurden neue Verhaltensknoten eingeführt, die grundlegende Funktionalitäten wie Zustandsmaschinen, Zeitstempel und Signale unterstützen. All diese Funktionalitäten werden uns in die Lage versetzen, komplexere und interessantere Verhaltensweisen zu implementieren.
Im Allgemeinen planen wir viele neue Features und werden einige coole Videos/Bilder vorbereiten, um mehr Details über unseren Fortschritt im nächsten Monat zu zeigen!
Design
Auf der Designseite haben wir eng mit dem britischen Team zusammengearbeitet und die Verantwortung für ein Level der Staffel 42 übernommen. Wir sind in jedem Aspekt der Entwicklung von Star Citizen aktiv, von der Arbeit an der Veröffentlichung des FPS-Moduls bis hin zur Entwicklung eines hochrangigen Verhaltensbaum-Feedbacks, das alle unsere Spielgebiete umfasst. Weitere Herausforderungen sind der Aufbau und die Einrichtung des Turm-Gameplays, die Bereitstellung von hochkarätigem Squadron 42-Feedback für Großbritannien und die Arbeit an der Vereinheitlichung der Anpassung von FPS-Anzügen, damit es besser funktioniert, als wir es derzeit mit den Schiffen tun.
Kinematiken
Ein paar Mitglieder des Teams waren den ganzen Monat über in London am Set, Chris Roberts drehte Szenen für Squadron 42. Die Besetzung ist fantastisch und wir können es kaum erwarten, bekannt zu geben, wen wir haben und ihre Auftritte zu präsentieren. Wir verstärken das Cinematics-Team und beginnen, die interne Pipeline und den Workflow zu verbessern.
Audio
Unser Audio-Ingenieur hat den ganzen Monat in Großbritannien verbracht, um mit seinem Audio-Team zusammenzuarbeiten, um das Audio für die nächste Veröffentlichung auf Wwise zum Laufen zu bringen.
Weitere Arbeiten zur Konvertierung alter FMOD-basierter Code-Features für die Verwendung des neuen Audiosystems. Ich habe einige Zeit bei der Entwicklung der Asset-Konvertierungsskripte mitgewirkt, um die einfacheren Teile des Prozesses zu automatisieren, so dass sich die Sound-Designer auf die Abstimmung der Sounds und die Art und Weise, wie sie im Spiel ausgelöst werden, konzentrieren können, anstatt sich um die Portierung der aktuellen Implementierungen kümmern zu müssen. Es wurden neue Tools für die Audio-Asset-Pipeline vorgestellt, die von den Sound-Designern und den Build-Servern verwendet werden, um die tägliche Produktion von Audio-Assets zu vereinfachen und zu beschleunigen.
FX
Im letzten Monat haben wir uns hauptsächlich auf die Erforschung verschiedener Arten von Feuer konzentriert, die in das Spiel einbezogen werden sollen. Diese reichen von kleinen Bränden und Trümmern bis hin zu gewaltigen Flammen und riesigen Explosionen. Rauch ist auch ein wichtiger Teil und sie dazu zu bringen, sich auf realistische Weise zu vermischen, war einer der Schwerpunkte des aktuellen F&E-Zyklus.
Wir haben auch einige Arbeiten am Blitz für einige der Staffel 42-Missionen durchgeführt, die hauptsächlich als Langstrecken-Hintergrundeffekte verwendet werden.
Guten Morgen, Bürger! ...oder Guten Abend Piraten? ...wie spät ist es überhaupt im Raum?? Poste die richtige Antwort in die Kommentare, um einen Daumen nach oben zu gewinnen.
Da es mehr als einen Monat dauert, etwas Wichtiges in einem so großen und detaillierten Spiel wie Star Citizen zu schaffen, könnte man feststellen, dass der Bericht dieses Monats dem Bericht des letzten Monats ähnlich ist, aber mit anderen Worten beschrieben wird :) Das bedeutet jedoch NICHT, dass der Monat ohne Fortschritt war, ganz im Gegenteil! Hier ist der Monatsbericht für das BHVR-Team:
Zunächst einmal haben wir uns intensiv mit dem Polieren, Debuggen und der Unterstützung anderer Studios auf verschiedenen Spielmodulen beschäftigt. Als wir uns dem FPS-Modul-Release und der Lieferung des Sozialmoduls nähern (bereiten Sie Ihre Aufregungstaschen vor!), wird die Zeit nicht so sehr mit dem Hinzufügen neuer Funktionen verbracht, sondern vielmehr mit dem Polieren und Konsolidieren des bereits Vorhandenen.
Hier sind die bemerkenswertesten Module, Systeme, systemischen Module und modularen Systeme, die in diesem Monat debugged, poliert und/oder unterstützt wurden:
Der Chat im Spiel Das Emote-System: /dance /dothebender Das FPS-Modul Die Lobby: Mehrsitzer in der Lobby: FPS Loadout Lassen Sie uns etwas über das Sozialmodul sprechen. Wir haben das Chatsystem um weitere Funktionen erweitert, um die Bedienung einfacher und angenehmer zu gestalten. Wir haben die erste Version der gefilterten Konversationsregisterkarten implementiert, die es Ihnen ermöglicht, mehrere private oder öffentliche Gespräche in verständlicher und geordneter Weise zu führen. Wir haben an der Schnittstelle und ihrer Erfahrung gearbeitet und sie für diese erste Iteration in einen Sperrzustand versetzt.
Wir haben auch einige Zeit damit verbracht, interaktive Elemente wie Flairs, den Holotable und Türen auf der Client- und Serverseite zu reparieren. Dies ist offensichtlich für jeden Ort im Spiel relevant, nicht nur für die Hangars.
Ingenieure haben die Replikation und Instanziierung der Hangars debuggt, während Leveldesigner alle möglichen Probleme in ihnen gelöst haben. Ich weiß nicht, was du in diesen Hangar-Jungs machst, aber sie scheinen die ganze Zeit zu brechen! Bitte hör auf, deine Buggys überall zu zertrümmern. ;)
Die Erstellung des Basis-Spawning-Moduls ist abgeschlossen, das, ob Sie es glauben oder nicht, das Spawnen mehrerer Spieler gleichzeitig in Hangars und an Planetenstandorten übernimmt. Damit können wir dich (also nicht dich, sondern deinen Charakter) an die richtige Position bringen, je nachdem, woher du kommst (Hangar -> Planetenseite, Raum -> Planetenseite, etc). Ich hätte nicht gedacht, dass das Laden und Spawnen so interessant sein könnte, aber wir sind gespannt auf die Videos, die Sie über Ihren ersten Spawn-Planetenrand veröffentlichen werden.
Okay, kommen wir nun zum lustigen Teil: Planeten! Diesen Monat haben wir in der Kunstabteilung alle Arbeiten für einen industriellen Bergbauplaneten abgeschlossen. Der Plan ist, dieses Set in der gesamten Galaxie zu verwenden, hauptsächlich, aber nicht ausschließlich für Delamar im NYX-System. Unser Hauptziel ist es, die Setstücke so vielseitig wie möglich zu gestalten, damit jedes Kunstteam in diesem Projekt verschiedene Orte schaffen kann. Dies hat ziemlich viel Zeit in Anspruch genommen, aber wir sind mit dem Endergebnis sehr zufrieden.
Wir haben auch mit der Arbeit an Legacy-Objekten begonnen, um sie an die neuen visuellen und technischen Standards anzupassen. Da wir mehr Standorte haben, aktualisieren wir unsere Techniken und da diese "alten" Stücke in Zukunft von Nutzen sein werden, müssen wir sicherstellen, dass sie konform sind.
Unsere Leveldesigner erforschen und verfeinern andere Standorte wie die Blöcke auf Terra Prime, Marianna und Odyssa, schaffen neue Innenräume und polieren und unterstützen ältere Standorte. Ähnlich wie die alten Kunstwerke änderten sich auch einige interaktive Objekte und mussten aktualisiert werden, um auf dem neuesten Stand zu sein.
Das mobiGlas hat viel Glanz und Fortschritt erfahren. Wir haben Animationen implementiert, um es noch eleganter zu machen. Einige Verfeinerungen und Aktualisierungen wurden auch am Warenfluss vorgenommen. Wir können jetzt Ihr UEC-Guthaben anzeigen und Sie können auch Dinge und Dinge wirklich kaufen!
In gleicher Weise haben wir eine erste Implementierung der Benutzeroberfläche, des Codes und der Visualisierung des microTech Kiosk durchgeführt. "Was zum Teufel ist das?", magst du fragen. Nun, einige Geschäfte und andere Orte rund um den Vers haben microTech-Kioske, die verwendet werden, um holographische Darstellungen von extra großen Produkten zu zeigen, die nicht zum Ort passen. Kioske werden auch genutzt, um mit Hilfe des mobiGlases Zugang zu einem Bestandskatalog zu erhalten. Das mobiGlas ist auch ein MicroTech-Produkt, so dass Sie jetzt die Verbindung sehen. Unser erster Kiosk wird in der Astro-Armada eingesetzt, wo er mit ihm interagiert werden kann, um Schiffe zu durchsuchen und zu kaufen.
Die Kioske sind Teil der ersten Phase des Schiffseinkaufserlebnisses. Wir planen immersivere und interessantere Wege, um Schiffe für die Zukunft zu kaufen, die auf Anhieb nicht lieferbar waren.
Ein weiteres interessantes Objekt, an dem wir arbeiten, ist der Personalschrank. Lass dich nicht täuschen, das hat nichts mit Flairs zu tun. Der persönliche Spind befindet sich in Ihrem Hangar und ist der Aufbewahrungsort für Ihre FPS-Geräte und Waffen. Später auf der Straße wird dieser Schrank nicht nur dazu verwendet, Waffen zu zeigen, sondern auch, um Ladungen vorzubereiten, um die Ausrüstung deines Charakters schnell auf den richtigen Job umzustellen.
Wie immer haben wir das Flair-Objekt dieses Monats zusammen mit anderen geheimen Merchandise-Arbeiten fertiggestellt, was die Überraschung nicht verderben wird, denn Überraschungen zu verderben macht überhaupt keinen Spaß.
Vielen Dank für Ihre Aufmerksamkeit! Jetzt geh und zerstöre einige Schiffe, dann wirst du es tun!
Grüße Stern-Bürger! Ich bin sicher, dass die meisten von euch den massiven Beitrag über Star Marine gesehen haben, und den Grund, warum es ein wenig länger dauert als erwartet. Vielen Dank, dass du mit uns mitgemacht hast! Der größte Teil des Monats Mai wurde für die Ausführung der in diesem Beitrag aufgeführten Punkte aufgewendet. Nachfolgend finden Sie die Details zu den einzelnen Teams.
Ingenieurwesen
Neben dem Zerquetschen vieler Fehler hat sich das Engineering-Team darauf konzentriert, die Animatoren bei der Entwicklung des neuen Jukes, Starts und Stopps-Systems zu unterstützen. Es gibt einzigartige Animationen für jede Richtungsänderung in eine andere, sowie für jeden Zustand und jede Geschwindigkeit, mit der der Spieler unterwegs ist. Das kann sich sehr schnell summieren! Auch die Arbeit an Zero-g-Bewegungen und SATA-Kugelfunktionen wurde fortgesetzt. Nachdem wir den SATA-Ball getestet hatten, stellten wir fest, dass es einige spezifische Fälle geben musste, die uns helfen würden, den Ball auf einem so großen Raum zu managen.
Design
Die Designer haben hart daran gearbeitet, SATA Ball zum Laufen zu bringen. Dies beinhaltet vor allem die Arbeit an der Spielbarkeit und den visuellen Hinweisen auf den Spieler für das Geschehen. Sicherstellen, dass die Spieler den Ball leicht finden können, dass die Spieler den Ball leicht greifen und mit Genauigkeit werfen können und dass sie ihn effektiv ansteuern können. Sie haben auch viele Tests mit dem Basissatz von Waffen durchgeführt und optimiert, wie das Atmen in Genauigkeit spielt.
Animation
Das Animationsteam konzentriert sich derzeit darauf, alle Jukes, Starts und Stopps von Mocap-Daten bereinigt und für die Implementierung im Spiel bereit zu machen. Wie bereits erwähnt, ist es eine Menge Mocap-Daten, so dass sie ihre Teller ziemlich voll haben.
Kunst
Das Kunstteam hat sich im letzten Monat auf zwei Hauptziele konzentriert. Einer davon ist die Überarbeitung der Anlagen für die Gold Horizon Station, um den Anforderungen an die Einrichtung des persistenten Universums gerecht zu werden. Dies wird es Teams in allen Studios ermöglichen, dieses Set in ihren verschiedenen Levels zu verwenden. Teilen ist wichtig!
Das zweite Ziel des Kunstteams war es, die vorhandenen Waffen zu polieren und ein einheitliches Schienensystem für Befestigungen zu schaffen. Dies wird die Erstellung von Anhängen erheblich erleichtern, da alles universell ist.
VFX
Einige neue VFX wurden für SATA Ball entwickelt, Effekte für die Tore, damit die Spieler nicht verwirrt werden und auch einige Effekte für den Spieler, wenn sie erschossen und deaktiviert werden. Ein Polish Pass wurde auch für alle vorhandenen Effekte mit Feedback von Chris durchgeführt.
Danke, dass du Citizens gelesen hast! Illfonie aus!
Hier ist, was wir hier in Montreal im Monat Mai gemacht haben:
Starmap
Herausragende Fortschritte wurden in diesem Monat in der eigentlichen Kunst für das Webstar-Kartenmodul erzielt. Wir haben jetzt vollständige künstlerische Entwürfe für die Top-Level-Ansicht der Galaktischen Ebene, in der alle Sternensysteme angeordnet sind und ihre Jump Point Verbindungen zeigen. Die größte Herausforderung bestand darin, einen Weg zu finden, die Sprungbretter stilistisch schön, aber auch funktional so darzustellen, dass sie die Größen und Richtungen der Wurmlöcher darstellen. Große Fortschritte wurden bei einer 2D HeatGrid-Darstellung erzielt, um (auf jeder Ebene) den politischen Einfluss, die Kriminalität und die wirtschaftliche Ebene der Gebiete der Galaxie darzustellen. Obwohl dies immer noch experimentell ist, inspirierten die von unseren Künstlern vorgeschlagenen Visuals zur Erweiterung dieses Features.
Eine der wichtigsten UI-Komponenten, die in diesem Kunstpass enthalten sind, ist die Control Disc; das ist ein sehr interessantes Design, da wir denken, dass es auch als In-Game-Komponente verwendet werden kann. Auf dieser Disc können Sie mit den verschiedenen Elementen, die Sie auf dem Bildschirm sehen, interagieren, während Sie durch die Galaxie surfen. Unser Mock-up-Set der Künstler beinhaltet auch den Bildschirm "Space Object Overview", der im Grunde genommen das ist, was passiert, wenn man mehr Informationen über ein Objekt anfordert, sei es ein Planet, ein Asteroidengürtel, ein Nebel oder ein Wurmloch. Diese allgemeine Ansicht dient als primäre Anzeige für Informationen über alles aus der Starmap sowie für den Sprung zu den Galactapedia-Einträgen für jeden von ihnen.
Das Design der Starmap ist nun in einem Zustand, in dem sie mit den tatsächlichen Plänen für die Starmap im Spiel verknüpft werden kann, weshalb wir auch unsere Benutzeroberfläche so gestaltet haben, dass sie mit den Spielkontrollen und -erfahrungen vereinheitlicht wird.
Community Hub
Wir haben in diesem Monat die Schnittstellen-Mock-ups für diesen neuen Abschnitt fertiggestellt, sein Design mit dem neuen Website-Look verschmolzen und es an tatsächliche datengesteuerte Ansichten angehängt. Wir haben viel Zeit damit verbracht, so viele Inhalte wie möglich von den Fans zu präsentieren: Bilder und Galerien, aber auch Videos von verschiedenen Anbietern, Streaming-Kanäle, Podcasts.... Der Hub befindet sich noch in intensiver Entwicklung, wir werden bald mehr zeigen können.
Ausgaberat
Der Issue Council, unser neues "crowdsourced" Bug-Reporting-System, durchlief einen Monat lang eine Headdown-Codierung. Der Kern des Systems wurde fertiggestellt, einschließlich Datenmodelle und API auf Systemebene. In der Zwischenzeit hat das Designteam die Bewegungen auf der eigentlichen Benutzeroberfläche durchgearbeitet. Wir haben dem QS-Team in Austin eine Demo gegeben und alle sind begeistert, dass sie es nutzen können. Im Juni werden wir es testen, indem wir tatsächlich Fehler über sich selbst in es eingeben!
Launcher
Diesen Monat haben wir in Zusammenarbeit mit der DevOps-Crew in Austin eine Prototyp-Überarbeitung der Star Citizen-Rakete abgeschlossen. Der neue Launcher ist vorerst nur intern, nur für CIG-Tests, und basiert auf der BitTorrent-Technologie. Dies ermöglicht es, den Patchprozess in Größe und Geschwindigkeit effizienter zu gestalten und ist ein erster Schritt zu einem webbasierten Launcher, der wiederum dazu führt, dass mehr Konfigurationswerkzeuge direkt im Launcher zur Verfügung stehen (Hangarkonfiguration, zukünftige Inventur, REC-Aktivierung....).
Chat
Das Chat-System hat auch in diesem Monat einige Verbesserungen erfahren. Wir haben sein Aussehen überarbeitet, um es dem Rest der Website näher zu bringen, und wir haben "klebrige" Raumthemen zur besseren Lesbarkeit eingeführt.
Und noch mehr!
In diesem Monat kam auch mit einem eigenen Content Slew Updates auf der Website. Wir sahen tatsächlich 2 Konzeptverkäufe mit dem Starfarer Gemini und dem neuen MISC Reliant Minischlepper, und wir brachten Ihnen auch das in Montreal produzierte Minispiel Hyper Vanguard Force IV von Dave Richard und Christine Marsh. Apex Predators vereinigen sich!
Um es stiller auszudrücken: Wir haben auch das neue Amazon "Login And Pay"-Zahlungssystem für nordamerikanische Nutzer implementiert.
Nachdem May in den letzten Monaten viel Planungs- und Konstruktionsarbeit geleistet hatte, war May zur Abwechslung mal kurz auf diese aufmerksam geworden, so dass wir die Chance hatten, uns wirklich in eine coole Ingenieursarbeit einzulassen. Es gab mehrere große Designer-Tool-Funktionen, an denen wir gearbeitet haben, und wir freuen uns darauf, sie nutzen zu können.
Ingenieurwesen
Letzten Monat sprachen wir über die ausgefallenen Verbesserungen beim Verbinden von Keilwellen, an denen wir gearbeitet haben. Dies ist ein Feature, das es Designern ermöglicht, eine Spline zu spezifizieren, die ein Schiff mitfliegen soll (um einige ausgefallene Manöver durchzuführen oder wirklich nahe an Hindernissen zu fliegen, von denen die KI sonst Abstand halten würde), und die KI wird einen optimalen Weg finden, um so schnell wie möglich auf die Spline zu gelangen. Dazu muss die KI einen Weg von ihrer aktuellen Position und Richtung zum Anfang der Spline herausfinden und am Ende nach unten in die Richtung des Spline-Pfades schauen, sobald sie dort ankommt. Dies kann dann komplizierter werden, da die Konstrukteure die Geschwindigkeit angeben können, mit der sich das Schiff bewegen soll, wenn es die Spline startet, so dass dies den Weg, den das Schiff nimmt, beeinflussen kann, da es möglicherweise den Weg ein wenig krümmen muss, um zusätzliche Anstiege hinzuzufügen, wenn es auf den neuesten Stand der Technik kommen muss oder um viel langsamer zu werden. Und natürlich wollen wir auch, dass das alles ziemlich natürlich aussieht.
Wir haben das Feature diesen Monat fertig gestellt und es den Designern zur Verfügung gestellt. Jetzt, da Schiffe Splines von überall zuverlässig verbinden können, erleichtert es die Einrichtung des Designers, aber was für Sie noch wichtiger ist, es wird uns ermöglichen, sie viel mehr in systemischem Verhalten einzusetzen. Bisher mussten wir bei der Auswahl der Schiffe für eine Spline sehr restriktiv sein, aber das gibt ihnen viel mehr Freiheit. Wenn wir das Verhalten angepasst haben, werden sie in zukünftigen Versionen von Arena Commander viel mehr verwendet werden.
Das größte Feature, an dem wir diesen Monat gearbeitet haben, war eine komplette Änderung in der Art und Weise, wie wir KI-Verhaltensbäume erstellen. Bisher haben wir sie direkt im Code erstellt. Mit Kytheras Laufzeit-C++-Rekompilierung war dies eigentlich recht effizient und ermöglichte eine schnelle Iteration während der Ausführung des Spiels, war aber für Designer ohne Programmierkenntnisse nicht zugänglich. Deshalb haben wir viel Arbeit geleistet, damit Verhaltensbäume in DataForge erstellt werden können.
Sie werden in der Vergangenheit viel von DataForge gehört haben, als das benutzerdefinierte Datenmanagement-Tool, das von Designern für alle Arten von unterschiedlichen Daten in Star Citizen verwendet wird. Es wurde von Anfang an so konzipiert, dass verschiedene Ansichten für verschiedene Datentypen möglich sind, so dass Sie gegebenenfalls Daten in einem Tabellenkalkulationsformat bearbeiten können, während für andere Dinge eine grafische Knotenbearbeitungsansicht besser geeignet ist, und so weiter.
Wir haben jetzt eine Datenkategorie für Verhaltensbaumdaten in DataForge, die es Designern ermöglicht, Verhaltensbäume über eine benutzerfreundliche GUI-Schnittstelle zu erstellen und zu bearbeiten und diese Verhaltensweisen dann direkt auf ein KI-Zeichen anzuwenden, ohne dass sie Code schreiben müssen. Außerdem können sie die Verhaltensbäume zur Laufzeit modifizieren und die Ergebnisse sofort sehen, was für eine schnelle Wiederholung fantastisch ist.
Was uns jedoch besonders interessant machte, ist, dass wir erwarten, dass in Zukunft regelmäßig neue Verhaltensbaumknoten erstellt werden, und wir wollten das Hinzufügen dieser Knoten in DataForge so einfach wie möglich unterstützen. Deshalb haben wir an der Erstellung eines einfachen Konsolenbefehls im Editor gearbeitet, der automatisch neue Definitionen für DataForge generiert, sowie an einem neuen C++-Bindungscode, der DataForge-Verhaltensbaumstrukturen mit dem zugrunde liegenden Kythera-Verhaltensbaumcode verbindet. Wenn ein Codierer also einen neuen Knoten erstellt, ist es nur ein kurzer Konsolenbefehl und der Knoten ist nun vollständig in DataForge integriert!
Es ist also immer noch möglich, KI-Verhalten in C++ zu erstellen, wie bisher, aber jetzt haben wir diese alternative GUI-Erstellungsmethode, die dann in entsprechenden C++-Code übersetzt wird, wenn das Verhalten ausgeführt wird. Wir freuen uns, dass die Designer beginnen, mit dem neuen Tool zu arbeiten und großartige Verhaltensweisen zu entwickeln. Wir erwarten, dass wir in naher Zukunft kleine Verbesserungen vornehmen müssen, um die Oberfläche für Designer noch einfacher zu machen, aber wir denken, dass es ein guter Anfang ist. Und wir müssen Ash Canning bei Foundry 42, dem Mastermind hinter DataForge, einen riesigen Schrei aussprechen, der uns wirklich kurzfristig viele Optimierungen vorgenommen hat, um DataForge zu helfen, Verhaltensweisen besser zu bearbeiten.
Schließlich haben wir etwas in unserem Debugging-Tool Kythera Inspector gearbeitet, damit Designer ihre Verhaltensbäume viel einfacher debuggen können, indem sie jederzeit eine visuelle Live-Darstellung dessen erhalten, was der Baum gerade tut. Letzten Monat haben wir die Möglichkeit hinzugefügt, Verhaltensbäume aufzuzeichnen und wiederzugeben, aber das ist nützlicher, um Fehler aufzuspüren. Für die Entwicklung von Verhaltensbäumen ist eine Live-Ansicht dessen, was sie tun, sehr praktisch. Wir geben diesem Feature den letzten Schliff und werden es bald an die Designer weitergeben, also werden wir auf den Bericht des nächsten Monats warten, um mehr darüber zu erfahren.
Meine Damen und Herren, Jungen und Mädchen, Bürger jeden Alters, Thomas, Kameramann und außergewöhnlicher Redakteur, hier, um Ihnen den Monatsbericht für Mai zu präsentieren. Wie immer berichtend aus dem, was man nur als Himmel auf Erden bezeichnen kann, alias dem einfach erhabenen Paradies, bekannt als Santa Monica, Kalifornien.
Und genau wie unser prächtiges Lokal war der Mai für uns ein geradezu wunderbarer Monat. Wir debütierten ein neues Segment in unserer Flaggschiffshow Around the Vers, genannt Ship Shape. Veranstaltet von der überschwänglichen und immer verführerischen Lisa Ohanian, bietet es uns die Möglichkeit, mit unseren Fans und Unterstützern einen umfassenden Blick in die Schiffspipeline zu werfen.
Apropos Around the Vers, Ben Lesnick hat einen fantastischen Job als Solo-Moderatorin gemacht, während Co-Moderatorin Sandi Gardiner aufgerufen wurde, ihre thespianischen Fähigkeiten beim Squadron 42 Motion Capture Shooting in London zu zeigen, und wir wurden mit einer Reihe talentierter Entwickler konfrontiert, die sich alle als hervorragende Faksimiles erwiesen haben, in Abwesenheit unseres berühmten Vorsitzenden auf unserer wöchentlichen 10 für Serien.
Im Mai sahen wir auch den beliebtesten Bugsmasher aller Zeiten, Herrn Mark Bartholomew Abent III, der den Sprung vom Untersegment Around the Verse zur alle zwei Wochen stattfindenden eigenständigen Show machte. Seine Pilotfolge wurde mit begeisterten Kritiken aufgenommen, und es ist mit großer Begeisterung, dass ich mit Freude bekannt geben kann, dass das Netzwerk tatsächlich einen Auftrag für eine ganze Saison von Shows erteilt hat.
Ganz ohne Zusammenhang zeugte uns der Mai auch die lang erwartete und lang erwartete Eröffnung von Fuddruckers Santa Monica, und das CommuniTeam vergeudete keine Zeit damit, es zum Mittagessen zu besuchen, und ich möchte nur sagen, dass wir nicht enttäuscht waren.
Und das, meine lieben Mitbürger, war der Monat Mai. Vielen Dank an alle unsere Fans, ohne dich wäre all dies nicht möglich, und es ist wirklich eine Ehre und ein Privileg, das tun zu können, was wir tun.
Bis zum nächsten Mal werde ich es immer und ewig sein,
Euer demütiger Diener,
Thomas Grüße Bürger,
Es ist schwer zu glauben, dass June schon da ist! In unseren Studios und Outsourcing-Partnern auf der ganzen Welt wird hektisch an Star Citizen gearbeitet. Diesen Monat freuen wir uns, Ihnen unser neuestes Studio, Foundry 42 Germany, vorstellen zu können. Sie werden in den kommenden Monaten viel aus Deutschland sehen: Sie sind damit beauftragt, viele der Programmherausforderungen, mit denen Star Citizen auf dem Weg in das persistente Universum konfrontiert ist, anzugehen. In diesen Bereichen und an unseren vielen Modulen und Meilensteinen wird weiter gearbeitet, von Star Marine (das gerade für sein PTU-Debüt vorbereitet wird) bis hin zu Squadron 42 (Kinofilme werden derzeit von Chris Roberts in London geleitet!) Ihre Top-Level-Ansicht dessen, was wir diesen Monat genau getan haben, finden Sie unten.
Willkommen zurück zu einer weiteren Ausgabe des Monatsberichts! Dieser Monat war ein ereignisreicher Monat mit vielen Entwicklungsnachrichten. Wie immer sind wir super aufgeregt, mit dir zu teilen, was wir im letzten Monat gemacht haben! Also einrichten und es sich bequem machen, denn hier kommt das Entwicklungs-Update!
Design
Eine der größten Entwicklungen vom Mai war die Enthüllung und der Konzeptverkauf für den MISC Reliant. Dieser Verkauf war eine große Leistung für uns und fühlte sich wirklich so an, als hätten wir jede Abteilung auf alle Zylinder geschossen, um den Verkauf vorzubereiten. Alle, die am Verkauf beteiligt waren, drängten sich wirklich darauf, sicherzustellen, dass es nicht nur pünktlich, sondern auch früh fertig war. Es war ein großartiges Beispiel dafür, wie sich unsere verschiedenen Abteilungen zusammenschlossen, um ein weiteres dieser unglaublichen Schiffe zum Leben zu erwecken. Wir sind auch ziemlich zuversichtlich, dass es der Community auch gefallen hat, mit über 19.000 verkauften Exemplaren während des Konzeptverkaufs. Vielen Dank an Sie alle, dass Sie sowohl dieses großartige neue Schiff von MISC als auch die Weiterentwicklung von Star Citizen unterstützen.
Wir haben einen Balancepass über die aktuelle Liste der Raketen genommen, insbesondere durch die Erhöhung der Anfälligkeit aller CS-Lock-Raketen (Tempest, Stalker, StrikeForce) für Spreurauschen, wodurch diejenigen, die auf eine bessere Chance geschossen haben, dem Zorn dieser mächtigen Munition zu entkommen. Zusätzlich wurden die Raketenverriegelungszeiten auf der ganzen Linie erhöht (von 2 auf 5 Sekunden), so dass die Piloten ihre Manövrierfähigkeiten auffrischen können! Das Ziel im Auge zu behalten, ist umso wichtiger geworden. Mit dieser Änderung werden auch Feuerlöschraketen praktischer. Frohe Jagd!
Eines der Schiffe, die die Pipeline hinunterfahren, ist der Crusader Industries Genesis Starliner. Die Starliner ist ein großes Schiff, das etwas größer als eine 747 ist. Dieses Schiff ist insofern einzigartig, als es eines der ersten Passagierschiffe ist, das vom Star Citizen-Team in Angriff genommen wird. Als erstes Schiff seiner Art hat es uns dazu gebracht, unsere Entwürfe in Bezug auf die Passagiere im Weltraum in Frage zu stellen. So werden beispielsweise noch einige der Fragen zur Fahrgastkapazität, zur Sicherheit dieser Fahrgäste und zu den maximalen Flugzeiten beantwortet. Das äußere Konzept ist an einem soliden Ort, aber die inneren Konzepte sind noch in Arbeit. Wir freuen uns sehr, Ihnen alles zu zeigen, was wir uns ausgedacht haben. Bald wird der Starliner mit Ihnen am Steuer oder als Passagier auf dem Weg zu dem Urlaubsort, den Sie ausprobieren wollten, die Sterne erkunden.
Ursprünglich im März-Update erwähnt, machen wir weiterhin Fortschritte in Richtung unseres neuen Physically Based Damage Systems. Dieses neue System wird an mehreren Fronten für das aktuelle Arena Commander Gameplay helfen und dazu beitragen, die Grundlagen für die Staffel 42 und die PU, aus der sie gebaut werden soll, zu schaffen. Einige der größten Highlights sind eine komplette Überarbeitung des Schadens und der Handhabung für jede Waffe mit einem klaren Fokus darauf, sicherzustellen, dass Ballistik- und Energiewaffen ihre eigenen einzigartigen Eigenschaften und Auswirkungen auf das Spiel haben. Aber wenn Sie den Schaden ändern, ist das nur ein Teil des Rätsels, also erwarten Sie auch ein vergleichbares Update für jede größere Schiffskomponente, um dieses neue System zu unterstützen: Schiffs- und Schild-Zustand, Kraftwerksleistung, Kühlraten, alles in Ordnung.
Ein weiteres großes Ereignis im Mai für das Büro in Santa Monica war, John Pritchett und Pete Mackay im Büro zu haben, als wir begannen, einen Teil des Flug- und Thruster-Handling für das Spiel wirklich einzuwählen. Während sie über einige ihrer Arbeiten während der letzten Around the Vers-Auftritte gesprochen haben, gibt es viele Arbeiten hinter den Kulissen, deren Besuch uns geholfen hat, sie zu rationalisieren. Jetzt haben wir noch bessere Tools und Dateneinstellungen, um den Bau neuer Schiffe und Komponenten reibungsloser und einheitlicher als bisher zu gestalten. Diese Arbeit half bereits bei der Vorbereitung des Reliant Verkaufs und ließ uns schnell die Massen- und Thrusteranforderungen für das Schiff schneller als je zuvor aufbauen.
Kunst
Für das HUD & UI haben wir einige Arbeit geleistet, um die CPU / Rendering-Performance zu verbessern, indem wir die Anzahl der Draw Calls, die der skalierte Aspekt des HUD beisteuerte, sowie einen Refaktor der Holo-Objekte optimiert haben, die zur Verbesserung der Rendering-Performance von holographischen Elementen und Entitäten beitragen sollten. Insgesamt sollte die Menge der CPU-Ressourcen, die das HUD / UI in Anspruch nimmt, jetzt deutlich geringer sein, und wir werden sie weiter optimieren, um die bestmögliche Leistung zu erzielen.
Diesen Monat haben Josh Coons und Mark McCall eine neue Helminnenausstattung entworfen und umgesetzt, die für alle FPS-Charaktere verwendet wird. Diese neue Richtung für die Helme ist ein großer Schritt in der Realisierung von Chris Roberts Gesamtvision für Star Citizen Charaktere. Das neue Helminnere gibt dem HUD-Team mehr Flexibilität und trägt zum Realismus unseres Universums bei.
Was unsere Helme einzigartig macht, ist, dass sie das Sichtfeld des Spielers beeinflussen und die Vielseitigkeit unseres FPS-Spielerlebnisses verbessern. Die Ausrüstung in unserem Spiel sollte sich real und substantiell anfühlen - nicht nur eine Reihe von Statistiken und Zahlen, die im Gameplay min-maxed werden sollen, mit Eigenschaften, die den verschiedenen Spielern die Wahl lassen, basierend auf ihren eigenen subjektiven Präferenzen, und die die Vielfalt der Spielerwahlen erweitern.
Bei der technischen Kunst lag unser Schwerpunkt in diesem Monat auf Schiffsuntergang, Bergung und Optimierung. Wir haben den Auftrag, das Gleichgewicht zwischen dem am besten optimierten Schadensansatz zu finden und gleichzeitig sicherzustellen, dass unser Gameplay-Design intakt bleibt.
In der Vergangenheit haben wir für Schiffsschäden fünf Versionen von jedem Teil eines Schiffes gebaut. Dies waren die 0%, 25%, 50%, 50%, 75% und 100% beschädigten Versionen. Das Sprengen von Schiffen sah sehr cool aus, aber diese Lösung war extrem arbeitsintensiv, verbrauchte viele Systemressourcen und war nicht skalierbar, damit CryEngine die epische Armada von Schiffen, die gegen Chris kämpfen, darstellen konnte.
Wir brauchten eine neue Schadenslösung. Ali Brown, Okka Kyaw, Geoff Birch und Mark Abent halfen alle bei der Entwicklung unserer neuen Damage Shader und Squib Technologie, die die Zerstörung unserer neuesten Schiffe ohne die hohen Ressourcenkosten ermöglichte. Aber selbst als wir diese großartige Leistung der Optimierung vollbrachten, planten unsere Designer neue Spielmechaniken wie Debris Salvage und Ship Repair, von denen jede die Kosten für die gesamte Verarbeitung unseres Schiffsmodells erhöht.
Der wahre Leistungsfeind von Star Citizen mit so vielen High-Fidelity-Assets ist "Draw Calls". Für diejenigen, die es noch nicht kennen, sind Draw Calls die Anzahl der Renderpasses auf jedem Geometrieteil, um das endgültige Bild zu erstellen. Wenn Ihr Raumschiffrumpf diffuse, spiegelnde und normale Texturen hat, dann würde das 3 Draw Calls bedeuten. Und wenn Ihr Schiff in 50 Stück aufgeteilt ist, wäre das 50 × 3 = 150 Draw Calls. Und fügen Sie einige hochwertige Selbstbeschattungen hinzu, und Sie können 150 auf riesige 300 Draw Calls verdoppeln! Unsere Schiffe werden mit PBR (Physically Based Rendering) gerendert, wobei der Damage Shader, Paint Variations und Decals mehr als 15-30 Draw Calls pro Stück erfordern. Um die Draw Calls zu optimieren, mussten wir also die Anzahl der einzelnen Figuren reduzieren. Aber das bedeutet, dass wir, um wirklich optimiert zu werden, weniger animierte Teile und weniger Absplitterungen des Schiffes benötigen würden! Ein ziemliches Rätsel, denn wir wollen diese Dinge!
Als er mit Ali über diese Optimierungsprobleme sprach, schlug er einen neuen Trümmeransatz vor, den wir jetzt untersucht haben. Anstatt das Schiff in einzelne, empfindliche Bereiche zu zerlegen und Trümmer vom Schiff zu lösen, schlug er vor, Teile des Schiffes mit dem Damage Shader und Spawn Debris zu verstecken, die dann vom Schiff wegfliegen würden. Dieser neue Ansatz sieht immer noch so aus, als ob Trümmer vom Schiff geblasen werden, ermöglicht es uns aber, die Anzahl der Schiffsrumpfnetze zu reduzieren, was auch die Draw Calls deutlich reduziert. Und außerdem ermöglicht uns diese Lösung, Schutt zu erzeugen, der bergefähige Komponenten enthält! Also, die Waffe, die du gerade von dem Entermesser in der PU abgeschossen hast? Es gehört jetzt dir. Gern geschehen.
Es gab viele andere Durchbrüche wie diesen. Und dieser Monat hat uns der Verwirklichung der Weltraumoper unserer Träume näher denn je gebracht. Nun ist es unsere Aufgabe, den kompletten Optimierungsplan über alle Schiffe im Spiel hinweg umzusetzen, mit dem Ziel, dass wir Squadron 42 mit erstaunlich lustigem Gameplay und einer seidig-glatten Bildrate veröffentlichen.
Ingenieurwesen
Die Arbeiten an Radar 2.0 sind abgeschlossen. Alles kann registriert werden, um auf dem Radar angezeigt zu werden, solange es eine passende IRadarObjekt-Struktur gibt. Für den Laien bedeutet das, dass, solange ein Objekt die richtigen Informationen enthält, dieses Objekt aufgenommen und auf dem Radar basierend auf seinen physikalischen Eigenschaften angezeigt wird. Ja, wir können EMP-Granaten sogar eine EM-Signatur geben und sie auf dem Radar erscheinen lassen, wenn Ihr Radar konfiguriert ist, um EM zu erkennen.
Wir haben es auch so gemacht, dass Radare in der Lage sind, nach jeder Art von Signaturtyp zu filtern und erkannte Objekte nun eine Instanz von ihnen erstellt haben. Die Erstellung dieser Instanz ermöglicht es uns, Dinge wie Stotterpositionsaktualisierungen durchzuführen und/oder Decay/Afalloff anzuzeigen, ohne das tatsächlich erkannte Objekt zu beeinflussen. Auf diese Weise können Design und Kunst coole und interessante Dinge für die angezeigte Instanzversion tun, ohne die zugrunde liegende Logik, die das Radar/Signatur antreibt, zu durchbrechen. In diesem Zusammenhang haben wir auch die Performance von Okklusionsprüfungen verbessert.
Last but not least haben wir die Unterstützung von "Dezibel" als neuen Signaturtyp hinzugefügt. Zu Fuß in Star Citizen kann Ihr Radar Audio aus der Umgebung wie Schritte und Waffenfeuer anzeigen. Diese Ereignisse sind nun ordnungsgemäß in das Signatursystem eingebunden, so dass Ihre Schritte und Waffen Feuer "Dezibel" erzeugen, die vom Spielerradar gescannt und angezeigt werden. Du wirst sehen, wie dieses Debüt mit dem FPS stattfindet.
Unser LA Engineering Team hat auch bei der Handhabung von Spieler-/Charakterkleidung, Individualisierung und Anhängen mit dem von uns entwickelten Item-Port-System geholfen. Das Item-Port-System ermöglicht das Anbringen von Items an Knochen, die auf 3D-Objekten definiert sind. Auf diese Weise befestigen wir alle unsere Schiffsteile und Schiffsartikel. Dieses System wird für Charaktere erweitert, die eine dynamische Skelett-Erweiterung durch skinned attachments unterstützen.
Das bedeutet konkret, dass wir die Körperteile haben, die in der Lage sind, Gegenstände auszurüsten. D.h. Füße, Hände, linke Hand, rechte Hand, Torso, etc. sind mit entsprechenden Knochen gekennzeichnet, die definieren, wo angebrachte Gegenstände angebracht sind. Von dort aus, wenn Sie ein Bruststück ausstatten würden, das eine taktische Schulterleuchte, Sauerstofftank und Brustholster erlaubt, benötigt jeder dieser zusätzlichen Befestigungspunkte zusätzliche Knochen. Das System erlaubt es jedem der zusätzlichen Knochen, die in einer Haut (enthäutetes Objekt, nicht tatsächliche Haut) angebracht sind, das Basisskelett zu erweitern, indem es dieses Skelett dynamisch mit den zusätzlichen Knochen aktualisiert.
Damit ist das Update für das Santa Monica Studio abgeschlossen! Vielen Dank wie immer, dass du dir die Zeit genommen hast, unsere Geschichte zu lesen und für deine Unterstützung bei der Entwicklung dieses Spiels! Wir könnten das nicht ohne jeden einzelnen von euch machen und eure Unterstützung wird von jedem von uns hier bei Cloud Imperium sehr geschätzt. Nochmals vielen Dank und wir sehen uns für das Update im nächsten Monat!
Aprilschauer haben sich in Texas in Mai-Hochwasser verwandelt! Wir wurden von schwerem Wetter und großen Überschwemmungen heimgesucht, wie Sie vielleicht in den Nachrichten gesehen haben. Glücklicherweise ist unser Studio von dieser Zerstörung weitgehend verschont geblieben und wir sind wie gewohnt vorangekommen. Wir haben neue Builds von Star Marine getestet und hart an der Arbeit am Persistent Universe und vielen technischen Aktivitäten gearbeitet. Hier sind einige detaillierte Berichte von den Leitern der einzelnen Teams.
Hartnäckiges Universumsteam
Kunst
Das PU Art Team hat in diesem Monat wie gewohnt in vielen Bereichen des Projekts mitgewirkt. Einer unserer Schwerpunkte war die Verlegung der Landezone Nyx>Delamar>Levski in die Final Art Phase. Wir sind jetzt an der Greybox-Phase vorbeigekommen und die Umgebung sieht fantastisch aus. Art Director Mark Skelton, Lead Artist Patrick Thomas und Global Environment Lead Ian Leyland haben eng mit BHVR zusammengearbeitet, um diese Umgebung wirklich zu einem Erlebnis zu machen. Der VFX-Künstler Lee Amarakoon und der Lichtkünstler Marc Toscano waren damit beschäftigt, dieser Umgebung einen zusätzlichen Hauch von Nebel, Rauch und Licht hinzuzufügen, um ihr Leben einzuhauchen. Wir können es kaum erwarten, euch an zwielichtigen Hintertürchen teilhaben zu sehen, Dinge auf dem Schwarzmarkt zu verkaufen und die gewundenen Asteroiden-Tunnel zu durchqueren, die diese Umgebung zu bieten hat.
Ein weiterer Schwerpunkt lag auf der Optimierung der Landezone Stanton>ArcCorp>Area18 für eine bessere Leistung in Vorbereitung auf das Social Module Release. Der extrem hohe Detaillierungsgrad und die Genauigkeit, die unsere Umgebungen so erstaunlich machen, sind ziemlich anstrengend für die Leistung, aber mit dem Einsatz neuer Technologien aus unserem Grafikteam sind wir in der Lage, unsere Leistung mit verschiedenen Mitteln erheblich zu verbessern.
Der Konzeptkünstler Ken Fairclough hat ein Konzept für eine Sicherheitsturmstütze entwickelt, die schließlich auf Landeplätzen wie ArcCorp zu finden sein wird. Diese Sicherheitstürme werden dazu dienen, Spieler zu bestrafen, die ihre Waffen in Gebieten ziehen, die ihnen das nicht erlauben. Sie werden auch als Abschreckungsmittel für Trolle und Trauernde dienen, die denken, dass es eine gute Idee ist, das Feuer auf zufällige Zivilisten zu eröffnen.
Unser Charakter-Team hat den Support für die FPS-Charaktere abgeschlossen. Die Marines und Outlaws befinden sich an einem Punkt, an dem wir ihnen Adieu gesagt haben, und jetzt hat sich unsere Aufmerksamkeit auf die Entwicklung der Charaktere verlagert, die beim Spielen von SATABall in der Astro Arena zu sehen sein werden. Wir haben einige ziemlich clevere neue Konzepte, von denen wir gearbeitet haben und die in den nächsten Wochen abgeschlossen werden sollten. Unser Charakter-Team hat auch einige Forschungs- und Entwicklungsarbeiten zu Haar und austauschbarer Kleidung für das kommende Social Module Release durchgeführt.
Das Austin Animation Team hat auch verschiedene Bereiche des Projekts unterstützt. Wir hatten alle Hände voll zu tun, um alte PU-, FPS- und Arena Commander-Animationen auf unser neues Skelett zu übertragen. Wir haben auch Unterstützung bei der Verbesserung der G-Force-Animationen und beim Testen des Grabby Hands-Systems geleistet. Senior-Animator David Peng hat sich zu 100% darauf konzentriert, Cockpit- und Kanonenvorlagen an die neuen Proportionen des Charakters anzupassen. Wir haben jetzt 7 Cockpittypen und 20 Tastenkombinationen, aus denen unsere Künstler bei der Erstellung von Cockpits wählen können.
Design
Ein Großteil der Zeit, die Design in diesem Monat damit verbracht hat, einige unserer anderen Berufe zu vertiefen, die die Spieler schließlich in der PU übernehmen können. Tony Zurovec verbrachte einen Großteil seiner Zeit damit, die Besonderheiten der Pioniertätigkeit (ehemals Exploration) zu ergründen und wie sie sich auf die Funktionalität eines zukünftigen Schiffes bezieht. Rob Reininger absolvierte einen ersten Durchgang darüber, wie die Söldner-/Sportlerbesetzung funktionieren würde, während Nate Blaisdell und Evan Manning die Berufe Kopfgeldjäger bzw. Schmuggler anpackten. Diese Entwürfe liegen nun bei Tony Z zur Überprüfung vor und werden nach der Genehmigung zusammen mit Andrew Nguyen in die Warteschlange gestellt, um das Gameplay zu implementieren.
Tony Z beendete auch seinen ersten Entwurf des neuen Universumssimulators (früher der Wirtschaftssimulator) und leitete ihn an das Team drüben in Wyrmbyte weiter. Das neue Design beinhaltet viel mehr als nur das ökonomische System, das in der PU enthalten sein wird, jetzt auch Dinge wie die Fähigkeit, Elemente und Verbundwerkstoffe zu erzeugen, die Fähigkeit, einen Planeten innerhalb eines Sonnensystems zu erschaffen und ihm Daten zuzuweisen, und die Fähigkeit, Berufe für NSCs zu schaffen und die Ausführungslogik für jeden Beruf festzulegen.
Mark Skelton und Tony Z trafen sich zusammen mit Lead Writer David Haddock mit BHVR, um Entwürfe und Layouts für die kommenden Standorte am Planetenrand zu besprechen. Konkret war unser Augenmerk in diesem Monat auf Magnus>Borea>Odyssa und Helios>Tangaroa>Mariana gerichtet. Beide Standorte werden unserem ohnehin schon beeindruckenden Stall von Landeplätzen mehrere neue, spannende Möglichkeiten und Vielfalt bieten. Wir werden einige spannende Looks mit euch teilen, wenn es online geht. Nächsten Monat werden wir uns auf die anderen Landezonen innerhalb des Stantonssystems konzentrieren: Crusader, Hurston und MicroTech.
Ingenieurwesen
Der Monat Mai war ein sehr arbeitsreicher Monat für das Engineering Team hier in Austin und für das Wyrmbyte Team. Viele große Ticketartikel waren fertig und bereit für den ersten Test.
Ein großer Punkt, auf den alle gewartet haben, ist unser neuer Generic Instance Manager, der deutliche Verbesserungen in Systemen wie Matchmaking und Party verspricht. Dies wurde von Jason Ely entworfen, und er brachte es mit starker Unterstützung von Tom Sawyer nach Hause. Wir werden erste Tests auf diesem neuen System durchführen, das Teil des kommenden FPS-Release sein soll.
Inzwischen...drüben bei Wyrmbyte...Scott Brown, Nathan Gray und Ryan Seabury haben an unserem Universums-Simulator gearbeitet und sind dabei, eine Proof-of-Concept-Iteration mit Basisfunktionalität zu liefern. Der nächste Schritt ist, dies weiter auszubauen, bis wir eine Arbeitsdemo erstellen können, die wir intern für weitere Diskussionen darüber austauschen können, wie wir darauf aufbauen können. Gleichzeitig arbeitet Ian Guthrie an der ersten Iteration unseres Sonnensystem-Servers und wird in Kürze eine erste Iteration davon abschließen. Das Wyrmbyte-Team hat auch eine Neufassung unseres Player Info Servers und unseres Presence Servers im Mai geliefert und arbeitet weiterhin an seinem iPredictor Schiffs- und Raketenbewegungssystem.
Unsere anderen Ingenieure waren auch sehr beschäftigt... Tom Davies hat v1.0 unseres Useable Editor für unsere NPC KI-Anforderungen fertiggestellt, und Jeff Uriarte macht solide Fortschritte mit dem Character Archetype Editor, einem weiteren Werkzeug für unser Designteam. Andrew Nguyen war in der Forschung und Entwicklung tätig und bereitete sich auf das erste Prototyping eines anderen Berufes vor (vorläufig "Discover" genannt), und er hat gerade einen ersten Prototyp für den Bergbau-Beruf abgeschlossen.
Brian Mazza war tief in der entscheidenden Arbeit, die vom gesamten Team benötigt wurde, wie z.B. die Implementierung von Google Brakepad für bessere Crash-Berichte, die Portierung unseres Universe Backends und die Behebung von Serverfehlern, die den Teamfortschritt blockierten und die Stabilität des Build verhinderten. Gegenüber von Brian hat James Wright eng mit QA zusammengearbeitet, um die Leistung unserer verschiedenen Builds zu profilieren und zu analysieren, einschließlich eines aktuellen PTU-Builds und unseres anstehenden FPS-Builds. Diese Daten helfen uns, Problembereiche zu identifizieren, die Aufmerksamkeit erfordern, um die Gesamtleistung zu verbessern. Und James hat Clive Johnson (der kurz davor steht, seine Arbeit an der Implementierung unseres Unique Global Entity ID-Systems abzuschließen) und George Kidd vom britischen Team rekrutiert, um einige der kritischen Performance-Probleme zu untersuchen, die in seinen Profilergebnissen aufgedeckt wurden.
Auf der Tool-Seite hat Benjamin Bechtel eine neue, verbesserte Version seines Asset Validation Tools mit einer völlig neuen Benutzeroberfläche eingeführt. Dieses Tool wird täglich von unseren Künstlern verwendet. Benjamin erwartet im Juni auch einen Besuch des britischen Werkzeugingenieurs Ashly Canning, um gemeinsam an unserem Dataforge Tool zu arbeiten. Sean Tracy und Jeffery Zhu haben die erste Phase ihrer Stream-Restrukturierung eingeleitet, die wesentlich dazu beitragen wird, unsere Stream-Ströme zu rationalisieren, indem sie unsere Entwicklungsströme bis hin zu unserem Live-Produkt führen. Schließlich haben diese beiden Herren viel Zeit und Mühe darauf verwendet, Cort Soest bei unserer dringend benötigten und überlangen Aufgabe der Bereinigung unserer Perforce-Daten zu unterstützen. Die ersten beiden Phasen dieser Aufgabe sind im Mai abgeschlossen.
Das Team erwartet den Juni und freut sich darauf, seine Unterstützung für die bevorstehende FPS-Veröffentlichung sowie die weitere Arbeit an unserem kommenden Sozialmodul anzubieten.
Live-Betrieb
QA
Für das QS-Team begann May mit dem Testen und Freigeben von 1.1.2 und anschließend 1.1.3.
Mit Hilfe unseres Senior Engine Programmierers James Wright führten wir einen speziellen PTU-Test durch, der einen separaten Server-CPU-Thread zur Berechnung der Physik verwendete. Die Ergebnisse zeigten signifikante Leistungssteigerungen während der Spiele.
Es wurden Änderungen an der Art und Weise vorgenommen, wie wir verschiedene Streams und Zweige mit Perforce, unserer Versionierungskontrollsoftware, verwenden. Dies wird zu einem wesentlich strukturierteren und reibungsloseren Prozess der Release- und Feature-Integration beitragen. Dies hat auch zu einer erhöhten Arbeitsbelastung für die Qualitätssicherung geführt, um sicherzustellen, dass diese zusätzlichen Streams oder Zweige des Spiels und des Editors ordnungsgemäß getestet werden. Das Team leistet jedoch hervorragende Arbeit, um sicherzustellen, dass diese zusätzliche Testanforderung erfüllt wird.
Unsere FPS-Spezialisten waren sehr damit beschäftigt, sicherzustellen, dass Star Marine jeden Tag ordnungsgemäß getestet wird. Das Team hatte das Glück, direkt an den Designchef Todd Papy Feedback geben zu können. Todd reagierte sehr schnell auf jeden angesprochenen Punkt. Nachdem er diese Punkte besprochen hatte, beauftragte Todd alle vereinbarten Änderungen und legte Prioritäten fest. Als QA ist es sehr erfüllend, so ein Teil der Entwicklungsrichtung sein zu können.
In der Zwischenzeit hat Todd Raffray dafür gesorgt, dass das Sozialmodul ordnungsgemäß getestet wird. Todd hat einen großartigen Job gemacht, um sicherzustellen, dass alle Funktionen in einer umfassenden Checkliste dokumentiert und kontinuierlich getestet werden, während sie online gehen.
Herzlichen Glückwunsch an Miles Lee, dass er mit unserem DevOps-Team in die Rolle eines offiziellen Associate Engineers gewechselt ist! Miles hat hervorragende Arbeit geleistet und dazu beigetragen, ein Framework für die Testautomatisierung zu schaffen. Wir können nun Leistungsdaten erfassen und die meisten unserer Stabilitätsprüfungen für jeden Build automatisieren, sobald sie verfügbar sind.
Das Team drehte ihre erste Episode eines speziellen QA-Segments mit Community, wo sie einige ihrer Lieblingsfehler präsentierten.
Das Team hatte auch das Glück, an der Launch-Party der University of Texas Denius-Sams Gaming Academy mit ihrem ersten offiziellen Release namens "The Calm Before" teilzunehmen. Wir hatten viel Spaß beim Spielen! Ihr Team ist sehr talentiert. Zögern Sie nicht, sich den kostenlosen Download anzusehen!
Es war ein arbeitsreicher Monat für uns in der QA. Nächsten Monat werden wir uns intensiv mit dem Testen von Alpha 1.2 beschäftigen, um uns auf die bevorstehende Veröffentlichung vorzubereiten.
Spielunterstützung
Dieser Monat war für den Game Support sehr arbeitsreich, da wir auf einigen der Arbeiten von März und April aufgebaut haben.
Im Monat Mai wurden auch zwei Updates für den Arena Commander veröffentlicht (1.1.2 und 1.1.3). Update 1.1.2 half den Spielern bei den gefürchteten Problemen mit dem Match Not Found, Kicked Back to Lobby und Infinite Load Screen, und 1.1.3 unterstützte sie bei den anhaltenden Problemen mit dem "Gummibanding", bei denen die Spieler um die Karte sprangen. Dies ist erst der Anfang unserer Optimierungen, und wir wissen, dass Sie gespannt sein werden, wie wir Ihre Informationen weiterhin nutzen, um das Spielerlebnis zu verbessern.
In diesem Zusammenhang haben wir auch einen unglaublich erfolgreichen Playtest auf PTU mit 1.1.2 durchgeführt. Die Spieler haben sich in den PTU-Dienst gestopft, um uns zu helfen, Stresstests durchzuführen und wichtige Serveranalysen zu sammeln, und auf dem Weg dorthin hatten wir eine absolut EPIC 8v8-Runde von Spielen, die eine Runde von Diskussionen und internen Aufgaben darüber ausgelöst hat, was wir tun können, um die Spielerkappe zu erhöhen.
Im Hinblick auf den weiteren Aufbau und die Skalierung unserer Support-Betriebe für Sie war einer der größeren Punkte in diesem Monat die Schaffung einer internen Workflow- und Wissensdatenbank, die unsere Möglichkeiten, Ihnen zu helfen, erheblich erweitert. Durch die interne Veröffentlichung einer vollständigen Matrix möglicher Probleme, Fehlerbehebungsmethoden und Lösungen konnten wir mehr Mitarbeiter im Unternehmen schulen, die bei technischen Problemen helfen. Das bedeutet, dass wir einer größeren Anzahl von Menschen in kürzerer Zeit helfen können und bietet eine fantastische Grundlage für die Erweiterung unseres Teams auf dem Weg in die Sternenmarine, das Sozialmodul, die Staffel 42 und schließlich das Persistente Universum.
Wir haben auch begonnen, mit Turbulent zusammenzuarbeiten, der zwei große Initiativen für den Game Support vorantreibt: Der Community Bug Council (eine VIEL verbesserte Möglichkeit für Spieler, Beiträge einzureichen und zu sehen, welche Fehler im System aktiv sind) und eine neue, überarbeitete Version der Live Service Notification Seite, die eine begehrte Server Status Seite enthalten wird.
Sie werden in den kommenden Wochen mehr über diese beiden Punkte erfahren, aber beide sind auf unsere größeren Ziele ausgerichtet, Ihnen so schnell wie möglich genauere Informationen über den Zustand des Dienstes zu liefern.
IT/Betrieb
Der Mai war ein Monat der Geschwindigkeit für die IT. Die IT-Gruppe arbeitet hart daran, mit den wachsenden Infrastrukturanforderungen der Entwicklungsteams Schritt zu halten, und die Leistung der zentralen Speichersysteme in jedem Studio ist weiterhin eine unserer Prioritäten. Letzten Monat konzentrierten wir uns auf die interne Build-Replikation an Studios aus dem Build-System in Austin. Diesen Monat haben wir unseren Fokus auf die Leistung der zugrunde liegenden Hardware im Austin Build System selbst gelegt. Ziel dieses Projekts ist es, die Zeit für die Erstellung von Builds deutlich zu verkürzen. Die Verkürzung der Buildzeiten beschleunigt die Entwicklung und das interne Testen, aber die gesamte Build-Pipeline ist groß und komplex, so dass wir uns diesem Problem aus verschiedenen Blickwinkeln nähern.
Der erste auf der Liste war die Leistung des Speichers, auf dem die Build-Systeme laufen. Das Build-System kompiliert natürlich Code und Assets für das Spiel und die meisten dieser Arbeiten schieben die Festplatten wirklich hart. I/O-Wartezeiten können auf normalen Systemen durch die Decke gehen, und da unser Build-System viele Builds parallel kompiliert, haben wir viel Zeit verloren, indem wir nur darauf gewartet haben, dass die Festplatten aufholen. Um dieses Problem zu lösen, haben wir einen benutzerdefinierten Server mit allen Flash-Speichern und speziellen Controllern gebaut, um unsere IOPS weit über unsere aktuellen Bedürfnisse hinaus zu entwickeln. Diese eine Verbesserung unseres Build-Systems hat beeindruckende Ergebnisse mit einer Reduzierung der Buildzeiten um 66% gezeigt.
Als nächstes planen wir, weitere Sekundärsysteme auf Schnellspeicher umzustellen, was zu zusätzlichen Reduzierungen führen sollte. Schließlich werden wir parallele Verarbeitungsmethoden integrieren, um mehr CPU-Kerne in den Build-Prozess einzubringen. Dieser Schritt und einige potenzielle Ressourcen-Cachings sollten unsere Buildzeiten von Stunden auf Minuten reduzieren.
Wir haben auch eng mit DevOps zusammengearbeitet, um unsere Gebäudeautomationssysteme zu verbessern, die unserem aktuellen System Stabilität und Benutzerfreundlichkeit verleihen werden. Wir hoffen, dass wir den Rest dieser Änderungen in den nächsten Wochen umsetzen können. Im Moment sind wir sehr zufrieden mit den ersten Ergebnissen und ich denke, jeder ist gespannt, wie schnell wir diese Builds jetzt umsetzen können.
Dev Ops
Wir haben diesen Monat zwei Patches veröffentlicht, Patch 1.1.2.2 und 1.1.3, und beide wurden an einem Freitag veröffentlicht! Unser Team wird weiterhin mit dem Unternehmen zusammenarbeiten, um zu versuchen, diese Bereitstellungen auf Dienstag als Industriestandard einzugrenzen, und dann hoffentlich im Laufe einiger Jahre in eine kontinuierliche Bereitstellungspipeline übergehen, die die Notwendigkeit von Ausfallzeiten eliminieren sollte (viel davon hängt von unserem endgültigen Datenbankdesign ab).
Wir haben bei den Deployment Playtests des FPS geholfen und diese Möglichkeiten genutzt, um unseren neuen Launcher und Patcher zu testen. Bisher waren die Tests positiv, aber wir müssen noch einige weitere Polierdurchgänge durchlaufen, bevor wir sie in die PTU verschieben, damit jeder sie benutzen kann. Die Entwicklung des Launcher wird in drei Phasen unterteilt. Der erste, eine PTU-Phase, wurde bereits erwähnt. Dieser nimmt die bestehende Benutzeroberfläche und kombiniert sie mit unserem neuen Patcher. In der zweiten Phase wird eine komplette Überarbeitung des Launcher in C++ erfolgen. In Kombination mit dem neuen Patcher und der alten Benutzeroberfläche wird es Stabilitätsverbesserungen aufweisen, aber ähnlich wie der aktuelle Launcher und der kommende PTU-Launcher aussehen und funktionieren. Die dritte Phase wird eine komplett neue Benutzeroberfläche auf Basis des C++-Kerns und Patches sein. Die Einführung dieser Phasen wird mehrere Monate dauern, und weitere Informationen zu jeder Phase werden in Kürze veröffentlicht.
Schließlich ist eine Menge Arbeit damit verbunden, wie Daten im Unternehmen erstellt, gespeichert und konsumiert werden. Wir untersuchen, wie wir Zweige in Perforce verwenden, wie Daten auf den Build-Server kopiert werden, welche Daten ausgeschlossen sind, wie Entwicklungsleiter diese Daten betrachten. Initiativen für bessere Perforce-Tools, ein Ausschlusstool und einen neuen Build-Server haben die Teamzeit zusätzlich in Anspruch genommen. Der Build-Server ist ein besonders großes Projekt, das wir bis zum 14. Juli abgeschlossen haben wollen. Zu diesem Zweck ist einer der Ingenieure des Frankfurter Studios nach Austin geflogen, um in den nächsten drei Wochen mit uns zusammenzuarbeiten, damit wir an Implementierungsideen arbeiten können.
Die Arbeit an der Fertigstellung unseres Datenbankmodells und der Containerisierung der Server musste auf Eis gelegt werden, während wir unsere Tools fertig stellen, die alle von den Studios verwendeten Daten verarbeiten. Wir werden auf diese Themen zurückkommen, wenn unsere derzeit in der Entwicklung befindlichen Tools fertig sind und wenn unser Server-Team mit der Arbeit am Persistenzdienst beginnt, der die wichtigste Schnittstellenschicht zur Datenbank sein wird. Hoffentlich wird diese Arbeit in den Bericht vom Juni aufgenommen!
Hallo zusammen! Hier in der Gießerei 42 arbeiten wir an allem, vom Arena Commander (Multicrew) bis zur Staffel 42. Chris Roberts hat den letzten Monat in einem anderen Teil Englands verbracht, um die Leistung der Staffel 42 zu erfassen.... und wir arbeiten eng zusammen, um sicherzustellen, dass die dort generierten Daten in Kinofilme verwandelt werden, die Sie umhauen werden! Hier ist die Aufteilung der Abteilung nach Abteilungen, was diesen Monat in Manchester geschah:
Animation
Hier in Großbritannien arbeiten wir immer noch daran, die Bedürfnisse unserer Designer zu erfüllen. Während die Direktoren von Imaginarium weiterhin die Daten erfassen, die wir benötigen, sind wir damit beschäftigt, Block-Out-Animationen für die Design- und Code-Abteilungen bereitzustellen, um mit dem Prototyping und der Implementierung der Mechanik zu beginnen.
Wir arbeiten auch mit den verschiedenen Studios weltweit zusammen, um die Tools zu rationalisieren, die wir alle benötigen, um effizient und effektiv arbeiten zu können, um die für Squadron42 und darüber hinaus gesetzten Ziele zu erreichen.
- UK Lead Animator, Uisdean Ross.
Ingenieurwesen
Im Vorfeld
Konversationssystem: Wie üblich gab es in diesem Monat viel Arbeit am Konversationssystem zu erledigen, wobei die Highlights die Korrektur von NPC-zu-NPC-Gesprächen und der Multiplayer-Aspekt des Konversationssystems waren, der einen ersten Durchgang zur Vorbereitung auf das Sozialmodul erhielt. Auch die Schriftart der Untertitel wurde verbessert, und es wird an einer Überarbeitung der Benutzeroberfläche der Player-Auswahl für verzweigte Gespräche gearbeitet. Für die Staffel 42 haben wir jetzt Text-to-Speech im Einsatz, was sehr nützlich für das Prototyping von Gesprächen ist, da mehr Dialog zu diesen Ebenen hinzugefügt wird. Die Arbeiten an der Animationsseite des Systems sind ebenfalls im Gange, mit Hilfe des Austin-Studios, um das System bereit zu machen, alle schönen Bewegungsdaten zu empfangen, die uns zur Verfügung stehen.
PAW (Personal Arc Welder). Diese Waffe/Gerät ist etwas Besonderes, denn aufgrund ihres Verhaltens kann sie für mehrere Dinge verwendet werden. Wir haben uns sowohl in technischer als auch in gestalterischer Hinsicht konzentriert. Was den technischen Teil betrifft, so wurde die Schneidtechnologie verbessert, um unser Schadenssystem zu nutzen, so dass jetzt alles realistischer ist, und zwar jetzt kann man sehen, wie Oberflächen durch die Energie der PAW beeinflusst werden. Darüber hinaus wurde eine vollständige Überprüfung des Zielsystems durchgeführt, die es uns ermöglicht, z.B. das Laservisier zu aktivieren oder zu deaktivieren, sein Verhalten zu ändern, etc.... Schließlich, wenn wir über Design und Neugestaltung sprechen, haben wir verschiedene Effekte wie den Strahl und den Punkt im Zielsystem (Laservisier) geändert und wir haben neue hinzugefügt, wie den Aufpralleffekt und andere Partikel.
Plünderungssystem. In diesem Fall haben wir uns auf einige technische Änderungen konzentriert. Das vorherige Plünderungssystem basierte auf Gegenständen, so dass für uns eine Entität eine Gruppe von Gegenständen war, die wir nehmen konnten. Aber wir wollten etwas Stärkeres, um Gegenstände nicht nur zu nehmen, sondern auch zu platzieren, also haben wir uns für das Item-Port-System entschieden (das Item-Port-System ist eine sehr leistungsfähige, flexible Methode, um zu definieren, wie Gegenstände aneinander befestigt werden können). Infolgedessen plündern wir jetzt eine Entität, nicht unbedingt einen Körper, und suchen, welche Art von Ports sie hat, und wir können Elemente aus diesen Ports nehmen und Elemente darauf platzieren. Zusammenfassend lässt sich sagen, dass wir ein bestimmtes System in etwas Allgemeineres und Mächtigeres verwandelt haben.
Hydraulische Türen. Die hydraulischen Türen sind eine Erweiterung einer normalen automatischen Tür. Diese haben jetzt die Möglichkeit, "computergesteuert" zu sein, so dass wir Funktionen haben, bei denen wir die Tür in beide Richtungen verriegeln können. Wir haben nun eine neue Sicherheitsmethode für Spieler mit den richtigen Sicherheitsprivilegien hinzugefügt, die in der Lage sind, Türen zu verriegeln und zu entriegeln und die Mechanik der Verriegelung und manuellen Übersteuerung zu verfeinern. Die Überbrückungsmechanik an einigen Türen ermöglicht es dem Spieler, mit seiner PAW einen Abschnitt auszuschneiden und eine manuelle Hydraulikpumpe zum Öffnen der Tür von Hand zu entdecken. Diese Türen wurden auch in die Kleiderbügel gerollt, um sie so zu vereinen, dass sie überall das gleiche System verwenden.
Medpack: Ein Medpack-Element wurde für die Verwendung in den FPS-Spielmodi hinzugefügt, um die Gesundheit des Spielers wiederherzustellen. Bei Verwendung führt der Spieler eine Kampfheilung durch, indem er die Spritze wie einen Gegenstand in der Hand greift und sie in einen Port in seiner Rüstung spritzt. Eine solche Heilung verteilt die Erholung gleichmäßig auf alle Gliedmaßen.
Sammlerstücke: Sammlerstücke gibt es in zwei Formen, entweder Gegenstände, die auf die gleiche Weise wie der Plünderer aufgenommen werden können, oder Gegenstände, die nach Informationen gescannt werden, die beide zu deinem Inventar hinzugefügt werden. Beispiele dafür können Technikelemente sein, die nach einem Geldwert durchsucht werden können, oder Dog Tags, die Charakterprofile freischalten können. Diese Gegenstände befinden sich verstreut in verschiedenen Bereichen der Staffel 42.
Grafiken
In diesem Monat hat das Grafikteam vor allem an mehreren verschiedenen Bereichen parallel gearbeitet. Wir sind kurz davor, ein automatisiertes System für die Künstler zu entwickeln, das intelligent Netze findet, die in der Umgebung zusammengefügt werden können, um die Leistung zu verbessern. Da große Teile unseres Levels aus modularen Kits bestehen (damit wir die für das PU benötigte Menge produzieren können), haben wir am Ende mehr Meshes, als CryEngine, DirectX und der Grafiktreiber verarbeiten können. Das Zusammenführen von Netzen reduziert die Gesamtzahl der Objekte in der Ebene, würde aber dazu führen, dass eine einzige Ebene mehrere Gigabyte RAM benötigt, und so wertet unser Algorithmus alle möglichen Zusammenführungsoperationen aus, die wir durchführen könnten, und führt nur diejenige aus, die uns die meiste Leistung bei geringsten Speicherkosten ersparen würde. Der Algorithmus führt die besten Kandidaten weiter zusammen, bis er ein vom Künstler festgelegtes Speicherbudget oder eine vom Künstler festgelegte Leistungsgrenze erreicht. Das Endergebnis ist eine massive Einsparung der Anzahl der Objekte und damit der Leistung, bei minimalen Speicherkosten und ohne zusätzlichen Aufwand für den Künstler.
Das VFX-Team wurde in den letzten Monaten durch verschiedene Einschränkungen und Fehler in der Partikelbeleuchtung behindert, und so waren einige unserer Mitarbeiter damit beschäftigt, die Partikelbeleuchtung zu verbessern, was dazu führen sollte, dass die VFX-Künstler in der Lage sein sollten, Effekte zu erzeugen, die viel besser in der Umgebung sitzen. Der Rest unseres Teams hat die vielen Fehler, die wir vor jeder Veröffentlichung erhalten haben, bearbeitet, und diesmal sind es FPS-bezogene Fehler in Bezug auf Leistung, Streaming und Feldverbesserungen. Wir haben auch einige Korrekturen für das Rendering der "großen Welt" vorgenommen, die es der CryEngine ermöglichen, mit praktisch unbegrenzten Kartengrößen zu arbeiten.
Design
In diesem Monat hat das britische Design seine Arbeit an mehreren Kapiteln der Staffel 42 fortgesetzt, um sie der Greybox näher zu bringen. Die Hauptpriorität des Teams liegt derzeit auf dem Mocap-Shooting, das derzeit in London stattfindet. Jeder Designer konnte die erstaunlichen Leistungen unserer Darsteller in ihren eigenen Levels erleben, die selbst auf einer Whitebox-Bühne unglaublich aussehen und die Welt, die wir bauen, noch viel mehr zum Leben erwecken!
Der interne Vertikalschnitt macht ebenfalls große Fortschritte und hilft uns, wichtige Fragen zu unseren Kern-Gameplay-Mechanismen zu beantworten und unsere Funktionen für Erfahrungs-, Nahkampf- und FPS-Szenarien zu entwickeln.
Darüber hinaus unterstützt das britische Designteam auch alle anderen Bereiche von Star Citizen, wie Sie sicherlich gesehen haben, mit Arena Commander, Waffen, Schiffen und dem kommenden FPS-Modul, das uns alle beschäftigt!
Kunst
Nun, was soll ich sagen, für diejenigen, die es gewagt haben, sich die durchgesickerten Inhalte anzusehen, können Sie sicherlich sehen, dass wir Ihre hart verdienten Dollar sinnvoll einsetzen, um den besten Inhalt zu machen, den wir können! Wenn du gut warst und dich selbst rettest, dann sei es gut zu dir! Wir werden dir sicherlich etwas liefern, das sich für deine anhaltende Abstinenz lohnt.
Jeder Monat ist hier sehr arbeitsreich, es gibt keine Minute, die nicht voller Entscheidungen oder Poly oder Pixel-Push ist, die Schiffskonzeptarbeit beginnt sich zu reduzieren, es ist vor allem das seltsame Bild hier und da, um alle Bereiche zu klären, die wir früher verpasst haben, die Vanduul-Flotte hat alles mit nur den Waffen/Türmen konzipiert, die ausgearbeitet werden müssen. Wir haben von Jan Urschel und AtomHawk gute Arbeit auch in Umgebungen geleistet, was die Sq42-Handlung wirklich mitgestaltet.
Umgebungen
Unser Hauptaugenmerk für diesen letzten Monat lag auf der Weiterentwicklung unseres Vertikalschnittlevels und der Unterstützung des Shooting-Events in London. Für die VS haben wir uns bemüht, einen Detaillierungsgrad zu erreichen, der für Star Citizen geeignet ist. Besonderer Wert wurde auf die Spielerdurchquerung durch die Szene gelegt, lohnende Erkundungen, großartige Ausblicke und Kompositionen und natürlich hochwertige Kunstwerke. Für das Shooting haben wir sichergestellt, dass Szenen, in denen Auftritte festgehalten werden, am Set korrekt funktionieren und diese immer wichtigen Änderungen in letzter Minute vornehmen. Die Spannung ist sowohl am Set als auch im Studio groß, wir können es kaum erwarten, es euch zu zeigen.
VFX
Wir hatten einen ganzen Monat lang Code-Support von den Grafikern, die einen beeindruckenden Rückstand an Bugs und Feature-Anfragen beseitigt haben. Wir haben auch einen weiteren VFX Artist gewonnen, so dass das Team wächst! Dies hat es uns ermöglicht, in mehreren Bereichen voranzukommen, unter anderem:
Squadron 42 Umwelt-VFX-Varianten, nämlich: Funken Dampf Feuer/Schaden Weltraumstürme (Vorsicht, es ist gefährlich da draußen!) F&E für große Turm VFX - Mündungsfeuer, Leuchtspuren, Stöße usw. F&E für die Staffel 42 Kinematiken, die typische Arbeitsabläufe und Pipelines testen. Verschiedene Schiffseffekte. Auf einer etwas weniger spannenden (aber dennoch wichtigen) Seite haben wir auch hinter den Kulissen hart daran gearbeitet, unsere Workflows und Pipelines zu verfestigen und die VFX-Roadmap zu konkretisieren, damit wir die Vielzahl der Off-Effekte in allen Bereichen des Star Citizen-Universums gut im Griff behalten können!
Schiffe
Oh die Schiffe, die Schiffe - immer unsere Top-Künstler auf Trab halten - die Idris, ja, es kommt gut an, vielleicht sogar ein paar Überraschungen (ich weiß, dass du sie liebst), es gab eine Menge Arbeit, um die Designsprache der Schiffe in eine kohärente Form zu bringen, so dass weiter unten in der Linie klar ist, welcher Hersteller was macht, welchen Stil die Panel-Linien haben, welche Art von Leuchten, die Liste ist groß, aber zumindest wird es für interne und externe Künstler klar sein, was sie erreichen müssen.
Starfarer-Innenraum blockiert, ARGO braucht einen Shaderpass, Mining Drone fährt fort, ja, die Jav wurde noch nicht gestartet, wir sind an der maximalen Kapazität, bis wir mehr Personal finden - kommt mit und macht den BDSSE :)
UI
Das Team hat sich um 100% erweitert - wir sind von einem auf zwei Künstler übergegangen! Die Arbeit an der Benutzeroberfläche des FPS wurde fortgesetzt und nun wird der Stil erkundet und nach Shubin, Aegis und Vanduul gesucht - schauen Sie sich diesen Raum an.
Charaktere
Das Charakter-Team war neben dem Imaginarium-Shooting mit dem Kamerarigg vor Ort in London und wir hatten einen absoluten Spaß! Jede Scan-Sitzung hat Spaß gemacht und war spannend, und wir haben es geschafft, einige wirklich weltweit führende Daten über einige wirklich erstklassige Talente zu erfassen. Sie sagen, dass man seine Helden nie treffen sollte, aber ich stimme völlig nicht zu und jeder von ihnen war freundlich, professionell und enthusiastisch.
Die Daten wurden bereits verarbeitet, und einige von Ihnen haben vielleicht bereits einige der Aktionen aus unserer Scan-Sitzung mit Sandi gesehen, was ein gutes Beispiel für die Energie und den Antrieb ist, den wir bei diesem Projekt haben.
Ich wünschte nur, ich könnte dir sagen, wer in unserer Anlage gesessen hat!
Audio
Hey zusammen! Auf der CIG-Audio-Seite haben wir hauptsächlich mit unserem Bestreben, mit Wwise zu veröffentlichen, weitergemacht. Es gibt noch viel zu tun, aber wir machen Fortschritte.
Ich denke, es ist fair zu sagen, dass wir feststellen, dass in Bezug auf das Engineering viele Aufräumarbeiten erforderlich waren. Wir dachten (vielleicht optimistisch), dass die meisten Systeme einfach nur Wwise Events erzeugen müssten, die auf die gleiche Weise ausgelöst wurden wie ihre Äquivalente in FMOD, und los geht's, alles erledigt! Das ist jedoch selten der Fall gewesen, und je mehr du grabst, desto mehr findest du heraus, was getan werden muss.
Es ging also ebenso sehr darum, eine Bestandsaufnahme zu machen, aufzuräumen, offene Fragen in Bezug auf Sounddaten, Code und Logik zu klären, wie sicherzustellen, dass Wwise Events und Sounds einfach existieren. Es gibt bestimmte Dinge, die unter FMOD funktionierten, die in dieser Art und Weise funktionierten, aber mehr trotz aller Dinge als durch Design. Dies ist nicht auf die Schuld von jemandem zurückzuführen, nur dass Audio oft auf Projektänderungen spät am Tag der Entwicklung des Spiels reagiert hat.
So weit wie möglich haben wir die Gelegenheit genutzt, um sicherzustellen, dass dieser Wechsel zu Wwise eine Verlagerung von kurzfristigem, reaktivem Denken und Gestalten ist, und dass wir uns mehr darauf zubewegen, wie wir die Dinge angehen wollen - dem Spiel (buchstäblich) so weit wie möglich voraus zu sein: zum Beispiel Vorlagen in Wwise zu entwickeln, alles sauber und frei von Hacks zu halten. Wir haben unser Code-Team wieder zusammengebracht, ebenso wie unser in Austin entwickeltes Tech-Sound-Design, damit wir im Vorfeld von FPS am effektivsten Köpfe schlagen können. Das neue System zu entwickeln sowie das Dog-Fighting-Modul wieder auf den neuesten Stand zu bringen und verschiedene Aspekte des persistenten Universums zu unterstützen - diese Dinge wären schwer genug, um ohne die neue Audio-Engine auskommen zu können. Aber wir dürfen nicht zu viel meckern!
Leider hat uns einer unserer Senior-Sounddesigner, Tom, diesen Monat verlassen. Er hat ihn vermisst, da er über einen reichen Erfahrungsschatz in CryEngine verfügte, aber ihm wurde die Möglichkeit geboten, seinen Lieben näher zu kommen, und es ist schwer, damit zu argumentieren. Also geht er gut miteinander aus - wir wünschen ihm alles Gute für seine zukünftigen Bemühungen, er wird nicht leicht zu ersetzen sein.
In weiteren Nachrichten haben wir unsere neu errichteten Sound-Design-Räume, die größtenteils bezugsfertig sind. Wir müssen unsere akustische Behandlung noch richtig auf die Wände anwenden, und wir warten auf einige Möbel und Monitore (Monitore sind das, was die Audioleute Lautsprecher nennen, nur um alle zu verwirren), um anzukommen, aber es ist schön, diese Räume zusammenkommen zu sehen. Wir haben versucht, jedem von ihnen eine eigene Farbgebung zu geben, die entweder kreative Funken oder leichten Wahnsinn verursacht. Kommt auf den Raum an. Vielleicht werden wir von beidem ein wenig Zeuge! Sie müssen etwas optimiert und abgestimmt werden, um die Klangneutralität zu gewährleisten. Sie sind zugegebenermaßen ein wenig klein, was es schwierig macht, sicherzustellen, dass sie frei von stehenden Wellen usw. sind, die bestimmte Bänder des Audiospektrums falsch darstellen können. Wir kommen so nah ran, wie wir es praktisch können, aber wir brauchen nur ein wenig Zeit, um dorthin zu gelangen, wo sie sein müssen.
Wir haben versucht, uns rechtzeitig anzupassen, um mit Prozessen im Zusammenhang mit fremden Vocals zu experimentieren, mit denen wir begonnen haben, während die Linguisten den Aspekt der fremden Sprache immer wieder festhalten. Es ist immer eine knifflige Gegend, aber es erweist sich als sehr interessant zu sehen, was man tun kann, bevor man in das akustische Äquivalent des unheimlichen Tals kommt.
Außerdem waren wir vor Ort, um den laufenden Dreh für'Squadron 42' zu unterstützen, über den ich natürlich nichts sagen werde, also fragen Sie mich nicht;)
Danke, dass du dir die Zeit genommen hast, dich über alle Dinge bei CIG Audio zu informieren. Bitte stellen Sie ein oder zwei Fragen im Ask A Developer Forum und wir werden unser Bestes tun, um diese zu beantworten. Auf Wiedersehen für jetzt!
Das Frankfurter Team wächst stetig und ist in zahlreichen Disziplinen wie Basistechnologie, KI, Design, Cinematics, Audio, Animation, FX, etc. tätig. Wie in unserem Bürovideo letzten Monat zu sehen war, füllte sich unser Zeitarbeitsraum, wir haben einen weiteren Raum gemietet, um zusätzliche Mitarbeiter aufzunehmen. Wir haben uns auch darauf vorbereitet, in unser neues Büro einzuziehen, der offizielle Umzug wird Anfang Juli sein, und wir werden höchstwahrscheinlich ein neues Video veröffentlichen, sobald wir uns eingelebt haben. Wir sind erst seit ein paar Monaten Teil des globalen Teams, aber die Dynamik und der Fortschritt im gesamten Spiel aus allen Studios und Büros ist großartig zu sehen, und wir sind froh, dabei zu sein.
Ingenieurwesen
Für den Monat Mai war Frankfurt Engineering an mehreren Fronten beschäftigt. Wir haben große Fortschritte auf dem Gebiet der Großen Welt gemacht (Verschiebung der Codebasis auf 64-Bit-Koordinaten, so dass Galaxiengrößen (buchstäblich) in Star Citizen erstellt und erforscht werden können). Die Hauptaufgabe, die diesen Monat an Large World gearbeitet wurde, war es, die Rendering-Kamera relativ zu machen: Tatsächlich musste durch die Umstellung auf 64 Bit der gesamte Rendering-Code so geändert werden, dass er relativ zur Kamera ist und nicht mehr einfach in der absoluten Welt koordiniert.
Es gab auch viele Fortschritte beim Zonensystem, unserem neuen Raumgliederungssystem, das das alte oktare Raumgliederungsschema der CryEngine ersetzt. Das Zonensystem ist besonders geeignet für ein Spiel wie Star Citizen, das große, dynamische Karten, eine große Anzahl von Einheiten und große bewegliche Schiffe bietet. Apropos Mehrbesatzung: Wir haben auch an schiffslokalen Physikgittern gearbeitet (damit die Spieler in fahrenden Schiffen herumlaufen können), an Laufzeitvorabteilungen und an der Untersuchung von Entitätsoptimierungen und Streaming. Wir testen diese neuen Systeme zunächst mit dem Retaliator.
Wir begannen auch mit der Implementierung optimierter Asset-Speicherformate für Vertex-Daten, um die Gesamtdatengröße zu reduzieren, die Durchlaufzeit und den Speicher sowie die CPU/GPU-Leistung zu verbessern. Diese Optimierungen werden in Kürze umgesetzt.
Wir haben eine erste F&E-Diskussion zum Thema Prozesserzeugung begonnen, die später eine gewisse Zeit in Anspruch nehmen wird, nachdem die oben genannten Big-Ticket-Positionen alle vorhanden sind. Es gab viele Bereinigungen von veralteten CryEngine-Funktionalitäten, die wir für Star Citizen nicht mehr benötigen, wie den alten Level Heap, veraltete Renderknoten und viele andere kleinere Elemente. Zusätzlich haben wir daran gearbeitet, die relevanten Teile des neuen 3.7 SDK in unsere Codebasis zu integrieren. Alle diese Hauptaufgaben stehen nun kurz vor dem Erreichen der Hauptlinie des Star Citizen Codes. Darüber hinaus haben wir allgemeine Unterstützung, Funktionen und Bugfixes für den Motor bereitgestellt.
Wir haben auch unsere Speicherprofilierungstools aktualisiert und damit verbundene alte Kratzer aus dem gesamten Motorcode entfernt.
KI
Im letzten Monat haben wir eine solide Basis für alle zukünftigen Entwicklungen im Zusammenhang mit der Künstlichen Intelligenz in Star Citizen gelegt.
Wir begannen mit der Vereinheitlichung des CryEngine Kommunikationssystems mit dem CIG Contextual Reaction System. Was sind das für Systeme?
Das Kommunikationssystem wird verwendet, um KI-Charaktere sprechen zu lassen: Das Verhalten (oder ein anderes System) kann verlangen, eine bestimmte Kommunikationsleitung zu spielen (z.B. "GreetThePlayerInFronOfYou") und das System wird sich um eine geeignete Variante für dieses Konzept kümmern und eine geeignete Variante wählen (z.B. "Grüße mein Freund!") und überprüfen, ob das definierte Tempo tatsächlich das Abspielen des Audios ermöglicht. Das System ist auch für den korrekten Umgang mit einem Fall verantwortlich, in dem eine Kommunikationsleitung, die auf einem Kanal mit hoher Priorität abspielt, die aktuelle Nachricht löschen muss, wenn sie auf einem Kanal mit niedrigerer Priorität abspielt.
Das klassische Beispiel ist der NSC, der während des Sprechens geschlagen oder geschossen wird. Sein Schmerzensschrei sollte definitiv alles unterbrechen, was er vorher gesagt hat!
Das Contextual Reaction System wird verwendet, um eine Kommunikationsleitung auszulösen, die auf bestimmten, vom Spiel ausgelösten Ereignissen basiert. Ein Schiff, das stark beschädigt ist, kann ein "ShipsDamaged"-Signal ausstrahlen, das vom CRS empfangen wird, und es wählt eine geeignete Variante des Audios, das abgespielt werden muss. CRS ist bereits vollständig in Dataforge integriert, so dass die Autoren in der Lage sind, neue Inhalte ohne Codeunterstützung zu erstellen. In diesem Monat haben wir mit der Zusammenführung der neuen Systeme begonnen, um von beiden zu profitieren!
Wir begannen auch mit der Arbeit am CryEngine Cover Surface System, um es mit dem Kythera-Verhaltenssystem zu verbinden und die Unterstützung der großen Welt zu ermöglichen. Das Cover Surface System ist in der Lage, ein physisches Objekt zu erfassen und automatisch Daten zu erzeugen, um Deckungspositionen zu speichern.
Darüber hinaus haben wir die Grundlage für die Erweiterung des CryEngine MNM-Navigationssystems zur Unterstützung großer weltweiter und lokaler Navigationsnetze geschaffen. Wir haben mit dem Prototyping der Funktionalität begonnen, ein Navigationsnetz an einem sich bewegenden Raumschiff anzubringen, so dass wir in den nächsten Monaten die Besatzungsmitglieder des Schiffes in der internen Raumfahrzeugumgebung navigieren lassen können.
Wir konzentrierten uns auch auf die Koordination der Arbeit von Moon Collider im Zusammenhang mit einigen Verbesserungen des Kythera Behavior Tree Systems. Das BTS ist nun mit DataForge verbunden, damit System-/Game-Designer schnelle neue Verhaltensweisen erstellen/prototypen können, ohne C++-Code schreiben zu müssen. Außerdem wurden neue Verhaltensknoten eingeführt, die grundlegende Funktionalitäten wie Zustandsmaschinen, Zeitstempel und Signale unterstützen. All diese Funktionalitäten werden uns in die Lage versetzen, komplexere und interessantere Verhaltensweisen zu implementieren.
Im Allgemeinen planen wir viele neue Features und werden einige coole Videos/Bilder vorbereiten, um mehr Details über unseren Fortschritt im nächsten Monat zu zeigen!
Design
Auf der Designseite haben wir eng mit dem britischen Team zusammengearbeitet und die Verantwortung für ein Level der Staffel 42 übernommen. Wir sind in jedem Aspekt der Entwicklung von Star Citizen aktiv, von der Arbeit an der Veröffentlichung des FPS-Moduls bis hin zur Entwicklung eines hochrangigen Verhaltensbaum-Feedbacks, das alle unsere Spielgebiete umfasst. Weitere Herausforderungen sind der Aufbau und die Einrichtung des Turm-Gameplays, die Bereitstellung von hochkarätigem Squadron 42-Feedback für Großbritannien und die Arbeit an der Vereinheitlichung der Anpassung von FPS-Anzügen, damit es besser funktioniert, als wir es derzeit mit den Schiffen tun.
Kinematiken
Ein paar Mitglieder des Teams waren den ganzen Monat über in London am Set, Chris Roberts drehte Szenen für Squadron 42. Die Besetzung ist fantastisch und wir können es kaum erwarten, bekannt zu geben, wen wir haben und ihre Auftritte zu präsentieren. Wir verstärken das Cinematics-Team und beginnen, die interne Pipeline und den Workflow zu verbessern.
Audio
Unser Audio-Ingenieur hat den ganzen Monat in Großbritannien verbracht, um mit seinem Audio-Team zusammenzuarbeiten, um das Audio für die nächste Veröffentlichung auf Wwise zum Laufen zu bringen.
Weitere Arbeiten zur Konvertierung alter FMOD-basierter Code-Features für die Verwendung des neuen Audiosystems. Ich habe einige Zeit bei der Entwicklung der Asset-Konvertierungsskripte mitgewirkt, um die einfacheren Teile des Prozesses zu automatisieren, so dass sich die Sound-Designer auf die Abstimmung der Sounds und die Art und Weise, wie sie im Spiel ausgelöst werden, konzentrieren können, anstatt sich um die Portierung der aktuellen Implementierungen kümmern zu müssen. Es wurden neue Tools für die Audio-Asset-Pipeline vorgestellt, die von den Sound-Designern und den Build-Servern verwendet werden, um die tägliche Produktion von Audio-Assets zu vereinfachen und zu beschleunigen.
FX
Im letzten Monat haben wir uns hauptsächlich auf die Erforschung verschiedener Arten von Feuer konzentriert, die in das Spiel einbezogen werden sollen. Diese reichen von kleinen Bränden und Trümmern bis hin zu gewaltigen Flammen und riesigen Explosionen. Rauch ist auch ein wichtiger Teil und sie dazu zu bringen, sich auf realistische Weise zu vermischen, war einer der Schwerpunkte des aktuellen F&E-Zyklus.
Wir haben auch einige Arbeiten am Blitz für einige der Staffel 42-Missionen durchgeführt, die hauptsächlich als Langstrecken-Hintergrundeffekte verwendet werden.
Guten Morgen, Bürger! ...oder Guten Abend Piraten? ...wie spät ist es überhaupt im Raum?? Poste die richtige Antwort in die Kommentare, um einen Daumen nach oben zu gewinnen.
Da es mehr als einen Monat dauert, etwas Wichtiges in einem so großen und detaillierten Spiel wie Star Citizen zu schaffen, könnte man feststellen, dass der Bericht dieses Monats dem Bericht des letzten Monats ähnlich ist, aber mit anderen Worten beschrieben wird :) Das bedeutet jedoch NICHT, dass der Monat ohne Fortschritt war, ganz im Gegenteil! Hier ist der Monatsbericht für das BHVR-Team:
Zunächst einmal haben wir uns intensiv mit dem Polieren, Debuggen und der Unterstützung anderer Studios auf verschiedenen Spielmodulen beschäftigt. Als wir uns dem FPS-Modul-Release und der Lieferung des Sozialmoduls nähern (bereiten Sie Ihre Aufregungstaschen vor!), wird die Zeit nicht so sehr mit dem Hinzufügen neuer Funktionen verbracht, sondern vielmehr mit dem Polieren und Konsolidieren des bereits Vorhandenen.
Hier sind die bemerkenswertesten Module, Systeme, systemischen Module und modularen Systeme, die in diesem Monat debugged, poliert und/oder unterstützt wurden:
Der Chat im Spiel Das Emote-System: /dance /dothebender Das FPS-Modul Die Lobby: Mehrsitzer in der Lobby: FPS Loadout Lassen Sie uns etwas über das Sozialmodul sprechen. Wir haben das Chatsystem um weitere Funktionen erweitert, um die Bedienung einfacher und angenehmer zu gestalten. Wir haben die erste Version der gefilterten Konversationsregisterkarten implementiert, die es Ihnen ermöglicht, mehrere private oder öffentliche Gespräche in verständlicher und geordneter Weise zu führen. Wir haben an der Schnittstelle und ihrer Erfahrung gearbeitet und sie für diese erste Iteration in einen Sperrzustand versetzt.
Wir haben auch einige Zeit damit verbracht, interaktive Elemente wie Flairs, den Holotable und Türen auf der Client- und Serverseite zu reparieren. Dies ist offensichtlich für jeden Ort im Spiel relevant, nicht nur für die Hangars.
Ingenieure haben die Replikation und Instanziierung der Hangars debuggt, während Leveldesigner alle möglichen Probleme in ihnen gelöst haben. Ich weiß nicht, was du in diesen Hangar-Jungs machst, aber sie scheinen die ganze Zeit zu brechen! Bitte hör auf, deine Buggys überall zu zertrümmern. ;)
Die Erstellung des Basis-Spawning-Moduls ist abgeschlossen, das, ob Sie es glauben oder nicht, das Spawnen mehrerer Spieler gleichzeitig in Hangars und an Planetenstandorten übernimmt. Damit können wir dich (also nicht dich, sondern deinen Charakter) an die richtige Position bringen, je nachdem, woher du kommst (Hangar -> Planetenseite, Raum -> Planetenseite, etc). Ich hätte nicht gedacht, dass das Laden und Spawnen so interessant sein könnte, aber wir sind gespannt auf die Videos, die Sie über Ihren ersten Spawn-Planetenrand veröffentlichen werden.
Okay, kommen wir nun zum lustigen Teil: Planeten! Diesen Monat haben wir in der Kunstabteilung alle Arbeiten für einen industriellen Bergbauplaneten abgeschlossen. Der Plan ist, dieses Set in der gesamten Galaxie zu verwenden, hauptsächlich, aber nicht ausschließlich für Delamar im NYX-System. Unser Hauptziel ist es, die Setstücke so vielseitig wie möglich zu gestalten, damit jedes Kunstteam in diesem Projekt verschiedene Orte schaffen kann. Dies hat ziemlich viel Zeit in Anspruch genommen, aber wir sind mit dem Endergebnis sehr zufrieden.
Wir haben auch mit der Arbeit an Legacy-Objekten begonnen, um sie an die neuen visuellen und technischen Standards anzupassen. Da wir mehr Standorte haben, aktualisieren wir unsere Techniken und da diese "alten" Stücke in Zukunft von Nutzen sein werden, müssen wir sicherstellen, dass sie konform sind.
Unsere Leveldesigner erforschen und verfeinern andere Standorte wie die Blöcke auf Terra Prime, Marianna und Odyssa, schaffen neue Innenräume und polieren und unterstützen ältere Standorte. Ähnlich wie die alten Kunstwerke änderten sich auch einige interaktive Objekte und mussten aktualisiert werden, um auf dem neuesten Stand zu sein.
Das mobiGlas hat viel Glanz und Fortschritt erfahren. Wir haben Animationen implementiert, um es noch eleganter zu machen. Einige Verfeinerungen und Aktualisierungen wurden auch am Warenfluss vorgenommen. Wir können jetzt Ihr UEC-Guthaben anzeigen und Sie können auch Dinge und Dinge wirklich kaufen!
In gleicher Weise haben wir eine erste Implementierung der Benutzeroberfläche, des Codes und der Visualisierung des microTech Kiosk durchgeführt. "Was zum Teufel ist das?", magst du fragen. Nun, einige Geschäfte und andere Orte rund um den Vers haben microTech-Kioske, die verwendet werden, um holographische Darstellungen von extra großen Produkten zu zeigen, die nicht zum Ort passen. Kioske werden auch genutzt, um mit Hilfe des mobiGlases Zugang zu einem Bestandskatalog zu erhalten. Das mobiGlas ist auch ein MicroTech-Produkt, so dass Sie jetzt die Verbindung sehen. Unser erster Kiosk wird in der Astro-Armada eingesetzt, wo er mit ihm interagiert werden kann, um Schiffe zu durchsuchen und zu kaufen.
Die Kioske sind Teil der ersten Phase des Schiffseinkaufserlebnisses. Wir planen immersivere und interessantere Wege, um Schiffe für die Zukunft zu kaufen, die auf Anhieb nicht lieferbar waren.
Ein weiteres interessantes Objekt, an dem wir arbeiten, ist der Personalschrank. Lass dich nicht täuschen, das hat nichts mit Flairs zu tun. Der persönliche Spind befindet sich in Ihrem Hangar und ist der Aufbewahrungsort für Ihre FPS-Geräte und Waffen. Später auf der Straße wird dieser Schrank nicht nur dazu verwendet, Waffen zu zeigen, sondern auch, um Ladungen vorzubereiten, um die Ausrüstung deines Charakters schnell auf den richtigen Job umzustellen.
Wie immer haben wir das Flair-Objekt dieses Monats zusammen mit anderen geheimen Merchandise-Arbeiten fertiggestellt, was die Überraschung nicht verderben wird, denn Überraschungen zu verderben macht überhaupt keinen Spaß.
Vielen Dank für Ihre Aufmerksamkeit! Jetzt geh und zerstöre einige Schiffe, dann wirst du es tun!
Grüße Stern-Bürger! Ich bin sicher, dass die meisten von euch den massiven Beitrag über Star Marine gesehen haben, und den Grund, warum es ein wenig länger dauert als erwartet. Vielen Dank, dass du mit uns mitgemacht hast! Der größte Teil des Monats Mai wurde für die Ausführung der in diesem Beitrag aufgeführten Punkte aufgewendet. Nachfolgend finden Sie die Details zu den einzelnen Teams.
Ingenieurwesen
Neben dem Zerquetschen vieler Fehler hat sich das Engineering-Team darauf konzentriert, die Animatoren bei der Entwicklung des neuen Jukes, Starts und Stopps-Systems zu unterstützen. Es gibt einzigartige Animationen für jede Richtungsänderung in eine andere, sowie für jeden Zustand und jede Geschwindigkeit, mit der der Spieler unterwegs ist. Das kann sich sehr schnell summieren! Auch die Arbeit an Zero-g-Bewegungen und SATA-Kugelfunktionen wurde fortgesetzt. Nachdem wir den SATA-Ball getestet hatten, stellten wir fest, dass es einige spezifische Fälle geben musste, die uns helfen würden, den Ball auf einem so großen Raum zu managen.
Design
Die Designer haben hart daran gearbeitet, SATA Ball zum Laufen zu bringen. Dies beinhaltet vor allem die Arbeit an der Spielbarkeit und den visuellen Hinweisen auf den Spieler für das Geschehen. Sicherstellen, dass die Spieler den Ball leicht finden können, dass die Spieler den Ball leicht greifen und mit Genauigkeit werfen können und dass sie ihn effektiv ansteuern können. Sie haben auch viele Tests mit dem Basissatz von Waffen durchgeführt und optimiert, wie das Atmen in Genauigkeit spielt.
Animation
Das Animationsteam konzentriert sich derzeit darauf, alle Jukes, Starts und Stopps von Mocap-Daten bereinigt und für die Implementierung im Spiel bereit zu machen. Wie bereits erwähnt, ist es eine Menge Mocap-Daten, so dass sie ihre Teller ziemlich voll haben.
Kunst
Das Kunstteam hat sich im letzten Monat auf zwei Hauptziele konzentriert. Einer davon ist die Überarbeitung der Anlagen für die Gold Horizon Station, um den Anforderungen an die Einrichtung des persistenten Universums gerecht zu werden. Dies wird es Teams in allen Studios ermöglichen, dieses Set in ihren verschiedenen Levels zu verwenden. Teilen ist wichtig!
Das zweite Ziel des Kunstteams war es, die vorhandenen Waffen zu polieren und ein einheitliches Schienensystem für Befestigungen zu schaffen. Dies wird die Erstellung von Anhängen erheblich erleichtern, da alles universell ist.
VFX
Einige neue VFX wurden für SATA Ball entwickelt, Effekte für die Tore, damit die Spieler nicht verwirrt werden und auch einige Effekte für den Spieler, wenn sie erschossen und deaktiviert werden. Ein Polish Pass wurde auch für alle vorhandenen Effekte mit Feedback von Chris durchgeführt.
Danke, dass du Citizens gelesen hast! Illfonie aus!
Hier ist, was wir hier in Montreal im Monat Mai gemacht haben:
Starmap
Herausragende Fortschritte wurden in diesem Monat in der eigentlichen Kunst für das Webstar-Kartenmodul erzielt. Wir haben jetzt vollständige künstlerische Entwürfe für die Top-Level-Ansicht der Galaktischen Ebene, in der alle Sternensysteme angeordnet sind und ihre Jump Point Verbindungen zeigen. Die größte Herausforderung bestand darin, einen Weg zu finden, die Sprungbretter stilistisch schön, aber auch funktional so darzustellen, dass sie die Größen und Richtungen der Wurmlöcher darstellen. Große Fortschritte wurden bei einer 2D HeatGrid-Darstellung erzielt, um (auf jeder Ebene) den politischen Einfluss, die Kriminalität und die wirtschaftliche Ebene der Gebiete der Galaxie darzustellen. Obwohl dies immer noch experimentell ist, inspirierten die von unseren Künstlern vorgeschlagenen Visuals zur Erweiterung dieses Features.
Eine der wichtigsten UI-Komponenten, die in diesem Kunstpass enthalten sind, ist die Control Disc; das ist ein sehr interessantes Design, da wir denken, dass es auch als In-Game-Komponente verwendet werden kann. Auf dieser Disc können Sie mit den verschiedenen Elementen, die Sie auf dem Bildschirm sehen, interagieren, während Sie durch die Galaxie surfen. Unser Mock-up-Set der Künstler beinhaltet auch den Bildschirm "Space Object Overview", der im Grunde genommen das ist, was passiert, wenn man mehr Informationen über ein Objekt anfordert, sei es ein Planet, ein Asteroidengürtel, ein Nebel oder ein Wurmloch. Diese allgemeine Ansicht dient als primäre Anzeige für Informationen über alles aus der Starmap sowie für den Sprung zu den Galactapedia-Einträgen für jeden von ihnen.
Das Design der Starmap ist nun in einem Zustand, in dem sie mit den tatsächlichen Plänen für die Starmap im Spiel verknüpft werden kann, weshalb wir auch unsere Benutzeroberfläche so gestaltet haben, dass sie mit den Spielkontrollen und -erfahrungen vereinheitlicht wird.
Community Hub
Wir haben in diesem Monat die Schnittstellen-Mock-ups für diesen neuen Abschnitt fertiggestellt, sein Design mit dem neuen Website-Look verschmolzen und es an tatsächliche datengesteuerte Ansichten angehängt. Wir haben viel Zeit damit verbracht, so viele Inhalte wie möglich von den Fans zu präsentieren: Bilder und Galerien, aber auch Videos von verschiedenen Anbietern, Streaming-Kanäle, Podcasts.... Der Hub befindet sich noch in intensiver Entwicklung, wir werden bald mehr zeigen können.
Ausgaberat
Der Issue Council, unser neues "crowdsourced" Bug-Reporting-System, durchlief einen Monat lang eine Headdown-Codierung. Der Kern des Systems wurde fertiggestellt, einschließlich Datenmodelle und API auf Systemebene. In der Zwischenzeit hat das Designteam die Bewegungen auf der eigentlichen Benutzeroberfläche durchgearbeitet. Wir haben dem QS-Team in Austin eine Demo gegeben und alle sind begeistert, dass sie es nutzen können. Im Juni werden wir es testen, indem wir tatsächlich Fehler über sich selbst in es eingeben!
Launcher
Diesen Monat haben wir in Zusammenarbeit mit der DevOps-Crew in Austin eine Prototyp-Überarbeitung der Star Citizen-Rakete abgeschlossen. Der neue Launcher ist vorerst nur intern, nur für CIG-Tests, und basiert auf der BitTorrent-Technologie. Dies ermöglicht es, den Patchprozess in Größe und Geschwindigkeit effizienter zu gestalten und ist ein erster Schritt zu einem webbasierten Launcher, der wiederum dazu führt, dass mehr Konfigurationswerkzeuge direkt im Launcher zur Verfügung stehen (Hangarkonfiguration, zukünftige Inventur, REC-Aktivierung....).
Chat
Das Chat-System hat auch in diesem Monat einige Verbesserungen erfahren. Wir haben sein Aussehen überarbeitet, um es dem Rest der Website näher zu bringen, und wir haben "klebrige" Raumthemen zur besseren Lesbarkeit eingeführt.
Und noch mehr!
In diesem Monat kam auch mit einem eigenen Content Slew Updates auf der Website. Wir sahen tatsächlich 2 Konzeptverkäufe mit dem Starfarer Gemini und dem neuen MISC Reliant Minischlepper, und wir brachten Ihnen auch das in Montreal produzierte Minispiel Hyper Vanguard Force IV von Dave Richard und Christine Marsh. Apex Predators vereinigen sich!
Um es stiller auszudrücken: Wir haben auch das neue Amazon "Login And Pay"-Zahlungssystem für nordamerikanische Nutzer implementiert.
Nachdem May in den letzten Monaten viel Planungs- und Konstruktionsarbeit geleistet hatte, war May zur Abwechslung mal kurz auf diese aufmerksam geworden, so dass wir die Chance hatten, uns wirklich in eine coole Ingenieursarbeit einzulassen. Es gab mehrere große Designer-Tool-Funktionen, an denen wir gearbeitet haben, und wir freuen uns darauf, sie nutzen zu können.
Ingenieurwesen
Letzten Monat sprachen wir über die ausgefallenen Verbesserungen beim Verbinden von Keilwellen, an denen wir gearbeitet haben. Dies ist ein Feature, das es Designern ermöglicht, eine Spline zu spezifizieren, die ein Schiff mitfliegen soll (um einige ausgefallene Manöver durchzuführen oder wirklich nahe an Hindernissen zu fliegen, von denen die KI sonst Abstand halten würde), und die KI wird einen optimalen Weg finden, um so schnell wie möglich auf die Spline zu gelangen. Dazu muss die KI einen Weg von ihrer aktuellen Position und Richtung zum Anfang der Spline herausfinden und am Ende nach unten in die Richtung des Spline-Pfades schauen, sobald sie dort ankommt. Dies kann dann komplizierter werden, da die Konstrukteure die Geschwindigkeit angeben können, mit der sich das Schiff bewegen soll, wenn es die Spline startet, so dass dies den Weg, den das Schiff nimmt, beeinflussen kann, da es möglicherweise den Weg ein wenig krümmen muss, um zusätzliche Anstiege hinzuzufügen, wenn es auf den neuesten Stand der Technik kommen muss oder um viel langsamer zu werden. Und natürlich wollen wir auch, dass das alles ziemlich natürlich aussieht.
Wir haben das Feature diesen Monat fertig gestellt und es den Designern zur Verfügung gestellt. Jetzt, da Schiffe Splines von überall zuverlässig verbinden können, erleichtert es die Einrichtung des Designers, aber was für Sie noch wichtiger ist, es wird uns ermöglichen, sie viel mehr in systemischem Verhalten einzusetzen. Bisher mussten wir bei der Auswahl der Schiffe für eine Spline sehr restriktiv sein, aber das gibt ihnen viel mehr Freiheit. Wenn wir das Verhalten angepasst haben, werden sie in zukünftigen Versionen von Arena Commander viel mehr verwendet werden.
Das größte Feature, an dem wir diesen Monat gearbeitet haben, war eine komplette Änderung in der Art und Weise, wie wir KI-Verhaltensbäume erstellen. Bisher haben wir sie direkt im Code erstellt. Mit Kytheras Laufzeit-C++-Rekompilierung war dies eigentlich recht effizient und ermöglichte eine schnelle Iteration während der Ausführung des Spiels, war aber für Designer ohne Programmierkenntnisse nicht zugänglich. Deshalb haben wir viel Arbeit geleistet, damit Verhaltensbäume in DataForge erstellt werden können.
Sie werden in der Vergangenheit viel von DataForge gehört haben, als das benutzerdefinierte Datenmanagement-Tool, das von Designern für alle Arten von unterschiedlichen Daten in Star Citizen verwendet wird. Es wurde von Anfang an so konzipiert, dass verschiedene Ansichten für verschiedene Datentypen möglich sind, so dass Sie gegebenenfalls Daten in einem Tabellenkalkulationsformat bearbeiten können, während für andere Dinge eine grafische Knotenbearbeitungsansicht besser geeignet ist, und so weiter.
Wir haben jetzt eine Datenkategorie für Verhaltensbaumdaten in DataForge, die es Designern ermöglicht, Verhaltensbäume über eine benutzerfreundliche GUI-Schnittstelle zu erstellen und zu bearbeiten und diese Verhaltensweisen dann direkt auf ein KI-Zeichen anzuwenden, ohne dass sie Code schreiben müssen. Außerdem können sie die Verhaltensbäume zur Laufzeit modifizieren und die Ergebnisse sofort sehen, was für eine schnelle Wiederholung fantastisch ist.
Was uns jedoch besonders interessant machte, ist, dass wir erwarten, dass in Zukunft regelmäßig neue Verhaltensbaumknoten erstellt werden, und wir wollten das Hinzufügen dieser Knoten in DataForge so einfach wie möglich unterstützen. Deshalb haben wir an der Erstellung eines einfachen Konsolenbefehls im Editor gearbeitet, der automatisch neue Definitionen für DataForge generiert, sowie an einem neuen C++-Bindungscode, der DataForge-Verhaltensbaumstrukturen mit dem zugrunde liegenden Kythera-Verhaltensbaumcode verbindet. Wenn ein Codierer also einen neuen Knoten erstellt, ist es nur ein kurzer Konsolenbefehl und der Knoten ist nun vollständig in DataForge integriert!
Es ist also immer noch möglich, KI-Verhalten in C++ zu erstellen, wie bisher, aber jetzt haben wir diese alternative GUI-Erstellungsmethode, die dann in entsprechenden C++-Code übersetzt wird, wenn das Verhalten ausgeführt wird. Wir freuen uns, dass die Designer beginnen, mit dem neuen Tool zu arbeiten und großartige Verhaltensweisen zu entwickeln. Wir erwarten, dass wir in naher Zukunft kleine Verbesserungen vornehmen müssen, um die Oberfläche für Designer noch einfacher zu machen, aber wir denken, dass es ein guter Anfang ist. Und wir müssen Ash Canning bei Foundry 42, dem Mastermind hinter DataForge, einen riesigen Schrei aussprechen, der uns wirklich kurzfristig viele Optimierungen vorgenommen hat, um DataForge zu helfen, Verhaltensweisen besser zu bearbeiten.
Schließlich haben wir etwas in unserem Debugging-Tool Kythera Inspector gearbeitet, damit Designer ihre Verhaltensbäume viel einfacher debuggen können, indem sie jederzeit eine visuelle Live-Darstellung dessen erhalten, was der Baum gerade tut. Letzten Monat haben wir die Möglichkeit hinzugefügt, Verhaltensbäume aufzuzeichnen und wiederzugeben, aber das ist nützlicher, um Fehler aufzuspüren. Für die Entwicklung von Verhaltensbäumen ist eine Live-Ansicht dessen, was sie tun, sehr praktisch. Wir geben diesem Feature den letzten Schliff und werden es bald an die Designer weitergeben, also werden wir auf den Bericht des nächsten Monats warten, um mehr darüber zu erfahren.
Meine Damen und Herren, Jungen und Mädchen, Bürger jeden Alters, Thomas, Kameramann und außergewöhnlicher Redakteur, hier, um Ihnen den Monatsbericht für Mai zu präsentieren. Wie immer berichtend aus dem, was man nur als Himmel auf Erden bezeichnen kann, alias dem einfach erhabenen Paradies, bekannt als Santa Monica, Kalifornien.
Und genau wie unser prächtiges Lokal war der Mai für uns ein geradezu wunderbarer Monat. Wir debütierten ein neues Segment in unserer Flaggschiffshow Around the Vers, genannt Ship Shape. Veranstaltet von der überschwänglichen und immer verführerischen Lisa Ohanian, bietet es uns die Möglichkeit, mit unseren Fans und Unterstützern einen umfassenden Blick in die Schiffspipeline zu werfen.
Apropos Around the Vers, Ben Lesnick hat einen fantastischen Job als Solo-Moderatorin gemacht, während Co-Moderatorin Sandi Gardiner aufgerufen wurde, ihre thespianischen Fähigkeiten beim Squadron 42 Motion Capture Shooting in London zu zeigen, und wir wurden mit einer Reihe talentierter Entwickler konfrontiert, die sich alle als hervorragende Faksimiles erwiesen haben, in Abwesenheit unseres berühmten Vorsitzenden auf unserer wöchentlichen 10 für Serien.
Im Mai sahen wir auch den beliebtesten Bugsmasher aller Zeiten, Herrn Mark Bartholomew Abent III, der den Sprung vom Untersegment Around the Verse zur alle zwei Wochen stattfindenden eigenständigen Show machte. Seine Pilotfolge wurde mit begeisterten Kritiken aufgenommen, und es ist mit großer Begeisterung, dass ich mit Freude bekannt geben kann, dass das Netzwerk tatsächlich einen Auftrag für eine ganze Saison von Shows erteilt hat.
Ganz ohne Zusammenhang zeugte uns der Mai auch die lang erwartete und lang erwartete Eröffnung von Fuddruckers Santa Monica, und das CommuniTeam vergeudete keine Zeit damit, es zum Mittagessen zu besuchen, und ich möchte nur sagen, dass wir nicht enttäuscht waren.
Und das, meine lieben Mitbürger, war der Monat Mai. Vielen Dank an alle unsere Fans, ohne dich wäre all dies nicht möglich, und es ist wirklich eine Ehre und ein Privileg, das tun zu können, was wir tun.
Bis zum nächsten Mal werde ich es immer und ewig sein,
Euer demütiger Diener,
Thomas Grüße Bürger,
Es ist schwer zu glauben, dass June schon da ist! In unseren Studios und Outsourcing-Partnern auf der ganzen Welt wird hektisch an Star Citizen gearbeitet. Diesen Monat freuen wir uns, Ihnen unser neuestes Studio, Foundry 42 Germany, vorstellen zu können. Sie werden in den kommenden Monaten viel aus Deutschland sehen: Sie sind damit beauftragt, viele der Programmherausforderungen, mit denen Star Citizen auf dem Weg in das persistente Universum konfrontiert ist, anzugehen. In diesen Bereichen und an unseren vielen Modulen und Meilensteinen wird weiter gearbeitet, von Star Marine (das gerade für sein PTU-Debüt vorbereitet wird) bis hin zu Squadron 42 (Kinofilme werden derzeit von Chris Roberts in London geleitet!) Ihre Top-Level-Ansicht dessen, was wir diesen Monat genau getan haben, finden Sie unten.
Willkommen zurück zu einer weiteren Ausgabe des Monatsberichts! Dieser Monat war ein ereignisreicher Monat mit vielen Entwicklungsnachrichten. Wie immer sind wir super aufgeregt, mit dir zu teilen, was wir im letzten Monat gemacht haben! Also einrichten und es sich bequem machen, denn hier kommt das Entwicklungs-Update!
Design
Eine der größten Entwicklungen vom Mai war die Enthüllung und der Konzeptverkauf für den MISC Reliant. Dieser Verkauf war eine große Leistung für uns und fühlte sich wirklich so an, als hätten wir jede Abteilung auf alle Zylinder geschossen, um den Verkauf vorzubereiten. Alle, die am Verkauf beteiligt waren, drängten sich wirklich darauf, sicherzustellen, dass es nicht nur pünktlich, sondern auch früh fertig war. Es war ein großartiges Beispiel dafür, wie sich unsere verschiedenen Abteilungen zusammenschlossen, um ein weiteres dieser unglaublichen Schiffe zum Leben zu erwecken. Wir sind auch ziemlich zuversichtlich, dass es der Community auch gefallen hat, mit über 19.000 verkauften Exemplaren während des Konzeptverkaufs. Vielen Dank an Sie alle, dass Sie sowohl dieses großartige neue Schiff von MISC als auch die Weiterentwicklung von Star Citizen unterstützen.
Wir haben einen Balancepass über die aktuelle Liste der Raketen genommen, insbesondere durch die Erhöhung der Anfälligkeit aller CS-Lock-Raketen (Tempest, Stalker, StrikeForce) für Spreurauschen, wodurch diejenigen, die auf eine bessere Chance geschossen haben, dem Zorn dieser mächtigen Munition zu entkommen. Zusätzlich wurden die Raketenverriegelungszeiten auf der ganzen Linie erhöht (von 2 auf 5 Sekunden), so dass die Piloten ihre Manövrierfähigkeiten auffrischen können! Das Ziel im Auge zu behalten, ist umso wichtiger geworden. Mit dieser Änderung werden auch Feuerlöschraketen praktischer. Frohe Jagd!
Eines der Schiffe, die die Pipeline hinunterfahren, ist der Crusader Industries Genesis Starliner. Die Starliner ist ein großes Schiff, das etwas größer als eine 747 ist. Dieses Schiff ist insofern einzigartig, als es eines der ersten Passagierschiffe ist, das vom Star Citizen-Team in Angriff genommen wird. Als erstes Schiff seiner Art hat es uns dazu gebracht, unsere Entwürfe in Bezug auf die Passagiere im Weltraum in Frage zu stellen. So werden beispielsweise noch einige der Fragen zur Fahrgastkapazität, zur Sicherheit dieser Fahrgäste und zu den maximalen Flugzeiten beantwortet. Das äußere Konzept ist an einem soliden Ort, aber die inneren Konzepte sind noch in Arbeit. Wir freuen uns sehr, Ihnen alles zu zeigen, was wir uns ausgedacht haben. Bald wird der Starliner mit Ihnen am Steuer oder als Passagier auf dem Weg zu dem Urlaubsort, den Sie ausprobieren wollten, die Sterne erkunden.
Ursprünglich im März-Update erwähnt, machen wir weiterhin Fortschritte in Richtung unseres neuen Physically Based Damage Systems. Dieses neue System wird an mehreren Fronten für das aktuelle Arena Commander Gameplay helfen und dazu beitragen, die Grundlagen für die Staffel 42 und die PU, aus der sie gebaut werden soll, zu schaffen. Einige der größten Highlights sind eine komplette Überarbeitung des Schadens und der Handhabung für jede Waffe mit einem klaren Fokus darauf, sicherzustellen, dass Ballistik- und Energiewaffen ihre eigenen einzigartigen Eigenschaften und Auswirkungen auf das Spiel haben. Aber wenn Sie den Schaden ändern, ist das nur ein Teil des Rätsels, also erwarten Sie auch ein vergleichbares Update für jede größere Schiffskomponente, um dieses neue System zu unterstützen: Schiffs- und Schild-Zustand, Kraftwerksleistung, Kühlraten, alles in Ordnung.
Ein weiteres großes Ereignis im Mai für das Büro in Santa Monica war, John Pritchett und Pete Mackay im Büro zu haben, als wir begannen, einen Teil des Flug- und Thruster-Handling für das Spiel wirklich einzuwählen. Während sie über einige ihrer Arbeiten während der letzten Around the Vers-Auftritte gesprochen haben, gibt es viele Arbeiten hinter den Kulissen, deren Besuch uns geholfen hat, sie zu rationalisieren. Jetzt haben wir noch bessere Tools und Dateneinstellungen, um den Bau neuer Schiffe und Komponenten reibungsloser und einheitlicher als bisher zu gestalten. Diese Arbeit half bereits bei der Vorbereitung des Reliant Verkaufs und ließ uns schnell die Massen- und Thrusteranforderungen für das Schiff schneller als je zuvor aufbauen.
Kunst
Für das HUD & UI haben wir einige Arbeit geleistet, um die CPU / Rendering-Performance zu verbessern, indem wir die Anzahl der Draw Calls, die der skalierte Aspekt des HUD beisteuerte, sowie einen Refaktor der Holo-Objekte optimiert haben, die zur Verbesserung der Rendering-Performance von holographischen Elementen und Entitäten beitragen sollten. Insgesamt sollte die Menge der CPU-Ressourcen, die das HUD / UI in Anspruch nimmt, jetzt deutlich geringer sein, und wir werden sie weiter optimieren, um die bestmögliche Leistung zu erzielen.
Diesen Monat haben Josh Coons und Mark McCall eine neue Helminnenausstattung entworfen und umgesetzt, die für alle FPS-Charaktere verwendet wird. Diese neue Richtung für die Helme ist ein großer Schritt in der Realisierung von Chris Roberts Gesamtvision für Star Citizen Charaktere. Das neue Helminnere gibt dem HUD-Team mehr Flexibilität und trägt zum Realismus unseres Universums bei.
Was unsere Helme einzigartig macht, ist, dass sie das Sichtfeld des Spielers beeinflussen und die Vielseitigkeit unseres FPS-Spielerlebnisses verbessern. Die Ausrüstung in unserem Spiel sollte sich real und substantiell anfühlen - nicht nur eine Reihe von Statistiken und Zahlen, die im Gameplay min-maxed werden sollen, mit Eigenschaften, die den verschiedenen Spielern die Wahl lassen, basierend auf ihren eigenen subjektiven Präferenzen, und die die Vielfalt der Spielerwahlen erweitern.
Bei der technischen Kunst lag unser Schwerpunkt in diesem Monat auf Schiffsuntergang, Bergung und Optimierung. Wir haben den Auftrag, das Gleichgewicht zwischen dem am besten optimierten Schadensansatz zu finden und gleichzeitig sicherzustellen, dass unser Gameplay-Design intakt bleibt.
In der Vergangenheit haben wir für Schiffsschäden fünf Versionen von jedem Teil eines Schiffes gebaut. Dies waren die 0%, 25%, 50%, 50%, 75% und 100% beschädigten Versionen. Das Sprengen von Schiffen sah sehr cool aus, aber diese Lösung war extrem arbeitsintensiv, verbrauchte viele Systemressourcen und war nicht skalierbar, damit CryEngine die epische Armada von Schiffen, die gegen Chris kämpfen, darstellen konnte.
Wir brauchten eine neue Schadenslösung. Ali Brown, Okka Kyaw, Geoff Birch und Mark Abent halfen alle bei der Entwicklung unserer neuen Damage Shader und Squib Technologie, die die Zerstörung unserer neuesten Schiffe ohne die hohen Ressourcenkosten ermöglichte. Aber selbst als wir diese großartige Leistung der Optimierung vollbrachten, planten unsere Designer neue Spielmechaniken wie Debris Salvage und Ship Repair, von denen jede die Kosten für die gesamte Verarbeitung unseres Schiffsmodells erhöht.
Der wahre Leistungsfeind von Star Citizen mit so vielen High-Fidelity-Assets ist "Draw Calls". Für diejenigen, die es noch nicht kennen, sind Draw Calls die Anzahl der Renderpasses auf jedem Geometrieteil, um das endgültige Bild zu erstellen. Wenn Ihr Raumschiffrumpf diffuse, spiegelnde und normale Texturen hat, dann würde das 3 Draw Calls bedeuten. Und wenn Ihr Schiff in 50 Stück aufgeteilt ist, wäre das 50 × 3 = 150 Draw Calls. Und fügen Sie einige hochwertige Selbstbeschattungen hinzu, und Sie können 150 auf riesige 300 Draw Calls verdoppeln! Unsere Schiffe werden mit PBR (Physically Based Rendering) gerendert, wobei der Damage Shader, Paint Variations und Decals mehr als 15-30 Draw Calls pro Stück erfordern. Um die Draw Calls zu optimieren, mussten wir also die Anzahl der einzelnen Figuren reduzieren. Aber das bedeutet, dass wir, um wirklich optimiert zu werden, weniger animierte Teile und weniger Absplitterungen des Schiffes benötigen würden! Ein ziemliches Rätsel, denn wir wollen diese Dinge!
Als er mit Ali über diese Optimierungsprobleme sprach, schlug er einen neuen Trümmeransatz vor, den wir jetzt untersucht haben. Anstatt das Schiff in einzelne, empfindliche Bereiche zu zerlegen und Trümmer vom Schiff zu lösen, schlug er vor, Teile des Schiffes mit dem Damage Shader und Spawn Debris zu verstecken, die dann vom Schiff wegfliegen würden. Dieser neue Ansatz sieht immer noch so aus, als ob Trümmer vom Schiff geblasen werden, ermöglicht es uns aber, die Anzahl der Schiffsrumpfnetze zu reduzieren, was auch die Draw Calls deutlich reduziert. Und außerdem ermöglicht uns diese Lösung, Schutt zu erzeugen, der bergefähige Komponenten enthält! Also, die Waffe, die du gerade von dem Entermesser in der PU abgeschossen hast? Es gehört jetzt dir. Gern geschehen.
Es gab viele andere Durchbrüche wie diesen. Und dieser Monat hat uns der Verwirklichung der Weltraumoper unserer Träume näher denn je gebracht. Nun ist es unsere Aufgabe, den kompletten Optimierungsplan über alle Schiffe im Spiel hinweg umzusetzen, mit dem Ziel, dass wir Squadron 42 mit erstaunlich lustigem Gameplay und einer seidig-glatten Bildrate veröffentlichen.
Ingenieurwesen
Die Arbeiten an Radar 2.0 sind abgeschlossen. Alles kann registriert werden, um auf dem Radar angezeigt zu werden, solange es eine passende IRadarObjekt-Struktur gibt. Für den Laien bedeutet das, dass, solange ein Objekt die richtigen Informationen enthält, dieses Objekt aufgenommen und auf dem Radar basierend auf seinen physikalischen Eigenschaften angezeigt wird. Ja, wir können EMP-Granaten sogar eine EM-Signatur geben und sie auf dem Radar erscheinen lassen, wenn Ihr Radar konfiguriert ist, um EM zu erkennen.
Wir haben es auch so gemacht, dass Radare in der Lage sind, nach jeder Art von Signaturtyp zu filtern und erkannte Objekte nun eine Instanz von ihnen erstellt haben. Die Erstellung dieser Instanz ermöglicht es uns, Dinge wie Stotterpositionsaktualisierungen durchzuführen und/oder Decay/Afalloff anzuzeigen, ohne das tatsächlich erkannte Objekt zu beeinflussen. Auf diese Weise können Design und Kunst coole und interessante Dinge für die angezeigte Instanzversion tun, ohne die zugrunde liegende Logik, die das Radar/Signatur antreibt, zu durchbrechen. In diesem Zusammenhang haben wir auch die Performance von Okklusionsprüfungen verbessert.
Last but not least haben wir die Unterstützung von "Dezibel" als neuen Signaturtyp hinzugefügt. Zu Fuß in Star Citizen kann Ihr Radar Audio aus der Umgebung wie Schritte und Waffenfeuer anzeigen. Diese Ereignisse sind nun ordnungsgemäß in das Signatursystem eingebunden, so dass Ihre Schritte und Waffen Feuer "Dezibel" erzeugen, die vom Spielerradar gescannt und angezeigt werden. Du wirst sehen, wie dieses Debüt mit dem FPS stattfindet.
Unser LA Engineering Team hat auch bei der Handhabung von Spieler-/Charakterkleidung, Individualisierung und Anhängen mit dem von uns entwickelten Item-Port-System geholfen. Das Item-Port-System ermöglicht das Anbringen von Items an Knochen, die auf 3D-Objekten definiert sind. Auf diese Weise befestigen wir alle unsere Schiffsteile und Schiffsartikel. Dieses System wird für Charaktere erweitert, die eine dynamische Skelett-Erweiterung durch skinned attachments unterstützen.
Das bedeutet konkret, dass wir die Körperteile haben, die in der Lage sind, Gegenstände auszurüsten. D.h. Füße, Hände, linke Hand, rechte Hand, Torso, etc. sind mit entsprechenden Knochen gekennzeichnet, die definieren, wo angebrachte Gegenstände angebracht sind. Von dort aus, wenn Sie ein Bruststück ausstatten würden, das eine taktische Schulterleuchte, Sauerstofftank und Brustholster erlaubt, benötigt jeder dieser zusätzlichen Befestigungspunkte zusätzliche Knochen. Das System erlaubt es jedem der zusätzlichen Knochen, die in einer Haut (enthäutetes Objekt, nicht tatsächliche Haut) angebracht sind, das Basisskelett zu erweitern, indem es dieses Skelett dynamisch mit den zusätzlichen Knochen aktualisiert.
Damit ist das Update für das Santa Monica Studio abgeschlossen! Vielen Dank wie immer, dass du dir die Zeit genommen hast, unsere Geschichte zu lesen und für deine Unterstützung bei der Entwicklung dieses Spiels! Wir könnten das nicht ohne jeden einzelnen von euch machen und eure Unterstützung wird von jedem von uns hier bei Cloud Imperium sehr geschätzt. Nochmals vielen Dank und wir sehen uns für das Update im nächsten Monat!
Aprilschauer haben sich in Texas in Mai-Hochwasser verwandelt! Wir wurden von schwerem Wetter und großen Überschwemmungen heimgesucht, wie Sie vielleicht in den Nachrichten gesehen haben. Glücklicherweise ist unser Studio von dieser Zerstörung weitgehend verschont geblieben und wir sind wie gewohnt vorangekommen. Wir haben neue Builds von Star Marine getestet und hart an der Arbeit am Persistent Universe und vielen technischen Aktivitäten gearbeitet. Hier sind einige detaillierte Berichte von den Leitern der einzelnen Teams.
Hartnäckiges Universumsteam
Kunst
Das PU Art Team hat in diesem Monat wie gewohnt in vielen Bereichen des Projekts mitgewirkt. Einer unserer Schwerpunkte war die Verlegung der Landezone Nyx>Delamar>Levski in die Final Art Phase. Wir sind jetzt an der Greybox-Phase vorbeigekommen und die Umgebung sieht fantastisch aus. Art Director Mark Skelton, Lead Artist Patrick Thomas und Global Environment Lead Ian Leyland haben eng mit BHVR zusammengearbeitet, um diese Umgebung wirklich zu einem Erlebnis zu machen. Der VFX-Künstler Lee Amarakoon und der Lichtkünstler Marc Toscano waren damit beschäftigt, dieser Umgebung einen zusätzlichen Hauch von Nebel, Rauch und Licht hinzuzufügen, um ihr Leben einzuhauchen. Wir können es kaum erwarten, euch an zwielichtigen Hintertürchen teilhaben zu sehen, Dinge auf dem Schwarzmarkt zu verkaufen und die gewundenen Asteroiden-Tunnel zu durchqueren, die diese Umgebung zu bieten hat.
Ein weiterer Schwerpunkt lag auf der Optimierung der Landezone Stanton>ArcCorp>Area18 für eine bessere Leistung in Vorbereitung auf das Social Module Release. Der extrem hohe Detaillierungsgrad und die Genauigkeit, die unsere Umgebungen so erstaunlich machen, sind ziemlich anstrengend für die Leistung, aber mit dem Einsatz neuer Technologien aus unserem Grafikteam sind wir in der Lage, unsere Leistung mit verschiedenen Mitteln erheblich zu verbessern.
Der Konzeptkünstler Ken Fairclough hat ein Konzept für eine Sicherheitsturmstütze entwickelt, die schließlich auf Landeplätzen wie ArcCorp zu finden sein wird. Diese Sicherheitstürme werden dazu dienen, Spieler zu bestrafen, die ihre Waffen in Gebieten ziehen, die ihnen das nicht erlauben. Sie werden auch als Abschreckungsmittel für Trolle und Trauernde dienen, die denken, dass es eine gute Idee ist, das Feuer auf zufällige Zivilisten zu eröffnen.
Unser Charakter-Team hat den Support für die FPS-Charaktere abgeschlossen. Die Marines und Outlaws befinden sich an einem Punkt, an dem wir ihnen Adieu gesagt haben, und jetzt hat sich unsere Aufmerksamkeit auf die Entwicklung der Charaktere verlagert, die beim Spielen von SATABall in der Astro Arena zu sehen sein werden. Wir haben einige ziemlich clevere neue Konzepte, von denen wir gearbeitet haben und die in den nächsten Wochen abgeschlossen werden sollten. Unser Charakter-Team hat auch einige Forschungs- und Entwicklungsarbeiten zu Haar und austauschbarer Kleidung für das kommende Social Module Release durchgeführt.
Das Austin Animation Team hat auch verschiedene Bereiche des Projekts unterstützt. Wir hatten alle Hände voll zu tun, um alte PU-, FPS- und Arena Commander-Animationen auf unser neues Skelett zu übertragen. Wir haben auch Unterstützung bei der Verbesserung der G-Force-Animationen und beim Testen des Grabby Hands-Systems geleistet. Senior-Animator David Peng hat sich zu 100% darauf konzentriert, Cockpit- und Kanonenvorlagen an die neuen Proportionen des Charakters anzupassen. Wir haben jetzt 7 Cockpittypen und 20 Tastenkombinationen, aus denen unsere Künstler bei der Erstellung von Cockpits wählen können.
Design
Ein Großteil der Zeit, die Design in diesem Monat damit verbracht hat, einige unserer anderen Berufe zu vertiefen, die die Spieler schließlich in der PU übernehmen können. Tony Zurovec verbrachte einen Großteil seiner Zeit damit, die Besonderheiten der Pioniertätigkeit (ehemals Exploration) zu ergründen und wie sie sich auf die Funktionalität eines zukünftigen Schiffes bezieht. Rob Reininger absolvierte einen ersten Durchgang darüber, wie die Söldner-/Sportlerbesetzung funktionieren würde, während Nate Blaisdell und Evan Manning die Berufe Kopfgeldjäger bzw. Schmuggler anpackten. Diese Entwürfe liegen nun bei Tony Z zur Überprüfung vor und werden nach der Genehmigung zusammen mit Andrew Nguyen in die Warteschlange gestellt, um das Gameplay zu implementieren.
Tony Z beendete auch seinen ersten Entwurf des neuen Universumssimulators (früher der Wirtschaftssimulator) und leitete ihn an das Team drüben in Wyrmbyte weiter. Das neue Design beinhaltet viel mehr als nur das ökonomische System, das in der PU enthalten sein wird, jetzt auch Dinge wie die Fähigkeit, Elemente und Verbundwerkstoffe zu erzeugen, die Fähigkeit, einen Planeten innerhalb eines Sonnensystems zu erschaffen und ihm Daten zuzuweisen, und die Fähigkeit, Berufe für NSCs zu schaffen und die Ausführungslogik für jeden Beruf festzulegen.
Mark Skelton und Tony Z trafen sich zusammen mit Lead Writer David Haddock mit BHVR, um Entwürfe und Layouts für die kommenden Standorte am Planetenrand zu besprechen. Konkret war unser Augenmerk in diesem Monat auf Magnus>Borea>Odyssa und Helios>Tangaroa>Mariana gerichtet. Beide Standorte werden unserem ohnehin schon beeindruckenden Stall von Landeplätzen mehrere neue, spannende Möglichkeiten und Vielfalt bieten. Wir werden einige spannende Looks mit euch teilen, wenn es online geht. Nächsten Monat werden wir uns auf die anderen Landezonen innerhalb des Stantonssystems konzentrieren: Crusader, Hurston und MicroTech.
Ingenieurwesen
Der Monat Mai war ein sehr arbeitsreicher Monat für das Engineering Team hier in Austin und für das Wyrmbyte Team. Viele große Ticketartikel waren fertig und bereit für den ersten Test.
Ein großer Punkt, auf den alle gewartet haben, ist unser neuer Generic Instance Manager, der deutliche Verbesserungen in Systemen wie Matchmaking und Party verspricht. Dies wurde von Jason Ely entworfen, und er brachte es mit starker Unterstützung von Tom Sawyer nach Hause. Wir werden erste Tests auf diesem neuen System durchführen, das Teil des kommenden FPS-Release sein soll.
Inzwischen...drüben bei Wyrmbyte...Scott Brown, Nathan Gray und Ryan Seabury haben an unserem Universums-Simulator gearbeitet und sind dabei, eine Proof-of-Concept-Iteration mit Basisfunktionalität zu liefern. Der nächste Schritt ist, dies weiter auszubauen, bis wir eine Arbeitsdemo erstellen können, die wir intern für weitere Diskussionen darüber austauschen können, wie wir darauf aufbauen können. Gleichzeitig arbeitet Ian Guthrie an der ersten Iteration unseres Sonnensystem-Servers und wird in Kürze eine erste Iteration davon abschließen. Das Wyrmbyte-Team hat auch eine Neufassung unseres Player Info Servers und unseres Presence Servers im Mai geliefert und arbeitet weiterhin an seinem iPredictor Schiffs- und Raketenbewegungssystem.
Unsere anderen Ingenieure waren auch sehr beschäftigt... Tom Davies hat v1.0 unseres Useable Editor für unsere NPC KI-Anforderungen fertiggestellt, und Jeff Uriarte macht solide Fortschritte mit dem Character Archetype Editor, einem weiteren Werkzeug für unser Designteam. Andrew Nguyen war in der Forschung und Entwicklung tätig und bereitete sich auf das erste Prototyping eines anderen Berufes vor (vorläufig "Discover" genannt), und er hat gerade einen ersten Prototyp für den Bergbau-Beruf abgeschlossen.
Brian Mazza war tief in der entscheidenden Arbeit, die vom gesamten Team benötigt wurde, wie z.B. die Implementierung von Google Brakepad für bessere Crash-Berichte, die Portierung unseres Universe Backends und die Behebung von Serverfehlern, die den Teamfortschritt blockierten und die Stabilität des Build verhinderten. Gegenüber von Brian hat James Wright eng mit QA zusammengearbeitet, um die Leistung unserer verschiedenen Builds zu profilieren und zu analysieren, einschließlich eines aktuellen PTU-Builds und unseres anstehenden FPS-Builds. Diese Daten helfen uns, Problembereiche zu identifizieren, die Aufmerksamkeit erfordern, um die Gesamtleistung zu verbessern. Und James hat Clive Johnson (der kurz davor steht, seine Arbeit an der Implementierung unseres Unique Global Entity ID-Systems abzuschließen) und George Kidd vom britischen Team rekrutiert, um einige der kritischen Performance-Probleme zu untersuchen, die in seinen Profilergebnissen aufgedeckt wurden.
Auf der Tool-Seite hat Benjamin Bechtel eine neue, verbesserte Version seines Asset Validation Tools mit einer völlig neuen Benutzeroberfläche eingeführt. Dieses Tool wird täglich von unseren Künstlern verwendet. Benjamin erwartet im Juni auch einen Besuch des britischen Werkzeugingenieurs Ashly Canning, um gemeinsam an unserem Dataforge Tool zu arbeiten. Sean Tracy und Jeffery Zhu haben die erste Phase ihrer Stream-Restrukturierung eingeleitet, die wesentlich dazu beitragen wird, unsere Stream-Ströme zu rationalisieren, indem sie unsere Entwicklungsströme bis hin zu unserem Live-Produkt führen. Schließlich haben diese beiden Herren viel Zeit und Mühe darauf verwendet, Cort Soest bei unserer dringend benötigten und überlangen Aufgabe der Bereinigung unserer Perforce-Daten zu unterstützen. Die ersten beiden Phasen dieser Aufgabe sind im Mai abgeschlossen.
Das Team erwartet den Juni und freut sich darauf, seine Unterstützung für die bevorstehende FPS-Veröffentlichung sowie die weitere Arbeit an unserem kommenden Sozialmodul anzubieten.
Live-Betrieb
QA
Für das QS-Team begann May mit dem Testen und Freigeben von 1.1.2 und anschließend 1.1.3.
Mit Hilfe unseres Senior Engine Programmierers James Wright führten wir einen speziellen PTU-Test durch, der einen separaten Server-CPU-Thread zur Berechnung der Physik verwendete. Die Ergebnisse zeigten signifikante Leistungssteigerungen während der Spiele.
Es wurden Änderungen an der Art und Weise vorgenommen, wie wir verschiedene Streams und Zweige mit Perforce, unserer Versionierungskontrollsoftware, verwenden. Dies wird zu einem wesentlich strukturierteren und reibungsloseren Prozess der Release- und Feature-Integration beitragen. Dies hat auch zu einer erhöhten Arbeitsbelastung für die Qualitätssicherung geführt, um sicherzustellen, dass diese zusätzlichen Streams oder Zweige des Spiels und des Editors ordnungsgemäß getestet werden. Das Team leistet jedoch hervorragende Arbeit, um sicherzustellen, dass diese zusätzliche Testanforderung erfüllt wird.
Unsere FPS-Spezialisten waren sehr damit beschäftigt, sicherzustellen, dass Star Marine jeden Tag ordnungsgemäß getestet wird. Das Team hatte das Glück, direkt an den Designchef Todd Papy Feedback geben zu können. Todd reagierte sehr schnell auf jeden angesprochenen Punkt. Nachdem er diese Punkte besprochen hatte, beauftragte Todd alle vereinbarten Änderungen und legte Prioritäten fest. Als QA ist es sehr erfüllend, so ein Teil der Entwicklungsrichtung sein zu können.
In der Zwischenzeit hat Todd Raffray dafür gesorgt, dass das Sozialmodul ordnungsgemäß getestet wird. Todd hat einen großartigen Job gemacht, um sicherzustellen, dass alle Funktionen in einer umfassenden Checkliste dokumentiert und kontinuierlich getestet werden, während sie online gehen.
Herzlichen Glückwunsch an Miles Lee, dass er mit unserem DevOps-Team in die Rolle eines offiziellen Associate Engineers gewechselt ist! Miles hat hervorragende Arbeit geleistet und dazu beigetragen, ein Framework für die Testautomatisierung zu schaffen. Wir können nun Leistungsdaten erfassen und die meisten unserer Stabilitätsprüfungen für jeden Build automatisieren, sobald sie verfügbar sind.
Das Team drehte ihre erste Episode eines speziellen QA-Segments mit Community, wo sie einige ihrer Lieblingsfehler präsentierten.
Das Team hatte auch das Glück, an der Launch-Party der University of Texas Denius-Sams Gaming Academy mit ihrem ersten offiziellen Release namens "The Calm Before" teilzunehmen. Wir hatten viel Spaß beim Spielen! Ihr Team ist sehr talentiert. Zögern Sie nicht, sich den kostenlosen Download anzusehen!
Es war ein arbeitsreicher Monat für uns in der QA. Nächsten Monat werden wir uns intensiv mit dem Testen von Alpha 1.2 beschäftigen, um uns auf die bevorstehende Veröffentlichung vorzubereiten.
Spielunterstützung
Dieser Monat war für den Game Support sehr arbeitsreich, da wir auf einigen der Arbeiten von März und April aufgebaut haben.
Im Monat Mai wurden auch zwei Updates für den Arena Commander veröffentlicht (1.1.2 und 1.1.3). Update 1.1.2 half den Spielern bei den gefürchteten Problemen mit dem Match Not Found, Kicked Back to Lobby und Infinite Load Screen, und 1.1.3 unterstützte sie bei den anhaltenden Problemen mit dem "Gummibanding", bei denen die Spieler um die Karte sprangen. Dies ist erst der Anfang unserer Optimierungen, und wir wissen, dass Sie gespannt sein werden, wie wir Ihre Informationen weiterhin nutzen, um das Spielerlebnis zu verbessern.
In diesem Zusammenhang haben wir auch einen unglaublich erfolgreichen Playtest auf PTU mit 1.1.2 durchgeführt. Die Spieler haben sich in den PTU-Dienst gestopft, um uns zu helfen, Stresstests durchzuführen und wichtige Serveranalysen zu sammeln, und auf dem Weg dorthin hatten wir eine absolut EPIC 8v8-Runde von Spielen, die eine Runde von Diskussionen und internen Aufgaben darüber ausgelöst hat, was wir tun können, um die Spielerkappe zu erhöhen.
Im Hinblick auf den weiteren Aufbau und die Skalierung unserer Support-Betriebe für Sie war einer der größeren Punkte in diesem Monat die Schaffung einer internen Workflow- und Wissensdatenbank, die unsere Möglichkeiten, Ihnen zu helfen, erheblich erweitert. Durch die interne Veröffentlichung einer vollständigen Matrix möglicher Probleme, Fehlerbehebungsmethoden und Lösungen konnten wir mehr Mitarbeiter im Unternehmen schulen, die bei technischen Problemen helfen. Das bedeutet, dass wir einer größeren Anzahl von Menschen in kürzerer Zeit helfen können und bietet eine fantastische Grundlage für die Erweiterung unseres Teams auf dem Weg in die Sternenmarine, das Sozialmodul, die Staffel 42 und schließlich das Persistente Universum.
Wir haben auch begonnen, mit Turbulent zusammenzuarbeiten, der zwei große Initiativen für den Game Support vorantreibt: Der Community Bug Council (eine VIEL verbesserte Möglichkeit für Spieler, Beiträge einzureichen und zu sehen, welche Fehler im System aktiv sind) und eine neue, überarbeitete Version der Live Service Notification Seite, die eine begehrte Server Status Seite enthalten wird.
Sie werden in den kommenden Wochen mehr über diese beiden Punkte erfahren, aber beide sind auf unsere größeren Ziele ausgerichtet, Ihnen so schnell wie möglich genauere Informationen über den Zustand des Dienstes zu liefern.
IT/Betrieb
Der Mai war ein Monat der Geschwindigkeit für die IT. Die IT-Gruppe arbeitet hart daran, mit den wachsenden Infrastrukturanforderungen der Entwicklungsteams Schritt zu halten, und die Leistung der zentralen Speichersysteme in jedem Studio ist weiterhin eine unserer Prioritäten. Letzten Monat konzentrierten wir uns auf die interne Build-Replikation an Studios aus dem Build-System in Austin. Diesen Monat haben wir unseren Fokus auf die Leistung der zugrunde liegenden Hardware im Austin Build System selbst gelegt. Ziel dieses Projekts ist es, die Zeit für die Erstellung von Builds deutlich zu verkürzen. Die Verkürzung der Buildzeiten beschleunigt die Entwicklung und das interne Testen, aber die gesamte Build-Pipeline ist groß und komplex, so dass wir uns diesem Problem aus verschiedenen Blickwinkeln nähern.
Der erste auf der Liste war die Leistung des Speichers, auf dem die Build-Systeme laufen. Das Build-System kompiliert natürlich Code und Assets für das Spiel und die meisten dieser Arbeiten schieben die Festplatten wirklich hart. I/O-Wartezeiten können auf normalen Systemen durch die Decke gehen, und da unser Build-System viele Builds parallel kompiliert, haben wir viel Zeit verloren, indem wir nur darauf gewartet haben, dass die Festplatten aufholen. Um dieses Problem zu lösen, haben wir einen benutzerdefinierten Server mit allen Flash-Speichern und speziellen Controllern gebaut, um unsere IOPS weit über unsere aktuellen Bedürfnisse hinaus zu entwickeln. Diese eine Verbesserung unseres Build-Systems hat beeindruckende Ergebnisse mit einer Reduzierung der Buildzeiten um 66% gezeigt.
Als nächstes planen wir, weitere Sekundärsysteme auf Schnellspeicher umzustellen, was zu zusätzlichen Reduzierungen führen sollte. Schließlich werden wir parallele Verarbeitungsmethoden integrieren, um mehr CPU-Kerne in den Build-Prozess einzubringen. Dieser Schritt und einige potenzielle Ressourcen-Cachings sollten unsere Buildzeiten von Stunden auf Minuten reduzieren.
Wir haben auch eng mit DevOps zusammengearbeitet, um unsere Gebäudeautomationssysteme zu verbessern, die unserem aktuellen System Stabilität und Benutzerfreundlichkeit verleihen werden. Wir hoffen, dass wir den Rest dieser Änderungen in den nächsten Wochen umsetzen können. Im Moment sind wir sehr zufrieden mit den ersten Ergebnissen und ich denke, jeder ist gespannt, wie schnell wir diese Builds jetzt umsetzen können.
Dev Ops
Wir haben diesen Monat zwei Patches veröffentlicht, Patch 1.1.2.2 und 1.1.3, und beide wurden an einem Freitag veröffentlicht! Unser Team wird weiterhin mit dem Unternehmen zusammenarbeiten, um zu versuchen, diese Bereitstellungen auf Dienstag als Industriestandard einzugrenzen, und dann hoffentlich im Laufe einiger Jahre in eine kontinuierliche Bereitstellungspipeline übergehen, die die Notwendigkeit von Ausfallzeiten eliminieren sollte (viel davon hängt von unserem endgültigen Datenbankdesign ab).
Wir haben bei den Deployment Playtests des FPS geholfen und diese Möglichkeiten genutzt, um unseren neuen Launcher und Patcher zu testen. Bisher waren die Tests positiv, aber wir müssen noch einige weitere Polierdurchgänge durchlaufen, bevor wir sie in die PTU verschieben, damit jeder sie benutzen kann. Die Entwicklung des Launcher wird in drei Phasen unterteilt. Der erste, eine PTU-Phase, wurde bereits erwähnt. Dieser nimmt die bestehende Benutzeroberfläche und kombiniert sie mit unserem neuen Patcher. In der zweiten Phase wird eine komplette Überarbeitung des Launcher in C++ erfolgen. In Kombination mit dem neuen Patcher und der alten Benutzeroberfläche wird es Stabilitätsverbesserungen aufweisen, aber ähnlich wie der aktuelle Launcher und der kommende PTU-Launcher aussehen und funktionieren. Die dritte Phase wird eine komplett neue Benutzeroberfläche auf Basis des C++-Kerns und Patches sein. Die Einführung dieser Phasen wird mehrere Monate dauern, und weitere Informationen zu jeder Phase werden in Kürze veröffentlicht.
Schließlich ist eine Menge Arbeit damit verbunden, wie Daten im Unternehmen erstellt, gespeichert und konsumiert werden. Wir untersuchen, wie wir Zweige in Perforce verwenden, wie Daten auf den Build-Server kopiert werden, welche Daten ausgeschlossen sind, wie Entwicklungsleiter diese Daten betrachten. Initiativen für bessere Perforce-Tools, ein Ausschlusstool und einen neuen Build-Server haben die Teamzeit zusätzlich in Anspruch genommen. Der Build-Server ist ein besonders großes Projekt, das wir bis zum 14. Juli abgeschlossen haben wollen. Zu diesem Zweck ist einer der Ingenieure des Frankfurter Studios nach Austin geflogen, um in den nächsten drei Wochen mit uns zusammenzuarbeiten, damit wir an Implementierungsideen arbeiten können.
Die Arbeit an der Fertigstellung unseres Datenbankmodells und der Containerisierung der Server musste auf Eis gelegt werden, während wir unsere Tools fertig stellen, die alle von den Studios verwendeten Daten verarbeiten. Wir werden auf diese Themen zurückkommen, wenn unsere derzeit in der Entwicklung befindlichen Tools fertig sind und wenn unser Server-Team mit der Arbeit am Persistenzdienst beginnt, der die wichtigste Schnittstellenschicht zur Datenbank sein wird. Hoffentlich wird diese Arbeit in den Bericht vom Juni aufgenommen!
Hallo zusammen! Hier in der Gießerei 42 arbeiten wir an allem, vom Arena Commander (Multicrew) bis zur Staffel 42. Chris Roberts hat den letzten Monat in einem anderen Teil Englands verbracht, um die Leistung der Staffel 42 zu erfassen.... und wir arbeiten eng zusammen, um sicherzustellen, dass die dort generierten Daten in Kinofilme verwandelt werden, die Sie umhauen werden! Hier ist die Aufteilung der Abteilung nach Abteilungen, was diesen Monat in Manchester geschah:
Animation
Hier in Großbritannien arbeiten wir immer noch daran, die Bedürfnisse unserer Designer zu erfüllen. Während die Direktoren von Imaginarium weiterhin die Daten erfassen, die wir benötigen, sind wir damit beschäftigt, Block-Out-Animationen für die Design- und Code-Abteilungen bereitzustellen, um mit dem Prototyping und der Implementierung der Mechanik zu beginnen.
Wir arbeiten auch mit den verschiedenen Studios weltweit zusammen, um die Tools zu rationalisieren, die wir alle benötigen, um effizient und effektiv arbeiten zu können, um die für Squadron42 und darüber hinaus gesetzten Ziele zu erreichen.
- UK Lead Animator, Uisdean Ross.
Ingenieurwesen
Im Vorfeld
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
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
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
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
Links
No links available.
Images
28
image/jpeg
Metadata
- CIG ID
- 14758
- Channel
- Undefined
- Category
- Undefined
- Series
- Monthly Reports
- Comments
- 214
- Published
- 10 years ago (2015-06-05T00:00:00+00:00)