Monthly Studio Report: June 2015
Undefined Undefined Monthly ReportsContent
Greetings Citizens,
Summer is here (in the northern hemisphere, anyway) but we aren’t on vacation: big things are happening at CIG! Watching from the inside, it’s gratifying to see the moving parts that will form Star Citizen starting to come together. Important pieces of long-talked-about technology, like large world maps, are coming online internally and there’s an air of excitement among the development teams as the reality that a lot of what we’ve been planning for and working towards is finally happening sets in. We’re eager to share our progress with you, which means a push to get not just the Star Marine FPS module out, but to start sharing more about multicrew and the persistent world. Watch this space! As always, we’ve asked our project leads to put together individual reports for the community to let you know exactly what every part of the company has been doing. Read on!
Hey everyone! It’s been an amazing month chalked full of exciting work here in sunny Santa Monica. We love sharing with you everything we’ve been working on so enjoy and always let us know if you have any questions or thoughts!
Engineering
Our engineering team has been really busy this month. Everything from datastore clean up to the new character material system creation to large world updates. So let’s dig in:
We did some early implementation of the vehicle parameters where we were off loading the vehicles from parsing an xml on every spawn to parsing a single xml once and using it from then on to build a vehicle. Also, the only way we knew how to build a ship is to spawn it then look at what it contains. Now, other systems can just look up the parameters to build out a ship. We no longer need to spawn every ship below the hangar which was a massive change. We also had lots of integration bug fixes for FPS & Arena Commander. We continued working on the Radar 2.0 system where we moved the system from entity-only-based to practically anything the designers need to show on the HUD. The back end work is built, now we need to change HUD and other vehicle components to handle those objects so the designers can go nuts! We also did a lot of vehicle code clean up by deleting unused code which sped up a lot of the slow bits but this is going to be an ongoing process.
UI has been working tremendously hard on upcoming ship designs and implementation. Specifically, the glitch effects and boot up for the Vanduul. We reviewed a proposal for improved cockpit interaction and began preparation for HUD to support different seat actions and roles.
We’ve been doing some datastore cleanup, removing duplicated code, unifying different spread out code into single pass, and began preparation for Multicrew spawning/MP hangars. We separated object spawning from player spawning to move Hangar loading into level loading phase.
We’ve also been working on multi-layer material system. The goal is to end up with a fixed library of base materials that are blended together (up to 4 layers) to create more complex materials with minimal draw calls. Texture library and core shader functionality are mostly done, now working on the base material library that would bridge the render resources with the blended materials.
On the AI side, we’ve been doing a lot of ship bug fixing, particularly in regards to the pilot an AI ship creates and maintains. We also did a bit of work on the “defend target” wingmen command, creating an AI ship aspect that keeps track of nearby threats so that escorting ships will know what to attack.
On the Large World side, we fixed various trigger area issues in LW maps such as removed the +/- 16km limit for all the trigger areas and additional boundary conditions fix-up. We did a bit of interface clean-up for Matrix34 / Quat and established the prerequisite to make the rotational part of all those primitives to float. We also fixed the position info bar and GOTO position dialog and increased camera move speed in Sandbox while authoring LW maps. Lastly, we finished thread-safe texture loading with thread-safe shader parsing and thread-safe shader resource creation almost done. Phew, we had a great month and are looking forward to more!
Design
The design team here are keeping incredibly busy with all the upcoming ships, modes, gameplay needs, and so on. One of the bigger focuses for us was on the Genesis Starliner. We wanted to make sure we thought everything through to be ready to bring this awesome ship to you. We had a lot of work to get through this month such as establishing the initial gameplay balance plan which includes potential updates to stats, features, game modes, hud, controls, missiles, etc. Here are some of the in-depth details of this month:
We fixed an issue with the RSI Constellation Andromeda where the old Hangar Ready version would crash the hangar. Oops! We also switched the main elevator entrance from being a door to a switch to allow for entering/exiting via different doors without resetting the animation states. We also fixed both upper and lower turret hand positions. Also, in an effort to make the Constellation flight ready we overhauled thrusters.
For the Scythe dogfighter we dove into an issue in which the multilight was not loading into the light port and the archetype was crashing the client. We also removed unnecessary AI Space Ships and updated the Scythe to utilize “Scythe_Swarm” modification block to adjust AI Scythe health.
On the Hornet F7CM, we fixed an issue in which one of the thruster hard points was misnamed, preventing the thruster from loading onto the ship. We also combined the bound geometry and Weight Transfer Tool while refactoring controls design quite a bit.
On the Mustang Delta, we removed inclusion of default animations, which were colliding and causing problems (such as misplaced hatch and open/close animations not playing). We also implemented the AEGS Retaliator enter and exit Pilot Seat and updated the Interiors to use latest from Production level. That’s quite a bit of how our month went and are ready to go for the month of July.
Art
Overall, it’s been a very busy month for our art team in Santa Monica. Specifically, the vehicle artists have been busy focusing on the Merlin that just went through its final art pass and delivered to design to get flight ready. In addition, our Senior Vehicle Artist, Paul Forgy kicked off the first stages of getting the Bengal Carrier exterior white boxed and in the game engine. Can’t wait for those capital ships! With the new damage tech coming online, LA artists have been working hard to make sure the flight ready ships support the revised system. The Scythe is one of the first and has been setup for full damage support. Be sure to look for that in the near future. Now that’s not the only update to the Scythe. The ship’s cockpit has been retrofitted for human flight. Be expecting that in AC soon!
Alongside our ATX comrades, the LA studio has been working on revamping characters for not only the FPS, but for characters across all modules. Omar Aweidah is nearing finalizing the first gold standard to fully utilize the new character shader tech powered by Multi-LayerBlend written by our very own, Okka Kyaw. Now, we are ready to step up the character’s visual fidelity and take the massive leap into the future of character development for the Star Citizen universe.
Speaking of characters, our Production Designer of character concepts, Rob McKinnon is really ramping up our concept development quite heavily. We’re making great strides in developing looks for the characters of Star Citizen. 3D sculpts provided by Rob McKinnon and his team have given us our first 3d look at marine uniforms. Whether it’s a bridge office or a BDU, the marines are looking top notch. The Navy has tons of roles and responsibilities and we now have an outfit for each of them. From Officers on deck, to medics on call, the Navy uniforms are sharp and ready to begin 3d production.
With all the excitement of getting to ride the Meridian Transit, we have made sure you weren’t without a drink. The Genesis Starliner now has the very first concept designs for flight attendants. Also, the Vanduul just got a lot tougher with new images created from the concept team showing off new armor sets. The Vanduul now look meaner than ever. Under the armor has gone through revisions to attempt at finalizing the skin of this Alien race.
And that does it for the Santa Monica studio update for this month. Thank you so much for taking the time to look over all of the team’s hard work and supporting the creation of the game. None of this would be possible without your continued support and we’re honored to be able to make this game with you. We value your feedback and thoughts so keep them coming.
Hi Everyone!
It has been an unusually rainy and cool June in Texas and we’ve been enjoying it. We have hosted a number of visitors from other studios this month and we’ve been very focused on a number of different production priorities. We’ve made good progress on a number of fronts, and have a lot more work to do on the hard push to the end of the summer. Here are some detailed reports from the head of each team.
Persistent Universe Team
Art
This month the PU Concept Art Team spent the majority of their time fleshing out details of major features of the game. Ted Beargeon and Ken Fairclough crafted pieces that defined hero props for the Nyx>Delamar>Levski landing zone. We sent concepts of statues and large machinery over to BHVR to take to modeling. Likewise, some time was spent on fleshing out the Levski market area to help define the shopping experience there, as it will be different than anything we’ve done so far. Megan Cheever spent her time this month doing detail passes on various concepts of military personnel. She helped define the badges, medals, and materials you’ll see in the final game. Megan also concepted the flight attendant characters you saw in the Starliner sale this month.
Our PU Environment Team has been wrapping up the final detail passes on Levski as well. Lee Amarakoon and Emre Switzer have been providing VFX and Lighting support, respectively. Levski is beginning to look properly dark and gritty as a result of these guys’ work. Lee also got to work on revising the Customs Scanner effect you saw shown off at CitizenCon last year. Our Environment Leads, Cort Soest and Patrick Thomas, have been working with BHVR to optimize the environment itself and bring it the last 10 percent to completion. Next month Levski should be wrapped up and ready to show off somewhere down the road.
The Stanton>ArcCorp>Area18 landing zone has also been a huge focus for us this month. The environment has undergone some layout revisions to aid in optimizing it for release with the Social Module. Mark Skelton has been working in tandem with Tony Zurovec to provide direction for the changes. This environment is going to look better than ever as result.
The Character Team here in Austin just recently wrapped up the SATABall character and helmet, and it looks amazing! This was one of the first characters we took from start to finish utilizing our new Next-Gen Character Pipeline, and the new techniques have proven effective in making stellar characters for Star Citizen. We look forward to showing off David Jennison and Billy Lord’s work very soon!
The Austin Animation Team has had their hands full in several different areas of the project this month, per usual. We’re wrapping up work on the new female skeleton this week, which will allow us to finally get some ladies into the game proper! We’re also supporting Illfonic in implementing and polishing FPS animations, as well as polishing animations for Social Module. In addition, we’re working on standardizing animation templates for ship cockpits and enter/exit sequences to cut down on ship modeling time going forward. One thing you should see fairly soon are the updated G-Force animations in the cockpit. Jay Brushwood, Sean Tracy, and Jeff Zhu did a fantastic job bringing those to the next level.
Design
This month the PU Design Team spent much of their time brainstorming and fleshing out designs for upcoming player occupations in the PU. With Tony’s guidance, we have revamped the initial designs for the Bounty Hunter, Mercenary, and Piracy occupations. We’ve also drafted up designs for Smuggler and Search&Rescue occupations. The big one this month though was the Passenger Transport occupation designed by Tony Zurovec. If you haven’t had a chance to read the post from the Starliner Sale, you should totally check it out HERE.
Another thing our designers have been doing this month is testing out the new Usable Editor. The Usable Editor is part of Tony’s “Subsumption” peaceful NPC AI system. It’s the first major step towards achieving Tony’s vision for how NPC’s will interact with objects in Star Citizen. It’s been an iterative process, with the designers playing around with the Usable Editor and giving feedback, gameplay programmer Tom Davies adjusting based on that feedback, and repeat. We’re excited to see the Usable Editor in action for the first time and testing out how far we can stretch its limits.
Lastly, we are starting to dive in to the initial layouts/designs of the next planetside landing zone we want BHVR to tackle after Levksi. We’re focusing on another planetside landing zone in Stanton, going back and forth between Hurston, MicroTech, and Crusader. Which landing zone do YOU want to see come online next?
Engineering
June was spent continuing progress on a lot of longer term tasks, as well as planning and support for our upcoming releases and Gamescom demo.
There was a lot of focus on investigating ways to optimize server performance and we made some great progress on that front for upcoming Arena Commander, FPS and Social Module releases. As reported last month, our Generic Instance Manager (GIM) is in the works and incoming. The GIM will be a huge revamp of our party and matchmaking systems and it will go through multiple iterations until we’re happy with it. This first iteration has been with our QA team and they haven’t been shy about sending us bugs. We’ve been handling them quickly and getting closer and closer to what will eventually be GIM v1.0. We’re excited to reach the point when we can share it with you all, and it’s a highly anticipated system here within CIG.
Over at Wyrmbyte, in addition to being an important contributor to our server optimization investigation, they’re been deep in their iPredictor code…working diligently on hammering out the remaining kinks. Meanwhile, our tools team has been super busy with bugs and tool feature requests to help our team make the game. They never get a free moment as there’s no shortage of tools requests…and they’re happy to deliver! We also have some game-play programmers continuing to work on some proof-of-concept functional prototypes for some ofour occupations. It’s exhilarating to start seeing the early formulations of what will end up as our occupations in the Persistent Universe.
So unfortunately it’s a bit shorter of a report this month. However, it’s not due to anyone sleeping on the job, the team is mostly on long term tasks and have been making great progress on them! Many of these hope to be rolling out to you in the coming months.
Stay tuned!
Live Operations
QA
This month Star Citizen QA successfully conducted three cross-studio FPS playtests with development. Tyler Witkin has done a great job coordinating the playtests and gathering subsequent feedback.
Automation development has ramped up. Melissa Estrada and Tyler Witkin are using the Sandox Editor and Flow Graph Editor to build levels that utilize what’s known as the Feature Tester. These levels will be used to automate various ship and FPS related functionality testing.
Thanks to very informative feedback from Senior Technical Designer Rob Reininger, we have significantly improved our editor testing to include more tests related to tools and level design.
Social Module and Planetside testing continues thanks to the efforts of Todd Raffray. As soon as a system or tool is developed, Todd ensures it is added as a test case in our comprehensive Planetside testing. The latest addition is the Usable Editor. The Usable Editor is utilized to give NPC’s the ability to interact with objects. The Usable Editor is a big part of the overall Subsumtion (Peaceful NPC AI) System.
Jeffrey Pease is ensuring that the General Instance Manager is properly tested during its official implementation into Alpha 1.2.0. The General Instance Manager is our revamp of the back end lobby and matchmaking systems. Jeffrey is also leading an investigation into the prevention of potential hacks and exploits and has provided very valuable information to our engineering leads who now have a plan of action to address these issues.
Congratulations to Andrew Hesse who has transitioned into the role of QA Lead for the Austin Studio. Andrew has done an amazing job testing all aspects of the game and has been a huge help to our ship technical designers as our resident ship specialist. This month we welcome our newest addition to the QA team, Andrew Rexroth. Rex has extensive QA experience and is already a huge help with specialized Star Marine testing.
Next month, we will be continuing our testing of Alpha 1.2.0 while also looking towards testing multiplayer hangars, significantly larger play areas, the multi-crew system and much more.
Game Support
The month of June for Game Support was spent largely on designing, reviewing, and building infrastructure and processes that are going to help our backers on a service-wide level.
Particularly helpful will be our system-wide administrative broadcast tool which will allow us to provide a communication method to all players connected to a live service, which is essential to informing you with up-to-the-minute information while playing the game. We’re also working on replacing our current forum-based Live Service Notification page with its own webpage, which will ultimately include a Server Status page for all environments (Arena Commander, Star Marine, PTU, patching, etc.) and gives us an effective tool for communicating the health of the service to all players.
We’ve also continued to help triage the issues from May’s 1.1.3 release. We’ve identified and communicated the issues from the current release and actively worked with Production to get these issues highlighted and fixed, including some of the missile and ship damage state problems that we’ve been seeing.
Lastly, we’ve begun and flesh out ideas and designs for what we’re going to need to support our different environments, and particularly the Persistent Universe. Supporting gamers usually depends on the type of game, but Star Citizen will have all three (singleplayer, multiplayer, and PU)! We’ve begun to ask ourselves: What technical inefficiencies do we have in supporting our players today? What will be the expected behaviors inside the game, and what will they require from us as a service? How do we manage the raft of attempted account takeovers that occur in every PU, and what tools do we need so that players can protect themselves? How do we manage the players’ ability to go onto the secondary gray market without completely restricting it?
We don’t have the answers to all of this today, but we’re heavily invested them. These are important questions to ask in the formation of any online community, and especially the BDSSE!
IT/Operations
June has been an exciting month for the IT team. We’ve continued to make performance optimizations to our build systems and while each improvement brings great pride, we feel like we’re getting to the point where each new improvement, while important, bears smaller and smaller gains. Not all gains will come from hardware though so we’re again working closely with certain members of the DevOps team to reduce the size of data we’re moving and just as importantly reducing the number of times we need to move data. One of the remaining challenges is our asset build system. These are the graphical assets that must be rendered for each build and with the fidelity targets we’re working with, this is a very big portion of the build process. This month we’ve started the work to break that job in to many smaller jobs so we can run more of this work in parallel in order to get the overall build time down for this portion of the build. The DevOps team manages the build system logic and the IT team supplies the hardware for the jobs.
In addition to build system tuning, IT has been doing some extra travel this month. Paul from Austin and Hassan from Manchester have been traveling back and forth to our office in Frankfurt helping to plan the logistics of that studio’s office move. A good amount of planning and preparation goes in to a move like this and all is on schedule so far.
They’ve handled everything from electrical and cooling to IP addresses and VPN tunnels. Based on their hard work to get everything to fit in to a weekend, the dev team will not experience any down time.
Dennis from LA and Chris from Austin continue to build out custom configurations for testing based on feedback we’re receiving from the forums. We’re no longer just supplying reported gear to QA for one off testing. Dennis and Chris are now building and rebuilding custom systems in order to match reported systems in cases where we think hardware could be a contributing factor. They’ve also initiated early testing of Windows 10 in our test labs.
June has been an exciting and rewarding month for IT but we’ve got some even bigger things planned for July.
Dev Ops
June has been mainly consumed by 3 large projects for DevOps. The new Launcher, the new build server, and our “Phoenix” environment project.
The new launcher has already been broken into several code versions being worked on simultaneously. While the current public launcher is version 1.6, version 2.0 is in testing with the company and being used for the FPS playtests. Version 2.1 is being working on for roll out next week and will allow for faster downloads, smaller incremental patches, and some download speed improvements. Version 2.2 is coming right after that with a bunch more features, and version 3.0 is being worked on while all the rest of this process happens. Version 3.0 is a complete UI overhaul, and should be much closer to the final product.
The new build server is close to being done. We still are aiming for a mid-July release to the company with the first builds from that system going out to the public in September. For the players, they shouldn’t see any difference at all from this switch over. However for the company and the developers the improvements from this system should be huge. Not only should it allow us to run more builds at the same time, increasing the throughput of work, but reducing the amount of time developers wait for build, it will also lower overall build speeds. Currently, it takes 4hrs to make one build and we need to make around 6-8 builds a day for development to progress. As you can probably see, this is more time in the day than we have. So builds get backed up, skipped, and work slows down. The new build server will allow us to run 2-4 builds at the same time, and should reduce the 4hrs. We still need to do accurate measurements to figure out just how fast the builds will be.
As Chris Robert’s mentioned in his Letter from the Chairman, we have been working on the what we’re calling the “Phoenix” dynamic environments system. Each time the team kicks off a new build of Star Citizen all the data that the servers need is automatically copied out to hard disks in Google; this is a snapshot of our game data. These disks are broken into two to three conceptual parts: Base Image (the OS plus a few other things), Logs, and Server Data (Code and Assets). When we build an environment, we mount duplicates of these disks to each Virtual Machine (VM) that we bring up. Duplicates of the snapshot are created very rapidly, around 45 seconds for 200 gigs of data. We’ve written some automation code to automatically run commands on the VM to configure it appropriately for what type of server it will become (Game, Matchmaking, Party, etc.) During this process, a new DNS entry is assigned to the server based off the version of the data uploaded. When a new build is created, and we need to push it to an environment, we trigger a command that automatically shuts down all VM’s, unmounts the duplicated disks of the Base Image and Server Data disk (Log disks are always kept for troubleshooting), and then restarts the server with the new duplicates based of the new snapshot and the environment is running and ready on the new version.
This entire process takes about 8 minutes. When we want to take a QA environment that is built this way, and extend it to become a PTU environment, we send a command to our Provisioning layer and it goes out to Google, requests more VMs, builds more disk duplicates, mounts those snapshots, runs Chef commands to configure it, adds their DNS entries, and connects them to the existing infrastructure to be used. At that point we have a PTU environment. We repeat this process to build Production. Each time we expand an environment it takes about 8 to 10 minutes depending on the type of environment and the configurations we need.
The benefit of this dynamic creation and the environment expansion is threefold. First, any changed configs, misplaced settings, or broken processes are completely removed when the VMs are rebuilt using the new disk duplicates. Any configuration changes that need to persist should be made at the Chef level. Second, we can make absolutely sure that PTU and Production are the exact same environments that QA tested on, so there will be no strange differences we failed to catch in QA when we go live. The third benefit is simply speed. It is much faster to dynamically recreate environments on the fly than to recopy data each time. Those last two points are a pretty big deal. If our experience has taught us anything it is that having a consistent test environment that can be rolled out quickly is critically important, and this new system is pretty quick. It’s a huge force multiplier for our ability to rapidly iterate our test versions, which means QA and ultimately our backers will be able to do more varied testing more quickly. The more accurate we can get versions to our QA and to our backers the better we can ultimately make the game. July should be a very exciting month, with some of these major projects moving out of development and into production.
Greetings Citizens,
Foundry 42 is energized and ready to keep working hard! Between supporting the p-cap shoot in London, working on Squadron 42 in its own right and continuing engineering tasks for multicrew Arena Commander, we’ve been busy! Here’s the details from our department heads:
Animation
We’ve started work on breaking up some of the systemic Ai animations for enemy actions. These include things like stepping and running in to cover from various angles. Reacting to grenades and moving out of the way. As well as that the team has been working on refining some of the mechanics that are currently implemented in game to try and achieve a more responsive feel while keeping the realistic motion captured data. As always we’re on hand to provide any block out mechanics and environmental animations for the art and design teams here at Foundry 42.
Engineering
Two areas I’d like to talk about this month, which we’re getting more heavily involved with here in the UK, are the UI and AI.
On the AI front we’re taking a more active role in its development and have been doing a lot of the ground work getting our new CIGAI system up and running, alongside our colleagues in Frankfurt and Moon Collider. We have been looking at a new communication system, and how we can use it in conjunction with our current dialogue logic, to expand on the ground-work laid by the DFM survival mode’s Warlord and Vixen AI characters, as well as using it to make the cockpit audio system (a.k.a. Bitching Betty) smarter.
We’ve also been moving over some of the functionality from CryAI into our system and then amending it so it works better for our requirements on Star Citizen. So recently that has included the Tactical Point System, which includes things like cover, and the Group AI system, which allows better and easier handling of multiple AI objects, especially in the visual gameplay scripts (or the flow graph, which ever you prefer!)
On the UI we’ve been doing work here for quite some time now, but have recently started taking a bigger responsibility and taking on more of the work. We’ve been expanding the team with a new artist and a new engineer. Having the new engineer means that we can now have someone concentrating solely with bringing the User Interface requirements of Squadron 42 to life. Some of the many features that we have thrown his way are to develop the interface for the Tactical Visor and Looting. These will require various augmented reality overlays and post process effects to highlight people and objects, giving the player additional information about the world around them. We have also been performing an iteration on the visor displays for Star Marine, as each of the helmet types will have their own unique look and feel which require their own their own individual UI setup.
Our new artist is currently working on look-dev’ of the ship manufacturers, in parallel with this the ship UI code is undergoing lots of planning work so it can deal with multi-crew ships and all the challenges that throws our way, such as a captain being able to delegate (or lock out) various controls to the co-pilot or turret gunner. Planning is also underway to allow players to be able to customize their display outputs in their cockpits, giving them the ability to transfer various output to different displays. All of this planning is because, to support the functionality we require, the underlying structure that the UI code sits upon is going to need a bit of a refactor. We’ve already taken a lot of the hard coded setup of the UI and made it much more data driven (using our DataForge tool), but also were changing it to make it much more flexible, so any part of the HUD can be attached to anything else in the game that can take UI. So all of a sudden moving the radar from your visor and onto one of your cockpit displays becomes easy. This is going to be awesome!
Graphics
This month the UK graphics team have been focussing on several areas in parallel. The work on the mesh-merging tech continues, and is being trialled in larger environments such as asteroid fields to ensure it can handle any number of objects. This is coming along well and will be ready for production very soon and will start being used in public releases soon to give you better performance on new levels.
We’ve got a new senior programmer who’s been working on volumetric gas cloud rendering, investigating rendering dense clouds and soft fog with anisotropic lighting (the bright rim you get on the edge of clouds). This will be a very long term task as it’s hugely complex but is something we really want to push in our game. We’ve also been looking into facial animation technology, profiling various setups to see how far we can push the technology while maintaining a decent frame-rate. This includes trying different polygon counts, number of joints/bones in the face and the number of poses/blend-shapes that each character can use. As part of this we’ve also been investigating what we could do to push the rendering of our faces, which is no easy task when you also have to support many characters on screen. We’ll hopefully be starting this face rendering R’n’D next month and look forward to sharing the result (good or bad!).”
Design
June has been a busy month for design here with GamesCom looming. We are still flat out on Squadron 42, supporting the performance capture shoot with last minute level tweaks at the studio site to make it look at as fantastic as possible. All of the levels are looking more and more polished with a steady stream of great looking building tiles coming from our environment team that are iterated on until they look fantastic, while still allowing the level designers to layout the environments in a believable way.
We had an internal “Show-and-Tell” this month as a lot of the new staff had not seen the full depth of the plan for Star Citizen and it’s safe to say that it went fantastically well, with lots of jaw dropping amazement at depth of the game. It was great to see just how much work has actually been done in such a short period.
The technical design team has grown and is now covering tasks from FPS weapon balancing all the way to getting the Vanduul fleet operational in the engine, capital ships to fighters.
The Arena Commander team have now got the “large-world” code from the engineering team and are starting to realize what can be achieved in terms of universe size, suffice to say you should be seeing the fruits of their labours soon.
The systems designers have been finalising the specification for the “multi-functional displays” in the cockpits so that the functionality can be extended across all ships and is totally scalable from single-man ships up to larger capital ships. This is another one of our urgent tasks needed for GamesCom and will hopefully be shown in more detail very soon.
We are also trying to get a first implementation of “Quantum Jumping” ready to allow a more speedy way of navigating around the new “large-world” technology, which is looking very promising.
All in all a big month for us, but I’ve got a feeling we will be getting a lot busier in the next few months. Might be time to string up a hammock in the office soon. Thanks to everyone as always.
Art
Concept Art
Biggies this month have been the Bengal Bridge update and the Mining Bot, additional work continues on the Behring Ballistic shotgun, Xi’an transport ship, Vanduul fleet and further prop concept definition to add to the Shubin mining base and a few pirate bases needed for the Sq42 storyline (no spoilers!)
Ships
The Retaliator has been worked on this month to continue getting it ready for Flight – exciting times! Argo RUV is reaching Final art (excluding the pod which needs revisions for the cinematics), the Idris is looking very good in places, can’t wait to reveal some of it. Cutlass started its new greybox taking in to account design revisions, mining bot going to texture and material stage, Starfarer – going slower than we’d like, it’s a matter of resources, and we need more talented folk to help build this ship as its more complex than expected. Bengal Bridge will start once concepts are signed off.
Environment Art
A short update this month as much of what we’ve been doing must be kept secret for now. Progress is continuing with our VS environment which has hangars, control rooms, corridors, airlocks, and exterior landing pads – all of which can be traversed seamlessly. Hopefully we’ll be able to show you some of the really cool things we’ve been working on in the not too distant future, so stay tuned!
Props
We are getting clear documentation ready for outsource, dialling in with the techniques needed for materials which causes us most problems and then next month, we should be rolling.
VFX
The VFX team have been hard at work getting more ships “flight-ready” – this includes effects for thrusters, weapons and damage. In particular, the Scythe’s effects are looking pretty badass! We’ve also been continuing to iterate on environment effects – interior as well as exterior – for the Vertical Slice. We also began to focus on Star Marine’s weapon VFX, to make sure they’re matching the overall quality of the levels, characters and of course weapons. Truly exciting times to be a VFX artist at Foundry 42!
Audio
Hey everyone! This CIG Audio community report might meander a little, there’s a lot going on but think this should cover most of the interesting parts.
Firstly, Wwise. We’re nearly there as far as our mass of asset conversion/re-engineering is concerned; at least, the end is in sight. So Stefan, Darren and I have spent some time thinking more about how to set things up so we can mix the game well. Our game is on-going, constantly being revised of course, so the strategy we need to take is not typical to that we’d pursue for a one-shot release title. We think we have the basis of what should serve us well, and we’re changing the project structure to reflect this.
On the audio engineering side, much of it is still making sure things that used to work, work again; and ironing out any more emergent bugs/foibles that are still present. A certain ironic twist to what we’re doing is that the more we get individual sounds working, across all sorts of systems, the more we’re contributing to the problem of too many sounds playing, or being processed at some level, at once. Wwise has some ways of handling this situation, but the ideal is to make sure Wwise doesn’t get bogged down processing elements that are outside the player’s sphere of interest. At the core of it, if something is too far away to be heard, then we put it into a suspended-animation state where audio is concerned, but only to the extent that we need to so that when it comes back to life, it works as expected. There are all sorts of things to consider with this but that’s where we are right now in terms of core audio engineering. It’s not glamorous I know but it will keep things running smoothly if we get this right sooner rather than later.
We have a couple of new ships coming, one of which Darren’s been working on a lot. This had to have new dialogue recorded for its ship computer too and he’s been looking at the UI aspect, designing sounds and seeing how best to get them in. So much game UI these days is based somehow in Flash and that can be problematic for implementing sound in a way that we can iterate upon easily. So while we’re doing that we’re thinking of ways to improve this pipeline.
Incidentally, regarding the Origin ship computer, I’m holding my hands up on this one and admitting I failed to capture the previous essence of what made the ship computer so great for the Origin models. Basically, we’ve listened to you and absorbed the feedback you provided regarding the new one – and I’m absolutely determined that we’re going to win this one back. I’m not happy with it and this will be fixed!
Persistent Universe. We can’t say too much about this as yet but been ongoing support for the environmental audio for this.
FPS. So much of this is tied up in Wwise, there’s been plenty of new content required for FPS in terms of weapons, character Foley and dialogue and that’s coming along nicely. We’re getting a bunch of new music content down for FPS too. Thus we tested out a workflow where our composer, Pedro Macedo Camacho, works from his studio within Wwise, and we import what he sets up of his music into Wwise at our end. It’s not practical in terms of logistics to provide access to our own Wwise project (which is growing all the time), so testing out this workflow where he passes us a project file, has proved really valuable.
It was actually surprisingly easy to import his work-units into our Wwise project, and made me think that this might be an avenue for those of our modding community who wish to import their mods/material into Star Citizen. New assets could feasibly be produced by modders within Wwise, then passed to us for integration in the Wwise project, thus we export to sound banks etc. and pass the event triggers back to you for use. It might be a little unwieldy on the face of it, but I think ultimately working together with the modding community is the way to go to ensure a quality experience, and I’d love to try this out.
Arena Commander (or dog fighting module); a whole host of material has been converted, or some cases entirely re-created to work better than before. As Audio Director I don’t often get to do much sound design at the moment, which is obviously something of a shame as it’s what I am, at my core. So it’s been so good to be able to fit in some time for working on some ship thruster stuff and contribute in a material way to some thruster design! Luke’s taken what I’ve done and fixed it up a bit too, he’s very into the spaceship audio aspect of our game so that’s been reassuring for him to fix up my implementation. Generally a lot of this material is taking up time for all our sound designers, as it’s the lion’s share of Star Citizen right now there’s simply a lot to do but we’re whittling through it nicely.
Re: dialogue support for the Squadron 42. Our Dialogue Superman (not an official title) Bob Rissolo has still been hard at it down in London. It’s wrapping up soon, at least for now, which means he’ll be moving in-house permanently here to Foundry 42. A big move for him, we’re still hugely grateful he’s swapping sunny San Diego for the more, well, variable climate of Manchester!
Regarding our sound studios. By the time you read this we’ll have actually had our new doors installed for these. I know, doors seem like such an obvious thing to have, and of course, they are when you’re trying not to assail the rest of the studio with FPS gun sound effects, explosions and the like. But we’ve been waiting a while for a particular set of doors to be manufactured, simply we’ve been on the wrong end of some manufacturer-side production issues with them they’re each a different colour. I know that seems frivolous but when you have a number of isolated rooms and coming from another discipline, it saves time to be able to direct someone to the ‘orange sound studio’ rather than specify a room by who may or may not be there. Also means we can swap rooms to some extent. My own room is going to be a reference room for the rest of CIG Audio to test our surround mix, for instance.
Right now, tools improvements is something we’re considering. The better our tools, the easier it is for us to keep improving things. Wwise is an event-based system, and is reliant on external events of some form to trigger sounds in certain ways. For instance we want to trigger certain one shot-sounds when a thruster is transitioning from zero thrust to full thrust, on top of what we trigger for thrusters generally. And then trigger different one-shot events when the very same thruster transitions from full thrust back down to zero thrust. This is actually something that’s tricky to do ‘in the box’, the box being Wwise in this instance, so we want to be able to set-up these events more easily as sound designers rather than as programmers, so there’s a whole tool-set that we’re considering for defining logic to cater for this. This is just one tool out of many we can see a real need for.
We’re arranging to go back down to Pinewood, to record a whole bunch of duress elements for the ships. You might recall that they’ve worked with us on character Foley for FPS. There’s a new library of this sort of rattling, bone-shaking material that we’re also looking at (you can never have enough source) but we also want to make sure our stuff is that bit more individually tailored to our requirements. We’ll be taking down the Butt-kickers for this, for sure.
I’m sure there’s more stuff I’ve missed from this update, do feel free to ask us more on the Ask A Dev part of the community forums and we’ll continue to do our best to respond. Thanks for listening!
QA
UK QA have had to split our efforts this month to deal with the upcoming major events and releases. Star Marine (the FPS module) plus preparing for Gamescom, are on the cards for the near future, and Squadron 42 testing continues as normal.
Star Marine has had a lot of focus in order to root out major multiplayer bugs and try to find any general polish issues. Glenn Kneale from the UK and Tyler Witkin from ATX QA have been collaborating to make sure this game mode gets thoroughly tested. There’s been a lot of cross studio stress testing to help ensure that it should be stable once it gets released.
We’re focusing quite heavily on testing the sections of the game that will be shown at GamesCom. Unfortunately not too much can be mentioned there, but we’re all very excited about how what’s currently planned to be shown will be received.
Finally Squadron 42 is getting more testing time dedicated to it, as the game progresses we need to ensure the new mechanics are and alpha level run throughs can be completed. We also spent some time creating some more documentation to address our current plans to expand testing on S42.
Steven Brennon has continued to compile feedback from you guys and making sure it gets appropriately compiled and sent to the relevant people.
Sadly we’ll also be losing Chris “Chill” Hill at the end of the month. We wish him all the best as he’s been simply fantastic since he joined us last year, but looking forward we’re training up Steve Brennon to be a replacement lead.
June has been a busy month across all disciplines, and the team is building up in momentum. A large amount of strong applications have come in this month and we’re slowly getting through them 1 by 1. We continued to plan out our new office space, all things are set to get the keys to our new permanent office July 1st. We’ll make sure to share the new location with everyone in case anyone wants to stop by and say hi, with advanced notice of course.
Engineering
In June, Frankfurt Engineering deployed to the main codebase some major items that were planned for this month. As mentioned in the last monthly report, the Large World (moving the codebase to 64 bit coordinates), Camera Relative (rendering coordinates relative to the camera thus allowing galaxy size rendering without loss of precision), Zone system (the new Star Citizen spatial partitioning scheme, replacing Cryengine Octree) were close to hit the Star Citizen code mainline and have now been deployed, and will find their way into the various Star Citizen game modules soon.
The integration of relevant CryEngine 3.7 SDK parts, combined with our new changes, is being deployed into our codebase as we are writing this. Additionally a large effort this month was spent on supporting multi-crew vehicle ships: local physics grid, physics debugger, entities and prefabs, support for new 3D VisArea shapes, all this combined with the Zone System, are being worked on in the context of operating moveable ships. Amongst the other things, the multi-crew development process exposed a few bugs and incorrect functionalities that have been living in the CryEngine codebase for years …
We continued to work on optimizations, improved storage formats, bug fixing, clean up and general engine support to other CIG studios.
AI
During June, the AI development team has been focused mostly on the basic systems required for the human character to navigate through the full game world.
We completed the first pass on integrating the CryEngine MNM Navigation System and the multithreaded MNM Pathfinder. We also have completed the first pass on interfacing CryEngine Movement System with the current behaviour tree system. The Movement System takes care of analysing a path returned by the MNM Pathfollower and creates a plan on how to execute the movement.
Let’s imagine a character that needs to move into a cover position, the NPC will have to follow a path until the cover spot and then enter the right stance to actually position himself behind cover. The movement system allows us to have the proper context from the request to the execution of the movement, so that we can predict the necessary step the NPC has to take to correctly end up in a “behind cover” position.
We are in the middle of integrating the CryEngine Tactical Point System with our new behaviours. The Tactical Point System (or TPS) is a query system that allows us to query special position with specific properties.
In addition to the development of the systems we are taking care of creating all the glue code between the systems to allow the NPCs to have the best looking quality.
And we are also continuing coordinating the improvements on the Kythera Behavior Tree and its integration with Dataforge.
Design
This month the DE Design team has spent much of their time working on four initiatives: building a level for Squadron 42, assisting with the FPS module release, building AI behaviour trees for FPS, Squadron 42 and the Persistent Universe and then working with the UK team on Squadron 42 level feedback. We’re reviewing the missions and encounters they build for pacing, use of mechanics throughout the level, level flow and moment to moment gameplay ideas.
Animation
Currently the DE office only has 1 animator, fully focused on supporting cinematics. This month they worked on starting to set up scenes for scripted events and in-game cut scenes, getting pipeline tools identified and documented and a review of the Squadron 42 script (with the Cinematic director) to sort out which scenes will be owned by cinematics.
Cinematics
Hannes is back from the long cinematic shoot. He’ll be able to contribute to the monthly report starting next month. They had some truly talented actors on stage that gave amazing performances. We all internally look forward to pulling these together, as I’m sure the backers do as well.
Audio
Not much new for audio this month, still working on Wwise conversion that started last month. Hooked up the EVA thrusters and Ship Shield impacts to use the Wwise audio system, fixed several audio-related bugs. Started work on improving the distance-based culling of active sound emitters to let the sound designers create more detailed soundscapes without overloading the sound engine.
Build System
In June our Senior Build engineer visited our Austin studio (ATX) for 3 weeks and worked close to the Dev-Ops /IT teams on many aspects of our builds process, optimization and cross studio delivery. Among many things, the main goal was to reduce the amount of time it takes to put together a build, make patches, deploy servers and so forth.
We’ve decided to move away from the current build system in favor of something that we are confident will give us much more customization capabilities to better tailor it around our game’s needs. This is still work in progress, a lot of work has been done, and even more will be done in the next upcoming weeks.
VFX
For the past month we have been working hard on various squadron 42 effects. One of these effects has been a giant plasma drill. It is used to break up asteroids into smaller pieces for resource extraction.
Greetings Citizens!
Another whole month has gone by and we have been busy!
Engineering
As usual, a portion of the team has been focused on development for short term deliveries such as support for FPS Lobby & Flow. We’re also slowly moving away from that, now that it supports most of what we need for the first version, and have been starting to add support of multi-crew ships in the Lobby UI.
The month of June has brought us a few great features from other studios which has allowed us to work in tandem in order to add a bit more functionality to online hangars. We’ve been working hard on the current Holotable implementation in order to reduce the need for ships to be spawned in the game for them to be used in Arena Commander. This will allow us to reduce loading times as well as to facilitate management of server hosted Hangars. We have also been reworking part of the flairs implementation and Hangar spawning to work properly in such a context.
The planetside experience hasn’t been left to itself either as we’re still working on adding some features and a level of polish to the Augmented Reality (AR) experience with mobiGlas as well as the shopping experience as a whole.
Design
The design team has been setting up elevators and doors for Nyx, as well as setting up various functions (such as dynamic spawning, mobiGlas AR tags, and text string localization) for the items that will appear in Casaba outlet. We have also been doing follow-ups on the shopping experience, flair objects, and Level Design blueprints for Hurston, Crusader, and Microtech.
Art
This month we did a lot of work polishing for the Nyx asteroid map, improving materials/textures and dressing the environment to ensure that each room has a story to tell. We’ve also worked on improving one of our previous maps, modifying its layout to optimize navigation and improve performance.
Additional efforts were done on our shop system. We’ve added details on how clothing will be placed on the shelves to allow for good visibility from the player’s perspective.
Finally, as always, we’ve completed next month’s Flair object. Enjoy!
UI
The UI team has been doing quite a bit of spring cleaning (never too late!). We have been working on a thorough pass of the new holotable design flow to smooth out the whole user experience and to unify the various screens. Same goes for the simpod interface (also known as Electronic Access). We have also been cleaning up a lot of low priority tasks that have slowly and steadily been piling up.
Till next time, Citizens!
Hello Citizens!
Another month, another update. Quite a bit has happened over the last month. At the moment we have three guests from CiG (Sean Tracy, Steve Bender and Jason Hutchins) visiting us in Denver and helping out any way they can. We are currently focused on getting core locomotion as solid as we can, while still having the animations look great in both 1st and 3rd person. This isn’t easy by any means, which is why we have the extra reinforcements! You can find additional updates on the FPS module push in the weekly Star Marine update.
Engineering
Over the last month, engineering has been primarily focused on core locomotion and the start/stop/juke system. This has been close work with animators and designers, working out all the edge cases, and trying to find the absolute best balance between control response and animation quality. Everything then needs to work and be polished for both 1st and 3rd person modes. In addition to core locomotion, they have also created rules for Star Marine so that it reports stats in the same way that Arena Commander does for leaderboards and the accruement of REC. Lastly 5 different movement speeds were implemented. This makes moving with a controller very fluid and variable, depending on how much tilt is being applied to the stick.
Animation
The animators have all been laser focused on getting everything looking as good as possible with starts/stops/jukes. This has mostly involved a very quick feedback loop with Steve Bender. Getting his feedback, making tweaks and sending back the results until everybody is happy. It is a lot of work to be sure, but the team here is doing some really good work and the velocity of that work increases almost daily, now that the processes have been figured out.
Art
The art team has been working on optimizing all of the asset pieces for the Gold Horizon Station set, along with tweaking assets to match up with the metrics that are being used over at Foundry 42. This isn’t exactly the most interesting work, but it is something that needs to be done in the long run for persistent universe and Squadron 42.
Design
The design team is making numerous tweaks to the Gold Horizon level at the request of CiG. This includes some tweaks to ammo & energy placement locations, removing some doors and changing the behavior of others through the level. In addition, they are also tweaking the lines of sight throughout the level, and doing a polish pass on cover placement.
That’s all I have for you Guys and Gals this month. Until next time!
Here’s what we’ve been up to in this last month up here in Montreal:
Jump Point interview
First of all, this month our team had the opportunity to participate in an interview for an issue of Jump Point. This gave us the avenue to discuss some of the projects that we have been working for Star Citizen and shed some light on what is coming next. Thanks to David Ladyman for allowing us to go into a bit more details (and in a slightly more informal way) about our process for redesigning the site’s global look.
Starmap
This month, we completed the main art for the Starmap viewer, including Galaxy and System views. In terms of the interface, we made some significant changes to the HUD as well as filtering options (sensors and heat grid).
On the data side, we made good progress on data modeling for the upcoming Galactapedia. We also worked on our own administration tools so that we can import data from the Star Citizen universe. This will allow for having all the data of the different celestial objects already in a Galactapedia format.
On the 3D front, we started production of the different assets that will be displayed in the WebGL viewer (planet, jump point, space station, etc). This is very work intensive and it’s what the user will see on their screen, and so we’ll be working on this for the next couple of months.
Issue Council
As reported last time, we have continually been evolving the Issue Council to ensure that it greatly reduces the amount of time/effort for everyone involved. We have also been working to make sure that it cannot be easily swayed by large groups of users (such as organizations). We have been adding new features, re-organizing layouts, moving things from one page to another, removing pages, and so on — so much so that when we took a step back and looked at it all we realized that the UI was no longer intuitive. So we gathered the team around a big whiteboard and worked on fixing this.
The core update we worked out was an updated flow for the users. Upon arrival at the Issue Council, users will be provided with three ways of approaching the system:
Contribute by attempting to replicate issues and flagging invalid tickets (duplicates, feature-requests, poorly written, etc).
Prioritize the confirmed tickets to help the developers know what is important to the community.
Search all tickets that have ever been created.
We will soon have some designs to share, but to give a bit of insight here’s a photo of one of Benoit’s whiteboard designs.
Community Hub
The Community hub has entered its final stretch, and our developers have been working on actually implementing it for the whole month. The main notable undertaking on this specific project was to set up the submission flows. These will allow you to upload pictures and galleries of your own creations, embed your youtube play sessions, or report interesting links you’ve found elsewhere, which requires a great deal of technical flexibility from the website itself. Even more interesting was that we took some time devising filters and sorting algorithms based on the amount and frequency of content posted and their popularity through upvotes and comments. It’s always an exciting challenge to devise the way a website will display its own content, to keep it as relevant and fresh as possible.
Moderation tools
Another project that we have been working on, which has recently launched, was the new Moderation Tools, for the site’s dedicated team of moderators. These tools now give them more insight into flagged contents, repeat offenders and infamous recidivists, as well as a quicker way to manage forum access. This allows them to keep the forums, comments and Orgs running even more smoothly and efficiently. With their help, we’ve devised a set of tools that will then be expandable to cover all user-generated contents, including all aspects of the upcoming Community Hub as well.
This month’s concept sale was a short story showcasing the Genesis Starliner as operated by Meridian Transit. This quick tear-jerker (go read the postcards) was written by Star Citizen’s own writers, and along with some pretty cool art and voiceovers from the Community team, it gave us a lot of room to have fun with the post. This is why it quickly became one of the site’s most script-heavy pages, with mini components like the Flight board or the flipping postcards. The flight board itself was based on a very early concept for the Events block on the website’s homepage, which we were really fond of but put too much stress on browsers. So we were really happy to be able to use it anyway as part of the short story.
What you didn’t see
Just like for any other month, our programmers were also tasked with improvements and fixes that have gone unnoticed, thankfully. Prominent this June were the payment processors that we use : Amazon migrated their whole payment system, which we had to adapt to, along with transitioning to an entirely new way of handling subscriptions. Another one that shall remain unnamed cough*paypal*cough also had some interesting surprises for us that we had to react to very quickly. We’ve also dedicated some time to providing new tools to the Customer Service team, to help them deal with problematic cases even more efficiently.
It’s been another busy month at Moon Collider, so let’s jump straight into it:
Engineering
It’s a well known saying that no plan survives contact with the enemy, and I think an equally valid saying would be no tool survives contact with the designers! No matter how well you design any new tool, the moment designers start playing with it you’ll find out very fast what needs improvement. Last month we gave designers the ability to write behavior trees using an editor built into DataForge, Star Citizen’s custom data management tool. We tried to get it into designer hands as quickly as we could, so we already had a decent sized todo list of improvements we knew were needed, but a few hours of real use of a tool by a designer always helps to clarify which issues are minor annoyances, and which ones frequently interrupt their workflow or straight up make them unable to do some task.
We spent some time this month getting feedback from designers and working through their prioritized list of issues with the new editor. This included things as simple as writing up more documentation on how certain features worked; renaming, recategorizing and recoloring BT nodes in ways that are more intuitive to a designer; and even moving certain advanced pieces of functionality out of the standard workflow so that it’s a little more laborious to use those rarely needed features but it makes the common features more streamlined. We expect to continue improving this tool next month as the feedback from designers keeps on coming through.
With the designers now working on behavior trees with DataForge, it was also perfect timing for adding a behavior tree live view to our Kythera Inspector web based debugging tool. This is a web page that designers can bring up that gives direct access to the state of the AI in their game, and we’ve been constantly added features to it in order to make debugging AI easier. Up to now we’ve been relying on some simple on screen text debugging to help us understand the current state of an AI’s behavior tree, and while this worked reasonably well for a small and simple tree, it was much less useful for larger trees, and also limited in the information provided.
The new live view in Inspector allows designers to see the state of the behavior tree of any AI while the game is running. We have some new features coming next month that will allow this view to help them track down configuration errors with their trees, which, when combined with the already existing ability to record and play back the behavior trees of the AI, should give designers a comprehensive suite of tools for debugging their behavior trees.
One issue we’ve been trying to sort out for a while is a technical feature we call a string hash. This is something that is built into Kythera and basically allows us to convert any text string in the code into a numerical identifier at compile time. This makes it cheap and efficient to pass strings around in the code and use them without worrying about it being expensive to do comparisons, which is usually the case with strings. And this means that you can have a lot more descriptive text being passed around in your code rather than simple numbers, which can make code that’s easier to work with and easier to debug.
Because this is such a useful feature, a similar version has been added to the rest of the Star Citizen codebase. What we’ve been trying to work out is how best to unify these two different versions of string hashes, so we can avoid the cost of converting between them. There are various details that make this trickier to solve in a satisfying way than it might initially seem, so we’ve been spending time working this out with coders in some of the other studios and are currently testing some possible solutions to try them out and see if they cause problems in practice.
Now, let’s talk ships!
Last month we added in the feature that allows ships to reliably join splines. This month we started making good use of that feature in the form of retreat stunt splines. Stunt splines are paths that are laid down by designers in a level and allow AI to fly through tight areas where their collision avoidance would otherwise stop them from going, such as through a tunnel in an asteroid or gaps between sections of a space station.
One of the main goals of these stunt splines is to set up opportunities for players to chase AI through interesting and exciting paths. We’ve added them to AI retreat behaviors so that when an AI ship wants to break away from a pursuer, if there is a stunt spline nearby it will try to make use of it. To keep things believable, the AI will only pick a spline if it can get onto it quickly, so they won’t use one if it requires a major change in speed or direction to get to it.
We can also use them to distinguish elite AI pilots from rookies by having a skill level attached to the spline. So a really hairy maneuver can be marked as only available to the best pilots. This also means that if you go to chase a fleeing elite ship, you may find yourself in a chase that you’re not good enough to pull off, and you’ll need to make a quick decision on just how crazy a pilot you’re willing to be!
Once designers have had a chance to work with this feature, we plan to make some refinements to the spline selection process to get a good balance so they’re not overused or underused. It’s important that the AI don’t become too predictable to a player who is familiar with a map, but on the other hand, seeing a ship break off and head towards that tunnel you know is great fun to fly through can be something to anticipate as well.
As is always the case with new features, we’re looking forward to seeing this one get into the hands of real players and hearing the cool stories that come from it!
Greetings Citizens,
We always say that it has been a busy month for the community team, but at this point… what month isn’t busy?
We were very happy this month to celebrate the first anniversary of Around the Verse! AtV has been an interesting project for us; last year, we went into the s how dreading the need to replace fan favorite Wingman’s Hangar… and we took time to find our feet and figure out what was important. Thanks to your feedback (and your support!) we’re proud of what the show has become… and we’re going to try and keep making it better. Episode 50, aired last week, had one especially standout segment in which designer Randy Vasquez showed his process for building Starliner interiors. Expect to see more segments like this in the future, as we felt it was our strongest piece yet.
We’ve also asked the community team to be more interactive on the forums. We’re just as eager to see Star Marine release as the rest of the community, and we’re going to do our best to get out there and not just show the flag but share our answers and thoughts with all of you. A Community Manager can’t always answer your questions… but we’re here to address what we can and also listen to your concerns and make sure developers are aware of them. Even better, we’re working on a relaunch of the ‘Ask a Dev’ process, which will hopefully result in a system for getting your questions answered by the experts.
The whole team also had a field day with the Genesis Starliner sale. We wanted to get across just how much depth there was to the ship, and the whole team worked together to add pieces to the presentation that we thought would interest the community. From Jared’s postcards to Ryan’s safety card, we wanted to show you more than just how big the guns were (and if we’re being honest, the guns are not that big in the first place.)
Finally, we’re very sad to lose one of our own: Chelsea Day, manager of the Customer Service team, has left CIG to relocate. Chelsea was a good friend and a great CS manager; we’re all going to miss her! Patrick Probst, who you may have seen on the forums, will be taking over the CS manager position in the UK. So congratulations – we know you’ll live up to the example Chelsea set!
Summer is here (in the northern hemisphere, anyway) but we aren’t on vacation: big things are happening at CIG! Watching from the inside, it’s gratifying to see the moving parts that will form Star Citizen starting to come together. Important pieces of long-talked-about technology, like large world maps, are coming online internally and there’s an air of excitement among the development teams as the reality that a lot of what we’ve been planning for and working towards is finally happening sets in. We’re eager to share our progress with you, which means a push to get not just the Star Marine FPS module out, but to start sharing more about multicrew and the persistent world. Watch this space! As always, we’ve asked our project leads to put together individual reports for the community to let you know exactly what every part of the company has been doing. Read on!
Hey everyone! It’s been an amazing month chalked full of exciting work here in sunny Santa Monica. We love sharing with you everything we’ve been working on so enjoy and always let us know if you have any questions or thoughts!
Engineering
Our engineering team has been really busy this month. Everything from datastore clean up to the new character material system creation to large world updates. So let’s dig in:
We did some early implementation of the vehicle parameters where we were off loading the vehicles from parsing an xml on every spawn to parsing a single xml once and using it from then on to build a vehicle. Also, the only way we knew how to build a ship is to spawn it then look at what it contains. Now, other systems can just look up the parameters to build out a ship. We no longer need to spawn every ship below the hangar which was a massive change. We also had lots of integration bug fixes for FPS & Arena Commander. We continued working on the Radar 2.0 system where we moved the system from entity-only-based to practically anything the designers need to show on the HUD. The back end work is built, now we need to change HUD and other vehicle components to handle those objects so the designers can go nuts! We also did a lot of vehicle code clean up by deleting unused code which sped up a lot of the slow bits but this is going to be an ongoing process.
UI has been working tremendously hard on upcoming ship designs and implementation. Specifically, the glitch effects and boot up for the Vanduul. We reviewed a proposal for improved cockpit interaction and began preparation for HUD to support different seat actions and roles.
We’ve been doing some datastore cleanup, removing duplicated code, unifying different spread out code into single pass, and began preparation for Multicrew spawning/MP hangars. We separated object spawning from player spawning to move Hangar loading into level loading phase.
We’ve also been working on multi-layer material system. The goal is to end up with a fixed library of base materials that are blended together (up to 4 layers) to create more complex materials with minimal draw calls. Texture library and core shader functionality are mostly done, now working on the base material library that would bridge the render resources with the blended materials.
On the AI side, we’ve been doing a lot of ship bug fixing, particularly in regards to the pilot an AI ship creates and maintains. We also did a bit of work on the “defend target” wingmen command, creating an AI ship aspect that keeps track of nearby threats so that escorting ships will know what to attack.
On the Large World side, we fixed various trigger area issues in LW maps such as removed the +/- 16km limit for all the trigger areas and additional boundary conditions fix-up. We did a bit of interface clean-up for Matrix34 / Quat and established the prerequisite to make the rotational part of all those primitives to float. We also fixed the position info bar and GOTO position dialog and increased camera move speed in Sandbox while authoring LW maps. Lastly, we finished thread-safe texture loading with thread-safe shader parsing and thread-safe shader resource creation almost done. Phew, we had a great month and are looking forward to more!
Design
The design team here are keeping incredibly busy with all the upcoming ships, modes, gameplay needs, and so on. One of the bigger focuses for us was on the Genesis Starliner. We wanted to make sure we thought everything through to be ready to bring this awesome ship to you. We had a lot of work to get through this month such as establishing the initial gameplay balance plan which includes potential updates to stats, features, game modes, hud, controls, missiles, etc. Here are some of the in-depth details of this month:
We fixed an issue with the RSI Constellation Andromeda where the old Hangar Ready version would crash the hangar. Oops! We also switched the main elevator entrance from being a door to a switch to allow for entering/exiting via different doors without resetting the animation states. We also fixed both upper and lower turret hand positions. Also, in an effort to make the Constellation flight ready we overhauled thrusters.
For the Scythe dogfighter we dove into an issue in which the multilight was not loading into the light port and the archetype was crashing the client. We also removed unnecessary AI Space Ships and updated the Scythe to utilize “Scythe_Swarm” modification block to adjust AI Scythe health.
On the Hornet F7CM, we fixed an issue in which one of the thruster hard points was misnamed, preventing the thruster from loading onto the ship. We also combined the bound geometry and Weight Transfer Tool while refactoring controls design quite a bit.
On the Mustang Delta, we removed inclusion of default animations, which were colliding and causing problems (such as misplaced hatch and open/close animations not playing). We also implemented the AEGS Retaliator enter and exit Pilot Seat and updated the Interiors to use latest from Production level. That’s quite a bit of how our month went and are ready to go for the month of July.
Art
Overall, it’s been a very busy month for our art team in Santa Monica. Specifically, the vehicle artists have been busy focusing on the Merlin that just went through its final art pass and delivered to design to get flight ready. In addition, our Senior Vehicle Artist, Paul Forgy kicked off the first stages of getting the Bengal Carrier exterior white boxed and in the game engine. Can’t wait for those capital ships! With the new damage tech coming online, LA artists have been working hard to make sure the flight ready ships support the revised system. The Scythe is one of the first and has been setup for full damage support. Be sure to look for that in the near future. Now that’s not the only update to the Scythe. The ship’s cockpit has been retrofitted for human flight. Be expecting that in AC soon!
Alongside our ATX comrades, the LA studio has been working on revamping characters for not only the FPS, but for characters across all modules. Omar Aweidah is nearing finalizing the first gold standard to fully utilize the new character shader tech powered by Multi-LayerBlend written by our very own, Okka Kyaw. Now, we are ready to step up the character’s visual fidelity and take the massive leap into the future of character development for the Star Citizen universe.
Speaking of characters, our Production Designer of character concepts, Rob McKinnon is really ramping up our concept development quite heavily. We’re making great strides in developing looks for the characters of Star Citizen. 3D sculpts provided by Rob McKinnon and his team have given us our first 3d look at marine uniforms. Whether it’s a bridge office or a BDU, the marines are looking top notch. The Navy has tons of roles and responsibilities and we now have an outfit for each of them. From Officers on deck, to medics on call, the Navy uniforms are sharp and ready to begin 3d production.
With all the excitement of getting to ride the Meridian Transit, we have made sure you weren’t without a drink. The Genesis Starliner now has the very first concept designs for flight attendants. Also, the Vanduul just got a lot tougher with new images created from the concept team showing off new armor sets. The Vanduul now look meaner than ever. Under the armor has gone through revisions to attempt at finalizing the skin of this Alien race.
And that does it for the Santa Monica studio update for this month. Thank you so much for taking the time to look over all of the team’s hard work and supporting the creation of the game. None of this would be possible without your continued support and we’re honored to be able to make this game with you. We value your feedback and thoughts so keep them coming.
Hi Everyone!
It has been an unusually rainy and cool June in Texas and we’ve been enjoying it. We have hosted a number of visitors from other studios this month and we’ve been very focused on a number of different production priorities. We’ve made good progress on a number of fronts, and have a lot more work to do on the hard push to the end of the summer. Here are some detailed reports from the head of each team.
Persistent Universe Team
Art
This month the PU Concept Art Team spent the majority of their time fleshing out details of major features of the game. Ted Beargeon and Ken Fairclough crafted pieces that defined hero props for the Nyx>Delamar>Levski landing zone. We sent concepts of statues and large machinery over to BHVR to take to modeling. Likewise, some time was spent on fleshing out the Levski market area to help define the shopping experience there, as it will be different than anything we’ve done so far. Megan Cheever spent her time this month doing detail passes on various concepts of military personnel. She helped define the badges, medals, and materials you’ll see in the final game. Megan also concepted the flight attendant characters you saw in the Starliner sale this month.
Our PU Environment Team has been wrapping up the final detail passes on Levski as well. Lee Amarakoon and Emre Switzer have been providing VFX and Lighting support, respectively. Levski is beginning to look properly dark and gritty as a result of these guys’ work. Lee also got to work on revising the Customs Scanner effect you saw shown off at CitizenCon last year. Our Environment Leads, Cort Soest and Patrick Thomas, have been working with BHVR to optimize the environment itself and bring it the last 10 percent to completion. Next month Levski should be wrapped up and ready to show off somewhere down the road.
The Stanton>ArcCorp>Area18 landing zone has also been a huge focus for us this month. The environment has undergone some layout revisions to aid in optimizing it for release with the Social Module. Mark Skelton has been working in tandem with Tony Zurovec to provide direction for the changes. This environment is going to look better than ever as result.
The Character Team here in Austin just recently wrapped up the SATABall character and helmet, and it looks amazing! This was one of the first characters we took from start to finish utilizing our new Next-Gen Character Pipeline, and the new techniques have proven effective in making stellar characters for Star Citizen. We look forward to showing off David Jennison and Billy Lord’s work very soon!
The Austin Animation Team has had their hands full in several different areas of the project this month, per usual. We’re wrapping up work on the new female skeleton this week, which will allow us to finally get some ladies into the game proper! We’re also supporting Illfonic in implementing and polishing FPS animations, as well as polishing animations for Social Module. In addition, we’re working on standardizing animation templates for ship cockpits and enter/exit sequences to cut down on ship modeling time going forward. One thing you should see fairly soon are the updated G-Force animations in the cockpit. Jay Brushwood, Sean Tracy, and Jeff Zhu did a fantastic job bringing those to the next level.
Design
This month the PU Design Team spent much of their time brainstorming and fleshing out designs for upcoming player occupations in the PU. With Tony’s guidance, we have revamped the initial designs for the Bounty Hunter, Mercenary, and Piracy occupations. We’ve also drafted up designs for Smuggler and Search&Rescue occupations. The big one this month though was the Passenger Transport occupation designed by Tony Zurovec. If you haven’t had a chance to read the post from the Starliner Sale, you should totally check it out HERE.
Another thing our designers have been doing this month is testing out the new Usable Editor. The Usable Editor is part of Tony’s “Subsumption” peaceful NPC AI system. It’s the first major step towards achieving Tony’s vision for how NPC’s will interact with objects in Star Citizen. It’s been an iterative process, with the designers playing around with the Usable Editor and giving feedback, gameplay programmer Tom Davies adjusting based on that feedback, and repeat. We’re excited to see the Usable Editor in action for the first time and testing out how far we can stretch its limits.
Lastly, we are starting to dive in to the initial layouts/designs of the next planetside landing zone we want BHVR to tackle after Levksi. We’re focusing on another planetside landing zone in Stanton, going back and forth between Hurston, MicroTech, and Crusader. Which landing zone do YOU want to see come online next?
Engineering
June was spent continuing progress on a lot of longer term tasks, as well as planning and support for our upcoming releases and Gamescom demo.
There was a lot of focus on investigating ways to optimize server performance and we made some great progress on that front for upcoming Arena Commander, FPS and Social Module releases. As reported last month, our Generic Instance Manager (GIM) is in the works and incoming. The GIM will be a huge revamp of our party and matchmaking systems and it will go through multiple iterations until we’re happy with it. This first iteration has been with our QA team and they haven’t been shy about sending us bugs. We’ve been handling them quickly and getting closer and closer to what will eventually be GIM v1.0. We’re excited to reach the point when we can share it with you all, and it’s a highly anticipated system here within CIG.
Over at Wyrmbyte, in addition to being an important contributor to our server optimization investigation, they’re been deep in their iPredictor code…working diligently on hammering out the remaining kinks. Meanwhile, our tools team has been super busy with bugs and tool feature requests to help our team make the game. They never get a free moment as there’s no shortage of tools requests…and they’re happy to deliver! We also have some game-play programmers continuing to work on some proof-of-concept functional prototypes for some ofour occupations. It’s exhilarating to start seeing the early formulations of what will end up as our occupations in the Persistent Universe.
So unfortunately it’s a bit shorter of a report this month. However, it’s not due to anyone sleeping on the job, the team is mostly on long term tasks and have been making great progress on them! Many of these hope to be rolling out to you in the coming months.
Stay tuned!
Live Operations
QA
This month Star Citizen QA successfully conducted three cross-studio FPS playtests with development. Tyler Witkin has done a great job coordinating the playtests and gathering subsequent feedback.
Automation development has ramped up. Melissa Estrada and Tyler Witkin are using the Sandox Editor and Flow Graph Editor to build levels that utilize what’s known as the Feature Tester. These levels will be used to automate various ship and FPS related functionality testing.
Thanks to very informative feedback from Senior Technical Designer Rob Reininger, we have significantly improved our editor testing to include more tests related to tools and level design.
Social Module and Planetside testing continues thanks to the efforts of Todd Raffray. As soon as a system or tool is developed, Todd ensures it is added as a test case in our comprehensive Planetside testing. The latest addition is the Usable Editor. The Usable Editor is utilized to give NPC’s the ability to interact with objects. The Usable Editor is a big part of the overall Subsumtion (Peaceful NPC AI) System.
Jeffrey Pease is ensuring that the General Instance Manager is properly tested during its official implementation into Alpha 1.2.0. The General Instance Manager is our revamp of the back end lobby and matchmaking systems. Jeffrey is also leading an investigation into the prevention of potential hacks and exploits and has provided very valuable information to our engineering leads who now have a plan of action to address these issues.
Congratulations to Andrew Hesse who has transitioned into the role of QA Lead for the Austin Studio. Andrew has done an amazing job testing all aspects of the game and has been a huge help to our ship technical designers as our resident ship specialist. This month we welcome our newest addition to the QA team, Andrew Rexroth. Rex has extensive QA experience and is already a huge help with specialized Star Marine testing.
Next month, we will be continuing our testing of Alpha 1.2.0 while also looking towards testing multiplayer hangars, significantly larger play areas, the multi-crew system and much more.
Game Support
The month of June for Game Support was spent largely on designing, reviewing, and building infrastructure and processes that are going to help our backers on a service-wide level.
Particularly helpful will be our system-wide administrative broadcast tool which will allow us to provide a communication method to all players connected to a live service, which is essential to informing you with up-to-the-minute information while playing the game. We’re also working on replacing our current forum-based Live Service Notification page with its own webpage, which will ultimately include a Server Status page for all environments (Arena Commander, Star Marine, PTU, patching, etc.) and gives us an effective tool for communicating the health of the service to all players.
We’ve also continued to help triage the issues from May’s 1.1.3 release. We’ve identified and communicated the issues from the current release and actively worked with Production to get these issues highlighted and fixed, including some of the missile and ship damage state problems that we’ve been seeing.
Lastly, we’ve begun and flesh out ideas and designs for what we’re going to need to support our different environments, and particularly the Persistent Universe. Supporting gamers usually depends on the type of game, but Star Citizen will have all three (singleplayer, multiplayer, and PU)! We’ve begun to ask ourselves: What technical inefficiencies do we have in supporting our players today? What will be the expected behaviors inside the game, and what will they require from us as a service? How do we manage the raft of attempted account takeovers that occur in every PU, and what tools do we need so that players can protect themselves? How do we manage the players’ ability to go onto the secondary gray market without completely restricting it?
We don’t have the answers to all of this today, but we’re heavily invested them. These are important questions to ask in the formation of any online community, and especially the BDSSE!
IT/Operations
June has been an exciting month for the IT team. We’ve continued to make performance optimizations to our build systems and while each improvement brings great pride, we feel like we’re getting to the point where each new improvement, while important, bears smaller and smaller gains. Not all gains will come from hardware though so we’re again working closely with certain members of the DevOps team to reduce the size of data we’re moving and just as importantly reducing the number of times we need to move data. One of the remaining challenges is our asset build system. These are the graphical assets that must be rendered for each build and with the fidelity targets we’re working with, this is a very big portion of the build process. This month we’ve started the work to break that job in to many smaller jobs so we can run more of this work in parallel in order to get the overall build time down for this portion of the build. The DevOps team manages the build system logic and the IT team supplies the hardware for the jobs.
In addition to build system tuning, IT has been doing some extra travel this month. Paul from Austin and Hassan from Manchester have been traveling back and forth to our office in Frankfurt helping to plan the logistics of that studio’s office move. A good amount of planning and preparation goes in to a move like this and all is on schedule so far.
They’ve handled everything from electrical and cooling to IP addresses and VPN tunnels. Based on their hard work to get everything to fit in to a weekend, the dev team will not experience any down time.
Dennis from LA and Chris from Austin continue to build out custom configurations for testing based on feedback we’re receiving from the forums. We’re no longer just supplying reported gear to QA for one off testing. Dennis and Chris are now building and rebuilding custom systems in order to match reported systems in cases where we think hardware could be a contributing factor. They’ve also initiated early testing of Windows 10 in our test labs.
June has been an exciting and rewarding month for IT but we’ve got some even bigger things planned for July.
Dev Ops
June has been mainly consumed by 3 large projects for DevOps. The new Launcher, the new build server, and our “Phoenix” environment project.
The new launcher has already been broken into several code versions being worked on simultaneously. While the current public launcher is version 1.6, version 2.0 is in testing with the company and being used for the FPS playtests. Version 2.1 is being working on for roll out next week and will allow for faster downloads, smaller incremental patches, and some download speed improvements. Version 2.2 is coming right after that with a bunch more features, and version 3.0 is being worked on while all the rest of this process happens. Version 3.0 is a complete UI overhaul, and should be much closer to the final product.
The new build server is close to being done. We still are aiming for a mid-July release to the company with the first builds from that system going out to the public in September. For the players, they shouldn’t see any difference at all from this switch over. However for the company and the developers the improvements from this system should be huge. Not only should it allow us to run more builds at the same time, increasing the throughput of work, but reducing the amount of time developers wait for build, it will also lower overall build speeds. Currently, it takes 4hrs to make one build and we need to make around 6-8 builds a day for development to progress. As you can probably see, this is more time in the day than we have. So builds get backed up, skipped, and work slows down. The new build server will allow us to run 2-4 builds at the same time, and should reduce the 4hrs. We still need to do accurate measurements to figure out just how fast the builds will be.
As Chris Robert’s mentioned in his Letter from the Chairman, we have been working on the what we’re calling the “Phoenix” dynamic environments system. Each time the team kicks off a new build of Star Citizen all the data that the servers need is automatically copied out to hard disks in Google; this is a snapshot of our game data. These disks are broken into two to three conceptual parts: Base Image (the OS plus a few other things), Logs, and Server Data (Code and Assets). When we build an environment, we mount duplicates of these disks to each Virtual Machine (VM) that we bring up. Duplicates of the snapshot are created very rapidly, around 45 seconds for 200 gigs of data. We’ve written some automation code to automatically run commands on the VM to configure it appropriately for what type of server it will become (Game, Matchmaking, Party, etc.) During this process, a new DNS entry is assigned to the server based off the version of the data uploaded. When a new build is created, and we need to push it to an environment, we trigger a command that automatically shuts down all VM’s, unmounts the duplicated disks of the Base Image and Server Data disk (Log disks are always kept for troubleshooting), and then restarts the server with the new duplicates based of the new snapshot and the environment is running and ready on the new version.
This entire process takes about 8 minutes. When we want to take a QA environment that is built this way, and extend it to become a PTU environment, we send a command to our Provisioning layer and it goes out to Google, requests more VMs, builds more disk duplicates, mounts those snapshots, runs Chef commands to configure it, adds their DNS entries, and connects them to the existing infrastructure to be used. At that point we have a PTU environment. We repeat this process to build Production. Each time we expand an environment it takes about 8 to 10 minutes depending on the type of environment and the configurations we need.
The benefit of this dynamic creation and the environment expansion is threefold. First, any changed configs, misplaced settings, or broken processes are completely removed when the VMs are rebuilt using the new disk duplicates. Any configuration changes that need to persist should be made at the Chef level. Second, we can make absolutely sure that PTU and Production are the exact same environments that QA tested on, so there will be no strange differences we failed to catch in QA when we go live. The third benefit is simply speed. It is much faster to dynamically recreate environments on the fly than to recopy data each time. Those last two points are a pretty big deal. If our experience has taught us anything it is that having a consistent test environment that can be rolled out quickly is critically important, and this new system is pretty quick. It’s a huge force multiplier for our ability to rapidly iterate our test versions, which means QA and ultimately our backers will be able to do more varied testing more quickly. The more accurate we can get versions to our QA and to our backers the better we can ultimately make the game. July should be a very exciting month, with some of these major projects moving out of development and into production.
Greetings Citizens,
Foundry 42 is energized and ready to keep working hard! Between supporting the p-cap shoot in London, working on Squadron 42 in its own right and continuing engineering tasks for multicrew Arena Commander, we’ve been busy! Here’s the details from our department heads:
Animation
We’ve started work on breaking up some of the systemic Ai animations for enemy actions. These include things like stepping and running in to cover from various angles. Reacting to grenades and moving out of the way. As well as that the team has been working on refining some of the mechanics that are currently implemented in game to try and achieve a more responsive feel while keeping the realistic motion captured data. As always we’re on hand to provide any block out mechanics and environmental animations for the art and design teams here at Foundry 42.
Engineering
Two areas I’d like to talk about this month, which we’re getting more heavily involved with here in the UK, are the UI and AI.
On the AI front we’re taking a more active role in its development and have been doing a lot of the ground work getting our new CIGAI system up and running, alongside our colleagues in Frankfurt and Moon Collider. We have been looking at a new communication system, and how we can use it in conjunction with our current dialogue logic, to expand on the ground-work laid by the DFM survival mode’s Warlord and Vixen AI characters, as well as using it to make the cockpit audio system (a.k.a. Bitching Betty) smarter.
We’ve also been moving over some of the functionality from CryAI into our system and then amending it so it works better for our requirements on Star Citizen. So recently that has included the Tactical Point System, which includes things like cover, and the Group AI system, which allows better and easier handling of multiple AI objects, especially in the visual gameplay scripts (or the flow graph, which ever you prefer!)
On the UI we’ve been doing work here for quite some time now, but have recently started taking a bigger responsibility and taking on more of the work. We’ve been expanding the team with a new artist and a new engineer. Having the new engineer means that we can now have someone concentrating solely with bringing the User Interface requirements of Squadron 42 to life. Some of the many features that we have thrown his way are to develop the interface for the Tactical Visor and Looting. These will require various augmented reality overlays and post process effects to highlight people and objects, giving the player additional information about the world around them. We have also been performing an iteration on the visor displays for Star Marine, as each of the helmet types will have their own unique look and feel which require their own their own individual UI setup.
Our new artist is currently working on look-dev’ of the ship manufacturers, in parallel with this the ship UI code is undergoing lots of planning work so it can deal with multi-crew ships and all the challenges that throws our way, such as a captain being able to delegate (or lock out) various controls to the co-pilot or turret gunner. Planning is also underway to allow players to be able to customize their display outputs in their cockpits, giving them the ability to transfer various output to different displays. All of this planning is because, to support the functionality we require, the underlying structure that the UI code sits upon is going to need a bit of a refactor. We’ve already taken a lot of the hard coded setup of the UI and made it much more data driven (using our DataForge tool), but also were changing it to make it much more flexible, so any part of the HUD can be attached to anything else in the game that can take UI. So all of a sudden moving the radar from your visor and onto one of your cockpit displays becomes easy. This is going to be awesome!
Graphics
This month the UK graphics team have been focussing on several areas in parallel. The work on the mesh-merging tech continues, and is being trialled in larger environments such as asteroid fields to ensure it can handle any number of objects. This is coming along well and will be ready for production very soon and will start being used in public releases soon to give you better performance on new levels.
We’ve got a new senior programmer who’s been working on volumetric gas cloud rendering, investigating rendering dense clouds and soft fog with anisotropic lighting (the bright rim you get on the edge of clouds). This will be a very long term task as it’s hugely complex but is something we really want to push in our game. We’ve also been looking into facial animation technology, profiling various setups to see how far we can push the technology while maintaining a decent frame-rate. This includes trying different polygon counts, number of joints/bones in the face and the number of poses/blend-shapes that each character can use. As part of this we’ve also been investigating what we could do to push the rendering of our faces, which is no easy task when you also have to support many characters on screen. We’ll hopefully be starting this face rendering R’n’D next month and look forward to sharing the result (good or bad!).”
Design
June has been a busy month for design here with GamesCom looming. We are still flat out on Squadron 42, supporting the performance capture shoot with last minute level tweaks at the studio site to make it look at as fantastic as possible. All of the levels are looking more and more polished with a steady stream of great looking building tiles coming from our environment team that are iterated on until they look fantastic, while still allowing the level designers to layout the environments in a believable way.
We had an internal “Show-and-Tell” this month as a lot of the new staff had not seen the full depth of the plan for Star Citizen and it’s safe to say that it went fantastically well, with lots of jaw dropping amazement at depth of the game. It was great to see just how much work has actually been done in such a short period.
The technical design team has grown and is now covering tasks from FPS weapon balancing all the way to getting the Vanduul fleet operational in the engine, capital ships to fighters.
The Arena Commander team have now got the “large-world” code from the engineering team and are starting to realize what can be achieved in terms of universe size, suffice to say you should be seeing the fruits of their labours soon.
The systems designers have been finalising the specification for the “multi-functional displays” in the cockpits so that the functionality can be extended across all ships and is totally scalable from single-man ships up to larger capital ships. This is another one of our urgent tasks needed for GamesCom and will hopefully be shown in more detail very soon.
We are also trying to get a first implementation of “Quantum Jumping” ready to allow a more speedy way of navigating around the new “large-world” technology, which is looking very promising.
All in all a big month for us, but I’ve got a feeling we will be getting a lot busier in the next few months. Might be time to string up a hammock in the office soon. Thanks to everyone as always.
Art
Concept Art
Biggies this month have been the Bengal Bridge update and the Mining Bot, additional work continues on the Behring Ballistic shotgun, Xi’an transport ship, Vanduul fleet and further prop concept definition to add to the Shubin mining base and a few pirate bases needed for the Sq42 storyline (no spoilers!)
Ships
The Retaliator has been worked on this month to continue getting it ready for Flight – exciting times! Argo RUV is reaching Final art (excluding the pod which needs revisions for the cinematics), the Idris is looking very good in places, can’t wait to reveal some of it. Cutlass started its new greybox taking in to account design revisions, mining bot going to texture and material stage, Starfarer – going slower than we’d like, it’s a matter of resources, and we need more talented folk to help build this ship as its more complex than expected. Bengal Bridge will start once concepts are signed off.
Environment Art
A short update this month as much of what we’ve been doing must be kept secret for now. Progress is continuing with our VS environment which has hangars, control rooms, corridors, airlocks, and exterior landing pads – all of which can be traversed seamlessly. Hopefully we’ll be able to show you some of the really cool things we’ve been working on in the not too distant future, so stay tuned!
Props
We are getting clear documentation ready for outsource, dialling in with the techniques needed for materials which causes us most problems and then next month, we should be rolling.
VFX
The VFX team have been hard at work getting more ships “flight-ready” – this includes effects for thrusters, weapons and damage. In particular, the Scythe’s effects are looking pretty badass! We’ve also been continuing to iterate on environment effects – interior as well as exterior – for the Vertical Slice. We also began to focus on Star Marine’s weapon VFX, to make sure they’re matching the overall quality of the levels, characters and of course weapons. Truly exciting times to be a VFX artist at Foundry 42!
Audio
Hey everyone! This CIG Audio community report might meander a little, there’s a lot going on but think this should cover most of the interesting parts.
Firstly, Wwise. We’re nearly there as far as our mass of asset conversion/re-engineering is concerned; at least, the end is in sight. So Stefan, Darren and I have spent some time thinking more about how to set things up so we can mix the game well. Our game is on-going, constantly being revised of course, so the strategy we need to take is not typical to that we’d pursue for a one-shot release title. We think we have the basis of what should serve us well, and we’re changing the project structure to reflect this.
On the audio engineering side, much of it is still making sure things that used to work, work again; and ironing out any more emergent bugs/foibles that are still present. A certain ironic twist to what we’re doing is that the more we get individual sounds working, across all sorts of systems, the more we’re contributing to the problem of too many sounds playing, or being processed at some level, at once. Wwise has some ways of handling this situation, but the ideal is to make sure Wwise doesn’t get bogged down processing elements that are outside the player’s sphere of interest. At the core of it, if something is too far away to be heard, then we put it into a suspended-animation state where audio is concerned, but only to the extent that we need to so that when it comes back to life, it works as expected. There are all sorts of things to consider with this but that’s where we are right now in terms of core audio engineering. It’s not glamorous I know but it will keep things running smoothly if we get this right sooner rather than later.
We have a couple of new ships coming, one of which Darren’s been working on a lot. This had to have new dialogue recorded for its ship computer too and he’s been looking at the UI aspect, designing sounds and seeing how best to get them in. So much game UI these days is based somehow in Flash and that can be problematic for implementing sound in a way that we can iterate upon easily. So while we’re doing that we’re thinking of ways to improve this pipeline.
Incidentally, regarding the Origin ship computer, I’m holding my hands up on this one and admitting I failed to capture the previous essence of what made the ship computer so great for the Origin models. Basically, we’ve listened to you and absorbed the feedback you provided regarding the new one – and I’m absolutely determined that we’re going to win this one back. I’m not happy with it and this will be fixed!
Persistent Universe. We can’t say too much about this as yet but been ongoing support for the environmental audio for this.
FPS. So much of this is tied up in Wwise, there’s been plenty of new content required for FPS in terms of weapons, character Foley and dialogue and that’s coming along nicely. We’re getting a bunch of new music content down for FPS too. Thus we tested out a workflow where our composer, Pedro Macedo Camacho, works from his studio within Wwise, and we import what he sets up of his music into Wwise at our end. It’s not practical in terms of logistics to provide access to our own Wwise project (which is growing all the time), so testing out this workflow where he passes us a project file, has proved really valuable.
It was actually surprisingly easy to import his work-units into our Wwise project, and made me think that this might be an avenue for those of our modding community who wish to import their mods/material into Star Citizen. New assets could feasibly be produced by modders within Wwise, then passed to us for integration in the Wwise project, thus we export to sound banks etc. and pass the event triggers back to you for use. It might be a little unwieldy on the face of it, but I think ultimately working together with the modding community is the way to go to ensure a quality experience, and I’d love to try this out.
Arena Commander (or dog fighting module); a whole host of material has been converted, or some cases entirely re-created to work better than before. As Audio Director I don’t often get to do much sound design at the moment, which is obviously something of a shame as it’s what I am, at my core. So it’s been so good to be able to fit in some time for working on some ship thruster stuff and contribute in a material way to some thruster design! Luke’s taken what I’ve done and fixed it up a bit too, he’s very into the spaceship audio aspect of our game so that’s been reassuring for him to fix up my implementation. Generally a lot of this material is taking up time for all our sound designers, as it’s the lion’s share of Star Citizen right now there’s simply a lot to do but we’re whittling through it nicely.
Re: dialogue support for the Squadron 42. Our Dialogue Superman (not an official title) Bob Rissolo has still been hard at it down in London. It’s wrapping up soon, at least for now, which means he’ll be moving in-house permanently here to Foundry 42. A big move for him, we’re still hugely grateful he’s swapping sunny San Diego for the more, well, variable climate of Manchester!
Regarding our sound studios. By the time you read this we’ll have actually had our new doors installed for these. I know, doors seem like such an obvious thing to have, and of course, they are when you’re trying not to assail the rest of the studio with FPS gun sound effects, explosions and the like. But we’ve been waiting a while for a particular set of doors to be manufactured, simply we’ve been on the wrong end of some manufacturer-side production issues with them they’re each a different colour. I know that seems frivolous but when you have a number of isolated rooms and coming from another discipline, it saves time to be able to direct someone to the ‘orange sound studio’ rather than specify a room by who may or may not be there. Also means we can swap rooms to some extent. My own room is going to be a reference room for the rest of CIG Audio to test our surround mix, for instance.
Right now, tools improvements is something we’re considering. The better our tools, the easier it is for us to keep improving things. Wwise is an event-based system, and is reliant on external events of some form to trigger sounds in certain ways. For instance we want to trigger certain one shot-sounds when a thruster is transitioning from zero thrust to full thrust, on top of what we trigger for thrusters generally. And then trigger different one-shot events when the very same thruster transitions from full thrust back down to zero thrust. This is actually something that’s tricky to do ‘in the box’, the box being Wwise in this instance, so we want to be able to set-up these events more easily as sound designers rather than as programmers, so there’s a whole tool-set that we’re considering for defining logic to cater for this. This is just one tool out of many we can see a real need for.
We’re arranging to go back down to Pinewood, to record a whole bunch of duress elements for the ships. You might recall that they’ve worked with us on character Foley for FPS. There’s a new library of this sort of rattling, bone-shaking material that we’re also looking at (you can never have enough source) but we also want to make sure our stuff is that bit more individually tailored to our requirements. We’ll be taking down the Butt-kickers for this, for sure.
I’m sure there’s more stuff I’ve missed from this update, do feel free to ask us more on the Ask A Dev part of the community forums and we’ll continue to do our best to respond. Thanks for listening!
QA
UK QA have had to split our efforts this month to deal with the upcoming major events and releases. Star Marine (the FPS module) plus preparing for Gamescom, are on the cards for the near future, and Squadron 42 testing continues as normal.
Star Marine has had a lot of focus in order to root out major multiplayer bugs and try to find any general polish issues. Glenn Kneale from the UK and Tyler Witkin from ATX QA have been collaborating to make sure this game mode gets thoroughly tested. There’s been a lot of cross studio stress testing to help ensure that it should be stable once it gets released.
We’re focusing quite heavily on testing the sections of the game that will be shown at GamesCom. Unfortunately not too much can be mentioned there, but we’re all very excited about how what’s currently planned to be shown will be received.
Finally Squadron 42 is getting more testing time dedicated to it, as the game progresses we need to ensure the new mechanics are and alpha level run throughs can be completed. We also spent some time creating some more documentation to address our current plans to expand testing on S42.
Steven Brennon has continued to compile feedback from you guys and making sure it gets appropriately compiled and sent to the relevant people.
Sadly we’ll also be losing Chris “Chill” Hill at the end of the month. We wish him all the best as he’s been simply fantastic since he joined us last year, but looking forward we’re training up Steve Brennon to be a replacement lead.
June has been a busy month across all disciplines, and the team is building up in momentum. A large amount of strong applications have come in this month and we’re slowly getting through them 1 by 1. We continued to plan out our new office space, all things are set to get the keys to our new permanent office July 1st. We’ll make sure to share the new location with everyone in case anyone wants to stop by and say hi, with advanced notice of course.
Engineering
In June, Frankfurt Engineering deployed to the main codebase some major items that were planned for this month. As mentioned in the last monthly report, the Large World (moving the codebase to 64 bit coordinates), Camera Relative (rendering coordinates relative to the camera thus allowing galaxy size rendering without loss of precision), Zone system (the new Star Citizen spatial partitioning scheme, replacing Cryengine Octree) were close to hit the Star Citizen code mainline and have now been deployed, and will find their way into the various Star Citizen game modules soon.
The integration of relevant CryEngine 3.7 SDK parts, combined with our new changes, is being deployed into our codebase as we are writing this. Additionally a large effort this month was spent on supporting multi-crew vehicle ships: local physics grid, physics debugger, entities and prefabs, support for new 3D VisArea shapes, all this combined with the Zone System, are being worked on in the context of operating moveable ships. Amongst the other things, the multi-crew development process exposed a few bugs and incorrect functionalities that have been living in the CryEngine codebase for years …
We continued to work on optimizations, improved storage formats, bug fixing, clean up and general engine support to other CIG studios.
AI
During June, the AI development team has been focused mostly on the basic systems required for the human character to navigate through the full game world.
We completed the first pass on integrating the CryEngine MNM Navigation System and the multithreaded MNM Pathfinder. We also have completed the first pass on interfacing CryEngine Movement System with the current behaviour tree system. The Movement System takes care of analysing a path returned by the MNM Pathfollower and creates a plan on how to execute the movement.
Let’s imagine a character that needs to move into a cover position, the NPC will have to follow a path until the cover spot and then enter the right stance to actually position himself behind cover. The movement system allows us to have the proper context from the request to the execution of the movement, so that we can predict the necessary step the NPC has to take to correctly end up in a “behind cover” position.
We are in the middle of integrating the CryEngine Tactical Point System with our new behaviours. The Tactical Point System (or TPS) is a query system that allows us to query special position with specific properties.
In addition to the development of the systems we are taking care of creating all the glue code between the systems to allow the NPCs to have the best looking quality.
And we are also continuing coordinating the improvements on the Kythera Behavior Tree and its integration with Dataforge.
Design
This month the DE Design team has spent much of their time working on four initiatives: building a level for Squadron 42, assisting with the FPS module release, building AI behaviour trees for FPS, Squadron 42 and the Persistent Universe and then working with the UK team on Squadron 42 level feedback. We’re reviewing the missions and encounters they build for pacing, use of mechanics throughout the level, level flow and moment to moment gameplay ideas.
Animation
Currently the DE office only has 1 animator, fully focused on supporting cinematics. This month they worked on starting to set up scenes for scripted events and in-game cut scenes, getting pipeline tools identified and documented and a review of the Squadron 42 script (with the Cinematic director) to sort out which scenes will be owned by cinematics.
Cinematics
Hannes is back from the long cinematic shoot. He’ll be able to contribute to the monthly report starting next month. They had some truly talented actors on stage that gave amazing performances. We all internally look forward to pulling these together, as I’m sure the backers do as well.
Audio
Not much new for audio this month, still working on Wwise conversion that started last month. Hooked up the EVA thrusters and Ship Shield impacts to use the Wwise audio system, fixed several audio-related bugs. Started work on improving the distance-based culling of active sound emitters to let the sound designers create more detailed soundscapes without overloading the sound engine.
Build System
In June our Senior Build engineer visited our Austin studio (ATX) for 3 weeks and worked close to the Dev-Ops /IT teams on many aspects of our builds process, optimization and cross studio delivery. Among many things, the main goal was to reduce the amount of time it takes to put together a build, make patches, deploy servers and so forth.
We’ve decided to move away from the current build system in favor of something that we are confident will give us much more customization capabilities to better tailor it around our game’s needs. This is still work in progress, a lot of work has been done, and even more will be done in the next upcoming weeks.
VFX
For the past month we have been working hard on various squadron 42 effects. One of these effects has been a giant plasma drill. It is used to break up asteroids into smaller pieces for resource extraction.
Greetings Citizens!
Another whole month has gone by and we have been busy!
Engineering
As usual, a portion of the team has been focused on development for short term deliveries such as support for FPS Lobby & Flow. We’re also slowly moving away from that, now that it supports most of what we need for the first version, and have been starting to add support of multi-crew ships in the Lobby UI.
The month of June has brought us a few great features from other studios which has allowed us to work in tandem in order to add a bit more functionality to online hangars. We’ve been working hard on the current Holotable implementation in order to reduce the need for ships to be spawned in the game for them to be used in Arena Commander. This will allow us to reduce loading times as well as to facilitate management of server hosted Hangars. We have also been reworking part of the flairs implementation and Hangar spawning to work properly in such a context.
The planetside experience hasn’t been left to itself either as we’re still working on adding some features and a level of polish to the Augmented Reality (AR) experience with mobiGlas as well as the shopping experience as a whole.
Design
The design team has been setting up elevators and doors for Nyx, as well as setting up various functions (such as dynamic spawning, mobiGlas AR tags, and text string localization) for the items that will appear in Casaba outlet. We have also been doing follow-ups on the shopping experience, flair objects, and Level Design blueprints for Hurston, Crusader, and Microtech.
Art
This month we did a lot of work polishing for the Nyx asteroid map, improving materials/textures and dressing the environment to ensure that each room has a story to tell. We’ve also worked on improving one of our previous maps, modifying its layout to optimize navigation and improve performance.
Additional efforts were done on our shop system. We’ve added details on how clothing will be placed on the shelves to allow for good visibility from the player’s perspective.
Finally, as always, we’ve completed next month’s Flair object. Enjoy!
UI
The UI team has been doing quite a bit of spring cleaning (never too late!). We have been working on a thorough pass of the new holotable design flow to smooth out the whole user experience and to unify the various screens. Same goes for the simpod interface (also known as Electronic Access). We have also been cleaning up a lot of low priority tasks that have slowly and steadily been piling up.
Till next time, Citizens!
Hello Citizens!
Another month, another update. Quite a bit has happened over the last month. At the moment we have three guests from CiG (Sean Tracy, Steve Bender and Jason Hutchins) visiting us in Denver and helping out any way they can. We are currently focused on getting core locomotion as solid as we can, while still having the animations look great in both 1st and 3rd person. This isn’t easy by any means, which is why we have the extra reinforcements! You can find additional updates on the FPS module push in the weekly Star Marine update.
Engineering
Over the last month, engineering has been primarily focused on core locomotion and the start/stop/juke system. This has been close work with animators and designers, working out all the edge cases, and trying to find the absolute best balance between control response and animation quality. Everything then needs to work and be polished for both 1st and 3rd person modes. In addition to core locomotion, they have also created rules for Star Marine so that it reports stats in the same way that Arena Commander does for leaderboards and the accruement of REC. Lastly 5 different movement speeds were implemented. This makes moving with a controller very fluid and variable, depending on how much tilt is being applied to the stick.
Animation
The animators have all been laser focused on getting everything looking as good as possible with starts/stops/jukes. This has mostly involved a very quick feedback loop with Steve Bender. Getting his feedback, making tweaks and sending back the results until everybody is happy. It is a lot of work to be sure, but the team here is doing some really good work and the velocity of that work increases almost daily, now that the processes have been figured out.
Art
The art team has been working on optimizing all of the asset pieces for the Gold Horizon Station set, along with tweaking assets to match up with the metrics that are being used over at Foundry 42. This isn’t exactly the most interesting work, but it is something that needs to be done in the long run for persistent universe and Squadron 42.
Design
The design team is making numerous tweaks to the Gold Horizon level at the request of CiG. This includes some tweaks to ammo & energy placement locations, removing some doors and changing the behavior of others through the level. In addition, they are also tweaking the lines of sight throughout the level, and doing a polish pass on cover placement.
That’s all I have for you Guys and Gals this month. Until next time!
Here’s what we’ve been up to in this last month up here in Montreal:
Jump Point interview
First of all, this month our team had the opportunity to participate in an interview for an issue of Jump Point. This gave us the avenue to discuss some of the projects that we have been working for Star Citizen and shed some light on what is coming next. Thanks to David Ladyman for allowing us to go into a bit more details (and in a slightly more informal way) about our process for redesigning the site’s global look.
Starmap
This month, we completed the main art for the Starmap viewer, including Galaxy and System views. In terms of the interface, we made some significant changes to the HUD as well as filtering options (sensors and heat grid).
On the data side, we made good progress on data modeling for the upcoming Galactapedia. We also worked on our own administration tools so that we can import data from the Star Citizen universe. This will allow for having all the data of the different celestial objects already in a Galactapedia format.
On the 3D front, we started production of the different assets that will be displayed in the WebGL viewer (planet, jump point, space station, etc). This is very work intensive and it’s what the user will see on their screen, and so we’ll be working on this for the next couple of months.
Issue Council
As reported last time, we have continually been evolving the Issue Council to ensure that it greatly reduces the amount of time/effort for everyone involved. We have also been working to make sure that it cannot be easily swayed by large groups of users (such as organizations). We have been adding new features, re-organizing layouts, moving things from one page to another, removing pages, and so on — so much so that when we took a step back and looked at it all we realized that the UI was no longer intuitive. So we gathered the team around a big whiteboard and worked on fixing this.
The core update we worked out was an updated flow for the users. Upon arrival at the Issue Council, users will be provided with three ways of approaching the system:
Contribute by attempting to replicate issues and flagging invalid tickets (duplicates, feature-requests, poorly written, etc).
Prioritize the confirmed tickets to help the developers know what is important to the community.
Search all tickets that have ever been created.
We will soon have some designs to share, but to give a bit of insight here’s a photo of one of Benoit’s whiteboard designs.
Community Hub
The Community hub has entered its final stretch, and our developers have been working on actually implementing it for the whole month. The main notable undertaking on this specific project was to set up the submission flows. These will allow you to upload pictures and galleries of your own creations, embed your youtube play sessions, or report interesting links you’ve found elsewhere, which requires a great deal of technical flexibility from the website itself. Even more interesting was that we took some time devising filters and sorting algorithms based on the amount and frequency of content posted and their popularity through upvotes and comments. It’s always an exciting challenge to devise the way a website will display its own content, to keep it as relevant and fresh as possible.
Moderation tools
Another project that we have been working on, which has recently launched, was the new Moderation Tools, for the site’s dedicated team of moderators. These tools now give them more insight into flagged contents, repeat offenders and infamous recidivists, as well as a quicker way to manage forum access. This allows them to keep the forums, comments and Orgs running even more smoothly and efficiently. With their help, we’ve devised a set of tools that will then be expandable to cover all user-generated contents, including all aspects of the upcoming Community Hub as well.
This month’s concept sale was a short story showcasing the Genesis Starliner as operated by Meridian Transit. This quick tear-jerker (go read the postcards) was written by Star Citizen’s own writers, and along with some pretty cool art and voiceovers from the Community team, it gave us a lot of room to have fun with the post. This is why it quickly became one of the site’s most script-heavy pages, with mini components like the Flight board or the flipping postcards. The flight board itself was based on a very early concept for the Events block on the website’s homepage, which we were really fond of but put too much stress on browsers. So we were really happy to be able to use it anyway as part of the short story.
What you didn’t see
Just like for any other month, our programmers were also tasked with improvements and fixes that have gone unnoticed, thankfully. Prominent this June were the payment processors that we use : Amazon migrated their whole payment system, which we had to adapt to, along with transitioning to an entirely new way of handling subscriptions. Another one that shall remain unnamed cough*paypal*cough also had some interesting surprises for us that we had to react to very quickly. We’ve also dedicated some time to providing new tools to the Customer Service team, to help them deal with problematic cases even more efficiently.
It’s been another busy month at Moon Collider, so let’s jump straight into it:
Engineering
It’s a well known saying that no plan survives contact with the enemy, and I think an equally valid saying would be no tool survives contact with the designers! No matter how well you design any new tool, the moment designers start playing with it you’ll find out very fast what needs improvement. Last month we gave designers the ability to write behavior trees using an editor built into DataForge, Star Citizen’s custom data management tool. We tried to get it into designer hands as quickly as we could, so we already had a decent sized todo list of improvements we knew were needed, but a few hours of real use of a tool by a designer always helps to clarify which issues are minor annoyances, and which ones frequently interrupt their workflow or straight up make them unable to do some task.
We spent some time this month getting feedback from designers and working through their prioritized list of issues with the new editor. This included things as simple as writing up more documentation on how certain features worked; renaming, recategorizing and recoloring BT nodes in ways that are more intuitive to a designer; and even moving certain advanced pieces of functionality out of the standard workflow so that it’s a little more laborious to use those rarely needed features but it makes the common features more streamlined. We expect to continue improving this tool next month as the feedback from designers keeps on coming through.
With the designers now working on behavior trees with DataForge, it was also perfect timing for adding a behavior tree live view to our Kythera Inspector web based debugging tool. This is a web page that designers can bring up that gives direct access to the state of the AI in their game, and we’ve been constantly added features to it in order to make debugging AI easier. Up to now we’ve been relying on some simple on screen text debugging to help us understand the current state of an AI’s behavior tree, and while this worked reasonably well for a small and simple tree, it was much less useful for larger trees, and also limited in the information provided.
The new live view in Inspector allows designers to see the state of the behavior tree of any AI while the game is running. We have some new features coming next month that will allow this view to help them track down configuration errors with their trees, which, when combined with the already existing ability to record and play back the behavior trees of the AI, should give designers a comprehensive suite of tools for debugging their behavior trees.
One issue we’ve been trying to sort out for a while is a technical feature we call a string hash. This is something that is built into Kythera and basically allows us to convert any text string in the code into a numerical identifier at compile time. This makes it cheap and efficient to pass strings around in the code and use them without worrying about it being expensive to do comparisons, which is usually the case with strings. And this means that you can have a lot more descriptive text being passed around in your code rather than simple numbers, which can make code that’s easier to work with and easier to debug.
Because this is such a useful feature, a similar version has been added to the rest of the Star Citizen codebase. What we’ve been trying to work out is how best to unify these two different versions of string hashes, so we can avoid the cost of converting between them. There are various details that make this trickier to solve in a satisfying way than it might initially seem, so we’ve been spending time working this out with coders in some of the other studios and are currently testing some possible solutions to try them out and see if they cause problems in practice.
Now, let’s talk ships!
Last month we added in the feature that allows ships to reliably join splines. This month we started making good use of that feature in the form of retreat stunt splines. Stunt splines are paths that are laid down by designers in a level and allow AI to fly through tight areas where their collision avoidance would otherwise stop them from going, such as through a tunnel in an asteroid or gaps between sections of a space station.
One of the main goals of these stunt splines is to set up opportunities for players to chase AI through interesting and exciting paths. We’ve added them to AI retreat behaviors so that when an AI ship wants to break away from a pursuer, if there is a stunt spline nearby it will try to make use of it. To keep things believable, the AI will only pick a spline if it can get onto it quickly, so they won’t use one if it requires a major change in speed or direction to get to it.
We can also use them to distinguish elite AI pilots from rookies by having a skill level attached to the spline. So a really hairy maneuver can be marked as only available to the best pilots. This also means that if you go to chase a fleeing elite ship, you may find yourself in a chase that you’re not good enough to pull off, and you’ll need to make a quick decision on just how crazy a pilot you’re willing to be!
Once designers have had a chance to work with this feature, we plan to make some refinements to the spline selection process to get a good balance so they’re not overused or underused. It’s important that the AI don’t become too predictable to a player who is familiar with a map, but on the other hand, seeing a ship break off and head towards that tunnel you know is great fun to fly through can be something to anticipate as well.
As is always the case with new features, we’re looking forward to seeing this one get into the hands of real players and hearing the cool stories that come from it!
Greetings Citizens,
We always say that it has been a busy month for the community team, but at this point… what month isn’t busy?
We were very happy this month to celebrate the first anniversary of Around the Verse! AtV has been an interesting project for us; last year, we went into the s how dreading the need to replace fan favorite Wingman’s Hangar… and we took time to find our feet and figure out what was important. Thanks to your feedback (and your support!) we’re proud of what the show has become… and we’re going to try and keep making it better. Episode 50, aired last week, had one especially standout segment in which designer Randy Vasquez showed his process for building Starliner interiors. Expect to see more segments like this in the future, as we felt it was our strongest piece yet.
We’ve also asked the community team to be more interactive on the forums. We’re just as eager to see Star Marine release as the rest of the community, and we’re going to do our best to get out there and not just show the flag but share our answers and thoughts with all of you. A Community Manager can’t always answer your questions… but we’re here to address what we can and also listen to your concerns and make sure developers are aware of them. Even better, we’re working on a relaunch of the ‘Ask a Dev’ process, which will hopefully result in a system for getting your questions answered by the experts.
The whole team also had a field day with the Genesis Starliner sale. We wanted to get across just how much depth there was to the ship, and the whole team worked together to add pieces to the presentation that we thought would interest the community. From Jared’s postcards to Ryan’s safety card, we wanted to show you more than just how big the guns were (and if we’re being honest, the guns are not that big in the first place.)
Finally, we’re very sad to lose one of our own: Chelsea Day, manager of the Customer Service team, has left CIG to relocate. Chelsea was a good friend and a great CS manager; we’re all going to miss her! Patrick Probst, who you may have seen on the forums, will be taking over the CS manager position in the UK. So congratulations – we know you’ll live up to the example Chelsea set!
Grüße Bürger,
Der Sommer ist da (jedenfalls auf der Nordhalbkugel), aber wir sind nicht im Urlaub: Große Dinge passieren bei der CIG! Wenn man von innen betrachtet, ist es erfreulich zu sehen, dass die beweglichen Teile, die den Star Citizen ausmachen, zusammenkommen. Wichtige Teile der langjährig erprobten Technologie, wie große Weltkarten, kommen intern online und es herrscht ein Hauch von Spannung unter den Entwicklungsteams, da die Realität, dass vieles, was wir geplant haben und worauf wir hinarbeiten, endlich eintritt. Wir freuen uns darauf, unsere Fortschritte mit Ihnen zu teilen, was bedeutet, dass wir uns bemühen, nicht nur das Star Marine FPS-Modul herauszubringen, sondern auch mehr über Multicrew und die persistente Welt zu erfahren. Passt auf diesen Raum auf! Wie immer haben wir unsere Projektleiter gebeten, individuelle Berichte für die Community zusammenzustellen, damit Sie genau wissen, was jeder Teil des Unternehmens getan hat. Lies weiter!
Hey zusammen! Es war ein erstaunlicher Monat voller aufregender Arbeit hier im sonnigen Santa Monica. Wir lieben es, mit dir alles zu teilen, woran wir gearbeitet haben, also genieße es und lass es uns immer wissen, wenn du irgendwelche Fragen oder Gedanken hast!
Ingenieurwesen
Unser Ingenieurteam war diesen Monat sehr beschäftigt. Alles von der Datenspeicherbereinigung über die Erstellung des neuen Charakter-Materialsystems bis hin zu großen Weltneuheiten. Also lass uns reinhauen:
Wir haben einige frühe Implementierungen der Fahrzeugparameter vorgenommen, bei denen wir die Fahrzeuge vom Parsen einer Xml bei jedem Spawn bis zum Parsen einer einzelnen Xml und von da an damit zum Bau eines Fahrzeugs entladen haben. Auch der einzige Weg, wie wir ein Schiff bauen konnten, war, es zu spawnen und dann zu sehen, was es enthält. Jetzt können andere Systeme einfach die Parameter nachschlagen, um ein Schiff aufzubauen. Wir müssen nicht mehr jedes Schiff unter dem Hangar spawnen, was eine massive Veränderung war. Wir hatten auch viele Integrationsfehlerbehebungen für FPS & Arena Commander. Wir setzten die Arbeit am Radar 2.0-System fort, bei dem wir das System von der reinen Basisversion zu praktisch allem überführten, was die Designer auf dem HUD zeigen müssen. Die Backend-Arbeit ist gebaut, jetzt müssen wir HUD und andere Fahrzeugkomponenten ändern, um diese Objekte zu handhaben, damit die Designer verrückt werden können! Wir haben auch eine Menge Fahrzeugcode bereinigt, indem wir unbenutzten Code gelöscht haben, der viele der langsamen Bits beschleunigt hat, aber das wird ein laufender Prozess sein.
Die Benutzeroberfläche hat enorm hart an den anstehenden Schiffsdesigns und der Implementierung gearbeitet. Insbesondere die Glitch-Effekte und das Booten für die Vanduul. Wir überprüften einen Vorschlag für eine verbesserte Cockpit-Interaktion und begannen mit der Vorbereitung von HUD zur Unterstützung verschiedener Sitzaktionen und Rollen.
Wir haben einige Bereinigungen des Datenspeichers durchgeführt, doppelten Code entfernt, verschiedenen verteilten Code in einem Durchgang vereinheitlicht und mit der Vorbereitung für Multicrew Spawning/MP Hangars begonnen. Wir haben das Objekt-Spawnen vom Spieler-Spawnen getrennt, um die Hangar-Beladung in die Level-Ladephase zu verschieben.
Wir haben auch an einem mehrschichtigen Materialsystem gearbeitet. Das Ziel ist es, eine feste Bibliothek von Basismaterialien zu erhalten, die miteinander vermischt werden (bis zu 4 Schichten), um komplexere Materialien mit minimalen Draw Calls zu erstellen. Texturbibliothek und Core Shader-Funktionalität sind meist fertig und arbeiten nun an der Basismaterialbibliothek, die die Renderressourcen mit den Mischmaterialien überbrücken würde.
Auf der KI-Seite haben wir viele Schiffsfehler behoben, insbesondere in Bezug auf den Lotsen, den ein KI-Schiff erstellt und betreut. Wir haben auch ein wenig am Wingmen-Kommando "defend target" gearbeitet und einen KI-Schiffsaspekt geschaffen, der die Bedrohungen in der Nähe verfolgt, so dass eskortierende Schiffe wissen, was sie angreifen sollen.
Auf der Large World-Seite haben wir verschiedene Triggerbereichsprobleme in LW-Karten behoben, wie z.B. die Entfernung der +/- 16km-Grenze für alle Triggerbereiche und die Festlegung zusätzlicher Randbedingungen. Wir haben ein wenig Interface-Bereinigung für Matrix34 / Quat durchgeführt und die Voraussetzung geschaffen, dass der Rotationsanteil all dieser Primitive floaten kann. Wir haben auch die Positionsinformationsleiste und den GOTO-Positionsdialog korrigiert und die Bewegungsgeschwindigkeit der Kamera in der Sandbox beim Erstellen von LW-Karten erhöht. Schließlich haben wir das Laden von Thread-safe Texturen mit Thread-safe Shader Parsing und Thread-safe Shader Ressourcenerstellung fast abgeschlossen. Puh, wir hatten einen tollen Monat und freuen uns auf mehr!
Design
Das Designteam hier ist unglaublich beschäftigt mit all den kommenden Schiffen, Modi, Spielanforderungen und so weiter. Einer der größeren Schwerpunkte für uns war der Genesis Starliner. Wir wollten sichergehen, dass wir alles durchdacht haben, um bereit zu sein, dieses fantastische Schiff zu dir zu bringen. Wir hatten in diesem Monat viel Arbeit vor uns, wie z.B. die Erstellung des ersten Gameplay-Balance-Plans, der mögliche Updates von Statistiken, Features, Spielmodi, Hud, Kontrollen, Raketen usw. beinhaltet. Hier sind einige der detaillierten Details dieses Monats:
Wir haben ein Problem mit der RSI Constellation Andromeda behoben, bei dem die alte Hangar Ready Version den Hangar zum Absturz bringen würde. Hoppla! Wir haben auch den Haupteingang des Aufzugs von einer Tür auf einen Schalter umgestellt, um das Ein- und Aussteigen über verschiedene Türen zu ermöglichen, ohne die Animationszustände zurückzusetzen. Wir haben auch die obere und untere Revolverhandposition festgelegt. Außerdem haben wir die Triebwerke überholt, um den Flug der Constellation vorzubereiten.
Für den Scythe Dogfighter tauchen wir in ein Problem ein, bei dem das Multilight nicht in den Lichthafen geladen wurde und der Archetyp den Client zum Absturz brachte. Wir haben auch unnötige KI-Raumschiffe entfernt und die Scythe aktualisiert, um den Modifikationsblock "Scythe_Swarm" zu verwenden, um die Gesundheit der KI-Scythe anzupassen.
Bei der Hornet F7CM haben wir ein Problem behoben, bei dem einer der harten Punkte des Triebwerks falsch benannt wurde, wodurch verhindert wurde, dass das Triebwerk auf das Schiff geladen wird. Wir haben auch die gebundene Geometrie und das Gewichtstransferwerkzeug kombiniert, während die Refactoring-Kontrollen einiges an Design haben.
Im Mustang-Delta haben wir die Einbeziehung von Standard-Animationen entfernt, die kollidierend waren und Probleme verursachten (wie z.B. falsch platzierte Schraffuren und nicht abspielbare Open/Close-Animationen). Wir haben auch den AEGS Retaliator für den Ein- und Ausstieg aus dem Pilotensitz implementiert und die Innenräume aktualisiert, um die neuesten aus der Produktion zu verwenden. Das ist einiges davon, wie unser Monat verlaufen ist und ist bereit für den Monat Juli.
Kunst
Insgesamt war es ein sehr arbeitsreicher Monat für unser Kunstteam in Santa Monica. Insbesondere waren die Fahrzeugkünstler damit beschäftigt, sich auf den Merlin zu konzentrieren, der gerade seinen letzten Kunstpass durchlaufen hat und dem Design übergeben wurde, um den Flug vorzubereiten. Darüber hinaus hat unser Senior Vehicle Artist Paul Forgy die ersten Schritte unternommen, um den Bengal Carrier außen weiß in einer Box und in der Game Engine zu präsentieren. Ich kann es kaum erwarten, diese großen Schiffe zu sehen! Mit der neuen Schadenstechnologie, die online kommt, haben die Künstler von LA hart daran gearbeitet, sicherzustellen, dass die flugbereiten Schiffe das überarbeitete System unterstützen. Die Scythe ist eine der ersten und wurde für die volle Schadensunterstützung eingerichtet. Achten Sie darauf, dass Sie in naher Zukunft darauf achten. Das ist nicht das einzige Update für die Scythe. Das Cockpit des Schiffes wurde für den Menschenflug nachgerüstet. Erwarten Sie das bald in AC!
Neben unseren ATX-Kameraden hat das LA-Studio daran gearbeitet, Charaktere nicht nur für den FPS, sondern auch für Charaktere über alle Module hinweg neu zu gestalten. Omar Aweidah nähert sich der Fertigstellung des ersten Goldstandards, um die neue Charakter-Shader-Technologie von Multi-LayerBlend, geschrieben von Okka Kyaw, vollständig zu nutzen. Jetzt sind wir bereit, die visuelle Treue des Charakters zu erhöhen und den großen Sprung in die Zukunft der Charakterentwicklung für das Star Citizen-Universum zu wagen.
Apropos Charaktere, unser Produktionsdesigner für Charakterkonzepte, Rob McKinnon bringt unsere Konzeptentwicklung wirklich stark in Schwung. Wir machen große Fortschritte bei der Entwicklung von Looks für die Charaktere von Star Citizen. 3D-Skulpturen von Rob McKinnon und seinem Team haben uns unseren ersten 3D-Blick auf Marineuniformen gegeben. Ob Brückenbüro oder BDU, die Marines sehen erstklassig aus. Die Marine hat Tonnen von Rollen und Verantwortlichkeiten und wir haben jetzt ein Outfit für jeden von ihnen. Von Offizieren an Deck bis hin zu Ärzten auf Abruf sind die Uniformen der Marine scharf und bereit, mit der 3D-Produktion zu beginnen.
Bei all der Aufregung, den Meridian Transit zu fahren, haben wir dafür gesorgt, dass Sie nicht auf einen Drink verzichten müssen. Der Genesis Starliner hat nun die allerersten Konzeptentwürfe für Flugbegleiter. Außerdem wurde die Vanduul gerade viel härter mit neuen Bildern, die vom Konzeptteam erstellt wurden und neue Rüstungssets zeigen. Die Vanduul sehen jetzt gemeiner denn je aus. Unter der Rüstung wurde eine Revision durchgeführt, um zu versuchen, die Haut dieser Alien-Rasse zu finalisieren.
Und das war's für das Santa Monica Studio-Update für diesen Monat. Vielen Dank, dass du dir die Zeit genommen hast, dir die harte Arbeit des Teams anzusehen und die Entwicklung des Spiels zu unterstützen. Nichts davon wäre ohne deine weitere Unterstützung möglich und wir fühlen uns geehrt, dieses Spiel mit dir machen zu können. Wir schätzen Ihr Feedback und Ihre Gedanken, also halten Sie sie auf dem Laufenden.
Hallo zusammen!
Es war ein ungewöhnlich regnerischer und kühler Juni in Texas und wir haben es genossen. Wir haben diesen Monat eine Reihe von Besuchern aus anderen Studios empfangen und uns sehr auf eine Reihe von verschiedenen Produktionsprioritäten konzentriert. Wir haben an verschiedenen Fronten gute Fortschritte gemacht und haben noch viel mehr zu tun, um den harten Vorstoß bis zum Ende des Sommers zu bewältigen. Hier sind einige detaillierte Berichte von den Leitern der einzelnen Teams.
Hartnäckiges Universumsteam
Kunst
Diesen Monat verbrachte das PU Concept Art Team die meiste Zeit damit, Details zu den wichtigsten Features des Spiels zu erläutern. Ted Beargeon und Ken Fairclough fertigten Stücke, die Heldenrequisiten für die Landezone Nyx>Delamar>Levski definierten. Wir schickten Konzepte von Statuen und Großmaschinen an BHVR, um sie zur Modellierung zu bringen. Ebenso wurde einige Zeit damit verbracht, das Levski-Marktgebiet zu konkretisieren, um das Einkaufserlebnis dort zu definieren, da es anders sein wird als alles, was wir bisher gemacht haben. Megan Cheever verbrachte ihre Zeit in diesem Monat damit, Details zu vertiefen und gibt verschiedene Konzepte von Militärpersonal weiter. Sie half bei der Definition der Abzeichen, Medaillen und Materialien, die du im Endspiel sehen wirst. Megan hat auch die Charaktere der Flugbegleiterin konzipiert, die Sie diesen Monat im Starliner-Verkauf gesehen haben.
Unser PU-Umweltteam hat die letzten Detailpassagen auch für Levski ausgearbeitet. Lee Amarakoon und Emre Switzer haben VFX bzw. Lighting unterstützt. Levski fängt an, durch die Arbeit dieser Jungs richtig dunkel und düster auszusehen. Lee machte sich auch an die Überarbeitung des Customs Scanner-Effekts, den Sie letztes Jahr auf der CitizenCon gesehen haben. Unsere Environment Leads, Cort Soest und Patrick Thomas, haben mit BHVR zusammengearbeitet, um die Umwelt selbst zu optimieren und die letzten 10 Prozent fertigzustellen. Nächsten Monat sollte Levski eingepackt werden und bereit sein, irgendwo auf der Straße zu zeigen.
Die Landezone Stanton>ArcCorp>Area18 war auch in diesem Monat ein großer Schwerpunkt für uns. Die Umgebung wurde einigen Layoutänderungen unterzogen, um sie für die Veröffentlichung mit dem Sozialmodul zu optimieren. Mark Skelton hat zusammen mit Tony Zurovec daran gearbeitet, die Richtung für die Veränderungen zu bestimmen. Dieses Umfeld wird dadurch besser denn je aussehen.
Das Charakter-Team hier in Austin hat erst kürzlich den SATABall-Charakter und den Helm eingepackt, und es sieht fantastisch aus! Dies war einer der ersten Charaktere, die wir von Anfang bis Ende mit unserer neuen Next-Gen Character Pipeline aufgenommen haben, und die neuen Techniken haben sich als effektiv erwiesen, um stellare Charaktere für Star Citizen zu entwickeln. Wir freuen uns darauf, David Jennison und Billy Lords Werk sehr bald zu präsentieren!
Das Austin Animation Team hatte in diesem Monat in mehreren verschiedenen Bereichen des Projekts alle Hände voll zu tun, wie gewohnt. Wir werden diese Woche die Arbeit am neuen weiblichen Skelett abschließen, was es uns ermöglichen wird, endlich einige Damen ins Spiel zu bringen! Wir unterstützen Illfonic auch bei der Implementierung und dem Polieren von FPS-Animationen sowie beim Polieren von Animationen für das Social Module. Darüber hinaus arbeiten wir an der Standardisierung von Animationsvorlagen für Schiffscockpits und Enter/Exit-Sequenzen, um die Modellierungszeit für Schiffe in Zukunft zu verkürzen. Eine Sache, die Sie schon bald sehen sollten, sind die aktualisierten G-Force-Animationen im Cockpit. Jay Brushwood, Sean Tracy und Jeff Zhu haben fantastische Arbeit geleistet, um diese auf die nächste Stufe zu bringen.
Design
Diesen Monat verbrachte das PU Design Team einen Großteil seiner Zeit damit, Ideen zu sammeln und Designs für kommende Spielerberufe in der PU zu entwickeln. Mit Tonys Anleitung haben wir die ersten Entwürfe für die Berufe Kopfgeldjäger, Söldner und Piraterie überarbeitet. Wir haben auch Entwürfe für Schmuggler- und Such- und Rettungsberufe erstellt. Der große in diesem Monat war jedoch der von Tony Zurovec entworfene Personenverkehr. Wenn du noch keine Gelegenheit hattest, den Beitrag aus dem Starliner Verkauf zu lesen, solltest du ihn unbedingt HIER nachlesen.
Eine weitere Sache, die unsere Designer diesen Monat gemacht haben, ist das Testen des neuen Usable Editors. Der Usable Editor ist Teil von Tonys "Subsumption", einem friedlichen NPC-KI-System. Es ist der erste große Schritt zur Erreichung von Tonys Vision, wie NSCs mit Objekten in Star Citizen interagieren werden. Es war ein iterativer Prozess, bei dem die Designer mit dem Usable Editor herumspielen und Feedback geben, der Gameplay-Programmierer Tom Davies basierend auf diesem Feedback anpasst und wiederholt. Wir freuen uns, den Usable Editor zum ersten Mal in Aktion zu sehen und zu testen, wie weit wir seine Grenzen erweitern können.
Schließlich beginnen wir, in die ersten Entwürfe der nächsten Landezone am Planetenrand einzutauchen, die BHVR nach Levksi in Angriff nehmen soll. Wir konzentrieren uns auf eine weitere Landezone am Planetenrand in Stanton, die zwischen Hurston, MicroTech und Crusader hin und her geht. Welche Landezone möchtest du als nächstes online sehen?
Ingenieurwesen
Im Juni wurde der Juni mit der kontinuierlichen Weiterentwicklung vieler längerfristiger Aufgaben sowie der Planung und dem Support für unsere kommenden Releases und die Gamescom-Demo verbracht.
Es wurde viel Wert darauf gelegt, Wege zur Optimierung der Serverleistung zu finden, und wir haben in dieser Hinsicht große Fortschritte bei den kommenden Versionen von Arena Commander, FPS und Social Module gemacht. Wie im letzten Monat berichtet, ist unser Generic Instance Manager (GIM) in Arbeit und im Eingang. Das GIM wird ein großer Umbau unserer Party- und Matchmaking-Systeme sein, und es wird mehrere Iterationen durchlaufen, bis wir damit zufrieden sind. Diese erste Iteration wurde mit unserem QA-Team durchgeführt und sie waren nicht davor zurückgeschreckt, uns Fehler zu schicken. Wir haben uns schnell um sie gekümmert und sind dem, was später GIM v1.0 sein wird, immer näher gekommen. Wir freuen uns, den Punkt zu erreichen, an dem wir es mit Ihnen allen teilen können, und es ist ein mit Spannung erwartetes System hier bei CIG.
Bei Wyrmbyte sind sie nicht nur ein wichtiger Mitwirkender bei unserer Untersuchung zur Serveroptimierung, sondern auch tief in ihrem iPredictor-Code.... und arbeiten fleißig daran, die restlichen Knoten herauszuarbeiten. In der Zwischenzeit war unser Tool-Team sehr beschäftigt mit Bugs und Tool-Feature-Anfragen, um unserem Team bei der Entwicklung des Spiels zu helfen. Sie bekommen nie einen freien Moment, da es keinen Mangel an Werkzeuganforderungen gibt.... und sie liefern gerne! Wir haben auch einige Gameplay-Programmierer, die weiterhin an einigen Proof-of-Concept-Funktionsprototypen für einige unserer Berufe arbeiten. Es ist berauschend, die frühen Formulierungen dessen zu sehen, was am Ende als unsere Berufe im Persistent Universe enden wird.
Also ist es leider etwas kürzer als ein Bericht in diesem Monat. Es liegt jedoch nicht daran, dass jemand bei der Arbeit schläft, das Team ist meist auf langfristige Aufgaben ausgerichtet und hat große Fortschritte gemacht! Viele von ihnen hoffen, dass sie in den kommenden Monaten zu dir kommen werden.
Bleiben Sie dran!
Live-Betrieb
QA
In diesem Monat hat Star Citizen QA erfolgreich drei studioübergreifende FPS-Playtests mit Entwicklung durchgeführt. Tyler Witkin hat die Playtests hervorragend koordiniert und anschließend Feedback eingeholt.
Die Entwicklung der Automatisierung hat sich beschleunigt. Melissa Estrada und Tyler Witkin verwenden den Sandox-Editor und den Flussdiagramm-Editor, um Ebenen zu erstellen, die den so genannten Feature-Tester verwenden. Diese Stufen werden verwendet, um verschiedene schiffs- und FPS-bezogene Funktionstests zu automatisieren.
Dank des sehr informativen Feedbacks von Senior Technical Designer Rob Reininger haben wir unsere Editor-Tests deutlich verbessert, um mehr Tests in Bezug auf Werkzeuge und Leveldesign durchzuführen.
Die Tests des Sozialmoduls und der Planetenseite werden dank der Bemühungen von Todd Raffray fortgesetzt. Sobald ein System oder Werkzeug entwickelt wurde, stellt Todd sicher, dass es als Testfall in unseren umfassenden Planetside Tests hinzugefügt wird. Der neueste Zusatz ist der Usable Editor. Der Usable Editor wird verwendet, um NSCs die Möglichkeit zu geben, mit Objekten zu interagieren. Der Usable Editor ist ein großer Teil des gesamten Subsumtion (Peaceful NPC AI) Systems.
Jeffrey Pease stellt sicher, dass der General Instance Manager während seiner offiziellen Implementierung in Alpha 1.2.0 ordnungsgemäß getestet wird. Der General Instance Manager ist unser Revamp für die Backend-Lobby und die Matchmaking-Systeme. Jeffrey leitet auch eine Untersuchung zur Verhinderung potenzieller Hacks und Exploits und hat unseren Engineering-Leads, die nun einen Aktionsplan zur Lösung dieser Probleme haben, sehr wertvolle Informationen zur Verfügung gestellt.
Herzlichen Glückwunsch an Andrew Hesse, der in die Rolle des QA Lead für das Austin Studio gewechselt ist. Andrew hat eine erstaunliche Arbeit geleistet, indem er alle Aspekte des Spiels getestet hat und war eine große Hilfe für unsere Schiffsentwickler als unser ständiger Schiffsspezialist. Diesen Monat begrüßen wir unseren neuesten Mitarbeiter im QA-Team, Andrew Rexroth. Rex verfügt über umfangreiche QS-Erfahrung und ist bereits eine große Hilfe bei speziellen Star Marine Tests.
Im nächsten Monat werden wir unsere Tests von Alpha 1.2.0 fortsetzen und gleichzeitig Mehrspieler-Hangars, deutlich größere Spielplätze, das Multi-Crew-System und vieles mehr testen.
Spielunterstützung
Der Monat Juni für Game Support wurde hauptsächlich für das Design, die Überprüfung und den Aufbau von Infrastruktur und Prozessen aufgewendet, die unseren Geldgebern auf serviceweiter Ebene helfen werden.
Besonders hilfreich ist unser systemweites administratives Broadcast-Tool, das es uns ermöglicht, allen Spielern, die mit einem Live-Service verbunden sind, eine Kommunikationsmethode zur Verfügung zu stellen, die unerlässlich ist, um Sie während des Spielens mit aktuellen Informationen zu versorgen. Wir arbeiten auch daran, unsere aktuelle forumsbasierte Live-Service-Benachrichtigungsseite durch eine eigene Webseite zu ersetzen, die letztendlich eine Server-Statusseite für alle Umgebungen (Arena Commander, Star Marine, PTU, Patches, etc.) beinhalten wird und uns ein effektives Werkzeug an die Hand gibt, um den Zustand des Dienstes an alle Spieler zu kommunizieren.
Wir haben auch weiterhin geholfen, die Probleme von May's 1.1.3 Release zu lösen. Wir haben die Probleme der aktuellen Version identifiziert und kommuniziert und aktiv mit der Produktion zusammengearbeitet, um diese Probleme zu beheben, einschließlich einiger der Probleme mit dem Zustand von Raketen und Schiffsschäden, die wir gesehen haben.
Schließlich haben wir begonnen, Ideen und Designs für das, was wir brauchen werden, um unsere verschiedenen Umgebungen und insbesondere das Persistente Universum zu unterstützen, zu entwickeln. Die Unterstützung von Spielern hängt in der Regel von der Art des Spiels ab, aber Star Citizen hat alle drei (Singleplayer, Multiplayer und PU)! Wir haben angefangen, uns zu fragen: Welche technischen Ineffizienzen haben wir bei der Unterstützung unserer Spieler heute? Was wird das erwartete Verhalten innerhalb des Spiels sein, und was werden sie von uns als Dienstleistung verlangen? Wie managen wir die Vielzahl der versuchten Account-Übernahmen, die in jeder PU vorkommen, und welche Instrumente brauchen wir, damit sich die Spieler schützen können? Wie schaffen wir es, dass die Spieler in der Lage sind, auf den sekundären Graumarkt zu gehen, ohne ihn vollständig einzuschränken?
Wir haben heute keine Antworten auf all das, aber wir haben sie stark investiert. Dies sind wichtige Fragen, die man sich bei der Bildung einer Online-Community stellen muss, insbesondere der BDSSE!
IT/Betrieb
Der Juni war ein aufregender Monat für das IT-Team. Wir haben weiterhin Leistungsoptimierungen an unseren Build-Systemen vorgenommen, und während jede Verbesserung großen Stolz hervorruft, haben wir das Gefühl, dass wir an den Punkt kommen, an dem jede neue Verbesserung, obwohl sie wichtig ist, immer kleinere und kleinere Gewinne bringt. Nicht alle Gewinne werden jedoch von der Hardware kommen, so dass wir wieder eng mit einigen Mitgliedern des DevOps-Teams zusammenarbeiten, um die Größe der Daten, die wir verschieben, zu reduzieren und ebenso wichtig ist, die Anzahl der Datenbewegungen zu reduzieren. Eine der verbleibenden Herausforderungen ist unser Asset-Build-System. Dies sind die grafischen Assets, die für jeden Build gerendert werden müssen, und mit den Treuezielen, mit denen wir arbeiten, ist dies ein sehr großer Teil des Build-Prozesses. Diesen Monat haben wir mit der Arbeit begonnen, diesen Job in viele kleinere Jobs einzubauen, damit wir mehr von dieser Arbeit parallel ausführen können, um die gesamte Buildzeit für diesen Teil des Builds zu verkürzen. Das DevOps-Team verwaltet die Build-Systemlogik und das IT-Team liefert die Hardware für die Aufträge.
Zusätzlich zum Build-System-Tuning hat die IT diesen Monat einige zusätzliche Reisen unternommen. Paul aus Austin und Hassan aus Manchester reisten hin und her zu unserem Büro in Frankfurt und halfen bei der Planung der Logistik des Büroumzugs dieses Studios. Ein gutes Maß an Planung und Vorbereitung geht in einen solchen Umzug und alles liegt bisher im Zeitplan.
Sie haben alles von der Elektrik und Kühlung über IP-Adressen bis hin zu VPN-Tunneln abgewickelt. Aufgrund ihrer harten Arbeit, alles auf ein Wochenende abzustimmen, wird das Entwicklungsteam keine Ausfallzeiten erleben.
Dennis aus LA und Chris aus Austin entwickeln weiterhin kundenspezifische Konfigurationen für Tests, basierend auf dem Feedback, das wir aus den Foren erhalten. Wir liefern nicht mehr nur gemeldete Zahnräder an die Qualitätssicherung für einmalige Tests. Dennis und Chris bauen und rekonstruieren jetzt kundenspezifische Systeme, um die gemeldeten Systeme in Fällen, in denen wir glauben, dass Hardware ein wichtiger Faktor sein könnte, anzupassen. Außerdem haben sie in unseren Testlabors mit dem frühen Testen von Windows 10 begonnen.
Der Juni war ein aufregender und lohnender Monat für die IT, aber wir haben für Juli einige noch größere Dinge geplant.
Dev Ops
Der Juni wurde hauptsächlich von 3 Großprojekten für DevOps genutzt. Der neue Launcher, der neue Build-Server und unser Umweltprojekt "Phoenix".
Der neue Launcher wurde bereits in mehrere Codeversionen unterteilt, an denen gleichzeitig gearbeitet wird. Während der aktuelle öffentliche Launcher die Version 1.6 ist, befindet sich die Version 2.0 im Test mit dem Unternehmen und wird für die FPS-Playtests verwendet. Die Version 2.1 arbeitet derzeit an der Einführung für die nächste Woche und wird schnellere Downloads, kleinere inkrementelle Patches und einige Verbesserungen der Downloadgeschwindigkeit ermöglichen. Version 2.2 kommt gleich danach mit einer Reihe weiterer Funktionen, und an Version 3.0 wird gearbeitet, während der ganze Rest dieses Prozesses stattfindet. Version 3.0 ist eine komplette Überarbeitung der Benutzeroberfläche und sollte dem Endprodukt viel näher sein.
Der neue Build-Server steht kurz vor der Fertigstellung. Wir streben weiterhin ein Release für das Unternehmen Mitte Juli an, wobei die ersten Builds aus diesem System im September an die Öffentlichkeit gehen. Für die Spieler sollten sie bei diesem Wechsel überhaupt keinen Unterschied sehen. Für das Unternehmen und die Entwickler sollten die Verbesserungen durch dieses System jedoch enorm sein. Es sollte uns nicht nur ermöglichen, mehr Builds gleichzeitig auszuführen, was den Arbeitsdurchsatz erhöht, sondern auch die Zeit, die Entwickler auf den Build warten, reduziert, sondern auch die Gesamtgeschwindigkeit des Builds verringert. Derzeit dauert es 4 Stunden, um einen Build zu erstellen, und wir müssen etwa 6-8 Builds pro Tag erstellen, damit die Entwicklung voranschreitet. Wie du wahrscheinlich sehen kannst, ist dies mehr Zeit am Tag als wir haben. So werden Builds gesichert, übersprungen und die Arbeit verlangsamt. Der neue Build-Server wird es uns ermöglichen, 2-4 Builds gleichzeitig auszuführen und sollte die 4 Stunden reduzieren. Wir müssen noch genaue Messungen durchführen, um herauszufinden, wie schnell die Builds sein werden.
Wie Chris Robert in seinem Brief des Vorsitzenden erwähnt hat, haben wir an dem, was wir das dynamische Umgebungssystem "Phoenix" nennen, gearbeitet. Jedes Mal, wenn das Team einen neuen Build von Star Citizen startet, werden alle Daten, die die Server benötigen, automatisch auf Festplatten in Google kopiert; dies ist eine Momentaufnahme unserer Spieldaten. Diese Scheiben sind in zwei bis drei konzeptionelle Teile unterteilt: Basis-Image (das Betriebssystem und ein paar andere Dinge), Protokolle und Serverdaten (Code und Assets). Wenn wir eine Umgebung aufbauen, mounten wir Duplikate dieser Festplatten an jede Virtual Machine (VM), die wir aufspielen. Duplikate des Snapshots werden sehr schnell erstellt, etwa 45 Sekunden für 200 Gigabyte Daten. Wir haben einen Automatisierungscode geschrieben, um automatisch Befehle auf der VM auszuführen, um sie entsprechend dem Servertyp zu konfigurieren (Spiel, Matchmaking, Party, etc.). Dabei wird dem Server ein neuer DNS-Eintrag zugewiesen, der auf der Version der hochgeladenen Daten basiert. Wenn ein neuer Build erstellt wird und wir ihn in eine Umgebung verschieben müssen, lösen wir einen Befehl aus, der automatisch alle VMs herunterfährt, die Duplikate der Basis-Image- und Serverdatenplatte entfernt (Protokollplatten werden immer für die Fehlerbehebung aufbewahrt) und den Server mit den neuen Duplikaten neu startet, basierend auf dem neuen Snapshot und die Umgebung läuft und ist bereit für die neue Version.
Dieser gesamte Prozess dauert ca. 8 Minuten. Wenn wir eine QA-Umgebung, die auf diese Weise aufgebaut ist, zu einer PTU-Umgebung ausbauen wollen, senden wir einen Befehl an unsere Provisionierungsschicht und sie geht an Google, fordert mehr VMs an, erstellt mehr Festplattenduplikate, mountet diese Snapshots, führt Chefbefehle aus, um sie zu konfigurieren, fügt ihre DNS-Einträge hinzu und verbindet sie mit der vorhandenen Infrastruktur, die verwendet werden soll. Zu diesem Zeitpunkt haben wir eine PTU-Umgebung. Wir wiederholen diesen Prozess, um die Produktion aufzubauen. Jedes Mal, wenn wir eine Umgebung erweitern, dauert es etwa 8 bis 10 Minuten, je nach Art der Umgebung und den von uns benötigten Konfigurationen.
Der Nutzen dieser dynamischen Schöpfung und der Umwelterweiterung ist dreifach. Zunächst werden alle geänderten Konfigurationen, fehlgeleiteten Einstellungen oder fehlerhaften Prozesse vollständig entfernt, wenn die VMs mit den neuen Festplattenduplikaten neu erstellt werden. Alle Konfigurationsänderungen, die fortbestehen müssen, sollten auf der Chefebene vorgenommen werden. Zweitens können wir absolut sicherstellen, dass PTU und Produktion genau die gleichen Umgebungen sind, auf denen QA getestet wurde, so dass es keine seltsamen Unterschiede geben wird, die wir in QA nicht erkannt haben, wenn wir live gehen. Der dritte Vorteil ist einfach die Geschwindigkeit. Es ist viel schneller, Umgebungen während des Betriebs dynamisch zu erstellen, als jedes Mal Daten zu kopieren. Die letzten beiden Punkte sind eine ziemlich große Sache. Wenn unsere Erfahrung uns etwas gelehrt hat, dann ist es, dass eine einheitliche Testumgebung, die schnell eingeführt werden kann, von entscheidender Bedeutung ist, und dieses neue System ist ziemlich schnell. Es ist ein enormer Kraftmultiplikator für unsere Fähigkeit, unsere Testversionen schnell zu wiederholen, was bedeutet, dass QA und letztendlich unsere Geldgeber in der Lage sein werden, vielfältigere Tests schneller durchzuführen. Je genauer wir Versionen zu unserer Qualitätssicherung und zu unseren Geldgebern bekommen können, desto besser können wir das Spiel letztendlich gestalten. Juli dürfte ein sehr spannender Monat werden, in dem einige dieser Großprojekte aus der Entwicklung in die Produktion gehen.
Grüße Bürger,
Die Gießerei 42 ist unter Spannung und bereit, weiterhin hart zu arbeiten! Zwischen der Unterstützung des p-cap-Shootings in London, der Arbeit an der eigenständigen Staffel 42 und der Fortführung der Engineering-Aufgaben für den mehrköpfigen Arena Commander waren wir beschäftigt! Hier sind die Details von unseren Abteilungsleitern:
Animation
Wir haben mit der Arbeit begonnen, einige der systemischen Ai-Animationen für feindliche Aktionen aufzubrechen. Dazu gehören Dinge wie das Betreten und Einlaufen, um aus verschiedenen Blickwinkeln abzudecken. Reagieren auf Granaten und gehen aus dem Weg. Darüber hinaus hat das Team an der Verfeinerung einiger der Mechanismen gearbeitet, die derzeit im Spiel implementiert sind, um ein reaktionsschnelleres Gefühl zu erreichen und gleichzeitig die realistisch erfassten Bewegungsdaten zu erhalten. Wie immer sind wir für die Kunst- und Designteams hier in der Gießerei 42 für alle Ausblendmechaniken und Umweltanimationen da.
Ingenieurwesen
Zwei Bereiche, über die ich diesen Monat sprechen möchte und mit denen wir uns hier in Großbritannien stärker beschäftigen, sind die Benutzeroberfläche und die KI.
Auf der KI-Seite nehmen wir eine aktivere Rolle bei der Entwicklung ein und haben gemeinsam mit unseren Kollegen in Frankfurt und Moon Collider einen Großteil der Grundlagenarbeit geleistet, um unser neues CIGAI-System in Betrieb zu nehmen. Wir haben uns mit einem neuen Kommunikationssystem beschäftigt und wie wir es in Verbindung mit unserer aktuellen Dialoglogik nutzen können, um die Grundlagenarbeit der Warlord und Vixen KI-Charaktere des DFM-Überlebensmodus zu erweitern und das Cockpit-Audiosystem (alias Bitching Betty) intelligenter zu gestalten.
Wir haben auch einige der Funktionen von CryAI in unser System übernommen und dann so angepasst, dass sie besser zu unseren Anforderungen an Star Citizen passen. So vor kurzem hat das das Tactical Point System, das Dinge wie Cover beinhaltet, und das Group AI System, das eine bessere und einfachere Handhabung mehrerer KI-Objekte ermöglicht, besonders in den visuellen Gameplay-Skripten (oder dem Flow-Graphen, was immer Sie bevorzugen!).
Auf der Benutzeroberfläche arbeiten wir hier schon seit geraumer Zeit, haben aber in letzter Zeit begonnen, eine größere Verantwortung zu übernehmen und mehr von der Arbeit zu übernehmen. Wir haben das Team um einen neuen Künstler und einen neuen Ingenieur erweitert. Den neuen Ingenieur zu haben bedeutet, dass wir jetzt jemanden haben können, der sich ausschließlich darauf konzentriert, die Anforderungen an die Benutzeroberfläche der Staffel 42 zum Leben zu erwecken. Einige der vielen Features, die wir ihm in den Weg gelegt haben, sind die Entwicklung der Schnittstelle für das taktische Visier und die Plünderung. Diese erfordern verschiedene Augmented-Reality-Overlays und Post-Process-Effekte, um Menschen und Objekte hervorzuheben und dem Spieler zusätzliche Informationen über die Welt um ihn herum zu geben. Wir haben auch eine Iteration auf den Visieranzeigen für Star Marine durchgeführt, da jeder Helmtyp sein eigenes, einzigartiges Aussehen und Gefühl haben wird, das sein eigenes, individuelles UI-Setup erfordert.
Unser neuer Künstler arbeitet derzeit am Look-dev' der Schiffshersteller, parallel dazu wird der Schiffs-UI-Code viel Planungsarbeit geleistet, um mit Multi-Crew-Schiffen und all den Herausforderungen, die uns auf den Weg bringen, umgehen zu können, wie z.B. die Möglichkeit, dass ein Kapitän verschiedene Kontrollen an den Co-Piloten oder Turmschützen delegieren (oder ausschließen) kann. Es wird auch geplant, dass die Spieler ihr Display individuell gestalten können. setzt ihre Cockpits ein und gibt ihnen die Möglichkeit, verschiedene Ausgaben auf verschiedene Displays zu übertragen. All diese Planung ist, weil, um die von uns benötigte Funktionalität zu unterstützen, die zugrunde liegende Struktur, auf der der UI-Code sitzt, ein wenig einen Refactor benötigen wird. Wir haben bereits viel von der fest programmierten Einrichtung der Benutzeroberfläche genommen und sie viel datengesteuerter gemacht (mit unserem DataForge-Tool), aber wir haben sie auch geändert, um sie viel flexibler zu machen, so dass jeder Teil des HUD an alles andere im Spiel angehängt werden kann, was die Benutzeroberfläche aufnehmen kann. So wird es plötzlich einfach, das Radar von Ihrem Visier auf eines Ihrer Cockpit-Displays zu bewegen. Das wird fantastisch!
Grafiken
In diesem Monat hat sich das britische Grafikteam auf mehrere Bereiche parallel konzentriert. Die Arbeit an der Mesh-Merging-Technologie geht weiter und wird in größeren Umgebungen wie Asteroidenfeldern getestet, um sicherzustellen, dass sie mit einer beliebigen Anzahl von Objekten umgehen kann. Dies kommt gut an und wird sehr bald serienreif sein und bald in öffentlichen Veröffentlichungen eingesetzt werden, um Ihnen eine bessere Leistung auf neuen Ebenen zu bieten.
Wir haben einen neuen Senior-Programmierer, der an der volumetrischen Gaswolkenwiedergabe arbeitet, dichte Wolken und weichen Nebel mit anisotroper Beleuchtung untersucht (der helle Rand, den man am Rande von Wolken bekommt). Dies wird eine sehr langfristige Aufgabe sein, da sie sehr komplex ist, aber etwas ist, das wir in unserem Spiel wirklich vorantreiben wollen. Wir haben uns auch mit der Technologie der Gesichtsanimation beschäftigt und verschiedene Setups profiliert, um zu sehen, wie weit wir die Technologie vorantreiben können, während wir eine angemessene Bildrate beibehalten. Dazu gehören das Ausprobieren verschiedener Polygonzahlen, die Anzahl der Verbindungen/Knochen im Gesicht und die Anzahl der Posen/Mischformen, die jeder Charakter verwenden kann. In diesem Zusammenhang haben wir auch untersucht, was wir tun können, um das Rendern unserer Gesichter voranzutreiben, was keine leichte Aufgabe ist, wenn man auch viele Charaktere auf dem Bildschirm unterstützen muss. Wir werden hoffentlich nächsten Monat mit der R'n'D. beginnen und freuen uns darauf, das Ergebnis zu teilen (gut oder schlecht!)."
Design
Der Juni war hier ein arbeitsreicher Monat für das Design mit GamesCom. Wir sind immer noch mit voller Wucht bei Squadron 42 und unterstützen das Performance Capture Shooting mit last minute Level Optimierungen auf dem Studiogelände, damit es so fantastisch wie möglich aussieht. Alle Ebenen sehen mehr und mehr poliert aus mit einem stetigen Strom von großartig aussehenden Gebäudefliesen, die von unserem Umweltteam stammen und so lange wiederholt werden, bis sie fantastisch aussehen, während sie es den Leveldesignern dennoch ermöglichen, die Umgebungen glaubhaft zu gestalten.
Wir hatten diesen Monat ein internes "Show-and-Tell", da viele der neuen Mitarbeiter die volle Tiefe des Plans für Star Citizen noch nicht gesehen hatten, und es ist sicher zu sagen, dass es fantastisch gut gelaufen ist, mit vielen Kiefern, die das Staunen in der Tiefe des Spiels verloren haben. Es war großartig zu sehen, wie viel Arbeit in so kurzer Zeit tatsächlich geleistet wurde.
Das technische Designteam ist gewachsen und deckt nun Aufgaben ab, von der Ausbalancierung der FPS-Waffen bis hin zur Inbetriebnahme der Vanduul-Flotte im Motor, von Großschiffen bis hin zu Jägern.
Das Arena Commander Team hat nun den "Large-World"-Code vom Engineering-Team erhalten und beginnt zu erkennen, was in Bezug auf die Größe des Universums erreicht werden kann, genug um zu sagen, dass Sie die Früchte ihrer Arbeit bald sehen sollten.
Die Systemdesigner haben die Spezifikation für die "Multifunktionsdisplays" in den Cockpits fertiggestellt, so dass die Funktionalität auf alle Schiffe ausgedehnt werden kann und vom Einmannschiff bis zum größeren Großschiff vollständig skalierbar ist. Dies ist eine weitere unserer dringenden Aufgaben für GamesCom und wird hoffentlich in Kürze näher erläutert.
Wir versuchen auch, eine erste Implementierung von "Quantum Jumping" vorzubereiten, um eine schnellere Navigation durch die neue "large-world"-Technologie zu ermöglichen, die sehr vielversprechend ist.
Alles in allem ein großer Monat für uns, aber ich habe das Gefühl, dass wir in den nächsten Monaten viel beschäftigter werden. Vielleicht ist es an der Zeit, bald eine Hängematte im Büro aufzustellen. Vielen Dank an alle wie immer.
Kunst
Konzeptkunst
Biggies in diesem Monat waren das Update der Bengalbrücke und der Mining Bot, weitere Arbeiten an der Behring Ballistic Flinte, dem Transportschiff Xi'an, der Vanduul-Flotte und der weiteren Definition des Requisitenkonzepts, um die Shubin-Minenbasis und einige Piratenbasen, die für die Sq42-Handlung benötigt werden (keine Spoiler!), zu erweitern.
Schiffe
Der Vergelter wurde in diesem Monat daran gearbeitet, ihn weiterhin flugbereit zu machen - aufregende Zeiten! Argo RUV erreicht die finale Kunst (mit Ausnahme des Pod, das für die Filmkunst überarbeitet werden muss), der Idris sieht stellenweise sehr gut aus, kann es kaum erwarten, etwas davon zu enthüllen. Cutlass startete seine neue Greybox unter Berücksichtigung von Designrevisionen, Mining-Bot geht in die Textur- und Materialphase, Starfarer - langsamer als wir es gerne hätten, es ist eine Frage der Ressourcen, und wir brauchen mehr talentierte Leute, um dieses Schiff so komplex wie möglich zu bauen. Die Bengal Bridge wird beginnen, sobald die Konzepte unterzeichnet sind.
Umwelt Kunst
Ein kurzes Update diesen Monat, da vieles von dem, was wir getan haben, vorerst geheim gehalten werden muss. Die Fortschritte in unserer VS-Umgebung mit Hangars, Kontrollräumen, Korridoren, Luftschleusen und Außenlandeplätzen, die alle nahtlos durchquert werden können, gehen weiter. Hoffentlich können wir euch einige der wirklich coolen Dinge zeigen, an denen wir in nicht allzu ferner Zukunft gearbeitet haben, also bleibt dran!
Requisiten
Wir bereiten eine klare Dokumentation für das Outsourcing vor, wählen uns mit den Techniken ein, die für Materialien benötigt werden, die uns die meisten Probleme bereiten, und dann, nächsten Monat, sollten wir loslegen.
VFX
Das VFX-Team hat hart daran gearbeitet, mehr Schiffe "flugbereit" zu machen - dazu gehören Effekte für Triebwerke, Waffen und Schäden. Insbesondere die Effekte der Scythe sehen ziemlich knallhart aus! Wir haben auch weiterhin an den Umwelteffekten - sowohl im Innen- als auch im Außenbereich - für den Vertikalschnitt gearbeitet. Wir begannen uns auch auf Star Marine's Waffen-VFX zu konzentrieren, um sicherzustellen, dass sie der Gesamtqualität der Level, Charaktere und natürlich der Waffen entsprechen. Wirklich aufregende Zeiten, um ein VFX-Künstler in der Foundry 42 zu sein!
Audio
Hey zusammen! Dieser CIG Audio Community-Bericht könnte sich ein wenig schlängeln, es ist viel los, aber ich denke, das sollte die meisten interessanten Teile abdecken.
Erstens, Wise. Wir sind fast da, was unsere Masse an Asset Conversion/Reengineering betrifft, zumindest ist das Ende in Sicht. Also haben Stefan, Darren und ich einige Zeit darüber nachgedacht, wie man die Dinge einrichtet, damit wir das Spiel gut mischen können. Unser Spiel ist im Gange und wird natürlich ständig überarbeitet, so dass die Strategie, die wir verfolgen müssen, nicht typisch für einen One-Shot-Release Titel ist. Wir denken, dass wir die Grundlage dafür haben, was uns gut dienen sollte, und wir ändern die Projektstruktur, um dies zu berücksichtigen.
Auf der Seite der Audiotechnik ist viel davon immer noch die Sicherstellung, dass Dinge, die früher funktionierten, wieder funktionierten; und das Ausbügeln von noch vorhandenen auftretenden Bugs/Foibles. Eine gewisse Ironie dessen, was wir tun, ist, dass wir umso mehr zum Problem beitragen, dass zu viele Sounds gleichzeitig abgespielt oder auf einer bestimmten Ebene bearbeitet werden, je mehr wir einzelne Sounds in allen möglichen Systemen zum Einsatz bringen. Wwise hat einige Möglichkeiten, mit dieser Situation umzugehen, aber das Ideal ist, sicherzustellen, dass Wwise sich nicht in Verarbeitungselementen verfängt, die außerhalb des Interessenbereichs des Spielers liegen. Im Kern, wenn etwas zu weit weg ist, um gehört zu werden, dann bringen wir es in einen Schwebezustand, wenn es um Audio geht, aber nur in dem Maße, wie wir es brauchen, damit es, wenn es wieder zum Leben erwacht, wie erwartet funktioniert. Es gibt alle möglichen Dinge, die dabei zu berücksichtigen sind, aber genau hier sind wir im Moment in Bezug auf die Kern-Audiotechnik. Es ist nicht glamourös, ich weiß, aber es wird die Dinge am Laufen halten, wenn wir das früher oder später richtig machen.
Wir haben ein paar neue Schiffe, von denen eines, an dem Darren viel gearbeitet hat. Dies musste auch für seinen Schiffscomputer neu aufgenommen werden, und er hat sich den UI-Aspekt angesehen, Sounds entworfen und gesehen, wie man sie am besten einbezieht. So viel Spieloberfläche in diesen Tagen basiert irgendwie in Flash und das kann problematisch für die Implementierung von Sound in einer Weise sein, dass wir leicht iterieren können. Während wir das tun, überlegen wir uns also, wie wir diese Pipeline verbessern können.
Übrigens, was den Origin-Schiffscomputer betrifft, halte ich meine Hände hoch und gebe zu, dass ich es versäumt habe, die bisherige Essenz dessen zu erfassen, was den Schiffscomputer für die Origin-Modelle so großartig gemacht hat. Im Grunde genommen haben wir auf Sie gehört und das Feedback, das Sie zu dem neuen gegeben haben, aufgenommen - und ich bin fest entschlossen, dass wir dieses zurückgewinnen werden. Ich bin damit nicht zufrieden und das wird behoben!
Persistentes Universum. Wir können noch nicht allzu viel darüber sagen, aber wir unterstützen die Umweltaudiosignale dafür kontinuierlich.
FPS. So viel davon ist in Wwise gebunden, es gab viele neue Inhalte, die für FPS in Bezug auf Waffen, Charakter Foley und Dialog benötigt wurden, und das kommt gut voran. Wir bekommen auch einen Haufen neuer Musikinhalte für FPS. So haben wir einen Workflow ausprobiert, in dem unser Komponist Pedro Macedo Camacho von seinem Studio in Wwise aus arbeitet, und wir importieren das, was er von seiner Musik aufbaut, in Wwise an unserem Ende. Es ist in logistischer Hinsicht nicht praktikabel, Zugang zu unserem eigenen Wwise Projekt zu gewähren (das ständig wächst), so dass sich das Testen dieses Workflows, bei dem er uns eine Projektdatei übergibt, als sehr wertvoll erwiesen hat.
Es war eigentlich überraschend einfach, seine Workunits in unser Wwise Projekt zu importieren, und ließ mich denken, dass dies ein Weg für diejenigen unserer Modding-Community sein könnte, die ihre Mods/Materialien in Star Citizen importieren möchten. Neue Assets könnten von Moddern innerhalb von Wwise produziert werden, die dann an uns zur Integration in das Wwise Projekt weitergeleitet werden, so dass wir an solide Banken exportieren usw. und die Event-Trigger zur Verwendung an Sie zurückgeben. Es mag auf den ersten Blick etwas unhandlich erscheinen, aber ich denke, dass die Zusammenarbeit mit der Modding-Community der richtige Weg ist, um ein qualitativ hochwertiges Erlebnis zu gewährleisten, und ich würde das gerne ausprobieren.
Arena Commander (oder Hundekampfmodul); eine ganze Reihe von Materialien wurden konvertiert oder einige Fälle vollständig neu erstellt, um besser als zuvor zu funktionieren. Als Audio Director kann ich im Moment nicht oft viel Sound Design machen, was natürlich etwas schade ist, da es das ist, was ich bin, in meinem Kern. Es war also so gut, dass ich in der Lage war, irgendwann für die Arbeit an einigen Schiffsantrieben zu passen und in materieller Hinsicht zu einem Schubdüsen-Design beizutragen! Luke hat das, was ich getan habe, genommen und es auch ein wenig repariert, er ist sehr in den Raumschiff-Audioaspekt unseres Spiels verliebt, so dass es für ihn beruhigend war, meine Implementierung zu reparieren. Im Allgemeinen nimmt viel von diesem Material Zeit für alle unsere Sound-Designer in Anspruch, denn es ist der Löwenanteil von Star Citizen, im Moment gibt es einfach viel zu tun, aber wir schnitzen es gut durch.
Re: Dialogunterstützung für die Staffel 42. Unser Dialogue Superman (kein offizieller Titel) Bob Rissolo war in London immer noch hart dabei. Es geht bald zu Ende, zumindest für den Moment, was bedeutet, dass er hier im Haus dauerhaft in die Gießerei 42 umziehen wird. Ein großer Schritt für ihn, wir sind immer noch sehr dankbar, dass er das sonnige San Diego gegen das mehr, nun, variable Klima von Manchester eintauscht!
Was unsere Tonstudios betrifft. Wenn Sie dies lesen, werden wir unsere neuen Türen für diese Türen installiert haben. Ich weiß, Türen scheinen eine so offensichtliche Sache zu sein, und das sind sie natürlich, wenn man versucht, den Rest des Studios nicht mit FPS-Gun-Soundeffekten, Explosionen und dergleichen zu überfallen. Aber wir haben eine Weile darauf gewartet, dass ein bestimmter Satz Türen hergestellt wird, wir waren einfach am falschen Ende einiger herstellerseitiger Produktionsprobleme, bei denen sie jeweils eine andere Farbe haben. Ich weiß, dass das leichtfertig erscheint, aber wenn man eine Reihe von isolierten Zimmern hat und aus einer anderen Disziplin kommt, spart man Zeit, um jemanden in das "Orangetonstudio" leiten zu können, anstatt einen Raum festzulegen, wer da sein könnte oder nicht. Das bedeutet auch, dass wir Räume bis zu einem gewissen Grad tauschen können. Mein eigener Raum wird ein Referenzraum für den Rest von CIG Audio sein, um zum Beispiel unseren Surround-Mix zu testen.
Im Moment sind Werkzeugverbesserungen etwas, das wir in Betracht ziehen. Je besser unsere Werkzeuge, desto einfacher ist es für uns, die Dinge ständig zu verbessern. Wwise ist ein ereignisbasiertes System und ist auf externe Ereignisse in irgendeiner Form angewiesen, um Sounds auf bestimmte Weise auszulösen. Zum Beispiel wollen wir bestimmte One-Shot-Sounds auslösen, wenn ein Triebwerk von Nullschub auf Vollschub umschaltet, zusätzlich zu dem, was wir für Triebwerke im Allgemeinen auslösen. Und dann lösen Sie verschiedene One-Shot-Ereignisse aus, wenn das gleiche Triebwerk vom vollen Schub zurück zum Nullschub übergeht. Das ist eigentlich etwas, das in der Box knifflig ist, da die Box in diesem Fall Wise ist, also wollen wir diese Events leichter als Sounddesigner und nicht als Programmierer einrichten können, also gibt es ein ganzes Toolset, das wir für die Definition von Logik in Betracht ziehen. Dies ist nur eines von vielen Werkzeugen, an denen wir einen echten Bedarf erkennen können.
Wir arrangieren, zurück nach Pinewood zu gehen, um eine ganze Reihe von Nötigungselementen für die Schiffe aufzunehmen. Sie erinnern sich vielleicht, dass sie mit uns an Foley für FPS gearbeitet haben. Es gibt eine neue Bibliothek mit dieser Art von klapperndem, knochenschüttelndem Material, das wir uns auch ansehen (man kann nie genug Quelle haben), aber wir wollen auch sicherstellen, dass unsere Sachen etwas individueller auf unsere Bedürfnisse zugeschnitten sind. Dafür werden wir die Butt-kickers niedermachen, ganz sicher.
Ich bin sicher, dass es noch mehr Dinge gibt, die ich von diesem Update verpasst habe, zögere nicht, uns mehr über den Ask A Dev-Teil der Community-Foren zu fragen, und wir werden weiterhin unser Bestes tun, um zu antworten. Danke fürs Zuhören!
QA
UK QA musste unsere Bemühungen in diesem Monat aufteilen, um sich mit den bevorstehenden wichtigen Ereignissen und Veröffentlichungen zu befassen. Star Marine (das FPS-Modul) und die Vorbereitung auf die Gamescom sind für die nahe Zukunft geplant, und die Tests der Staffel 42 laufen wie gewohnt weiter.
Star Marine hat sich sehr stark darauf konzentriert, wichtige Multiplayer-Bugs auszulöschen und zu versuchen, allgemeine Polarfehler zu finden. Glenn Kneale aus Großbritannien und Tyler Witkin von ATX QA haben zusammengearbeitet, um sicherzustellen, dass dieser Spielmodus gründlich getestet wird. Es gab eine Menge Cross-Studio-Stresstests, um sicherzustellen, dass es nach der Veröffentlichung stabil sein sollte.
Wir konzentrieren uns ganz besonders darauf, die Teile des Spiels zu testen, die auf der GamesCom gezeigt werden. Leider kann dort nicht allzu viel erwähnt werden, aber wir sind alle sehr gespannt, wie das, was derzeit gezeigt werden soll, ankommt.
Schließlich erhält Staffel 42 mehr Testzeit, die ihr gewidmet ist, während das Spiel voranschreitet, müssen wir sicherstellen, dass die neuen Mechaniken vorhanden sind und Alpha-Level-Rundgänge abgeschlossen werden können. Wir haben auch einige Zeit damit verbracht, etwas mehr Dokumentation zu erstellen, um unsere aktuellen Pläne zur Erweiterung der Tests auf S42 zu berücksichtigen.
Steven Brennon hat weiterhin Feedback von euch gesammelt und dafür gesorgt, dass es angemessen zusammengestellt und an die relevanten Personen geschickt wird.
Leider werden wir auch Chris "Chill" Hill am Ende des Monats verlieren. Wir wünschen ihm alles Gute, denn er ist einfach fantastisch, seit er letztes Jahr zu uns kam, aber wir freuen uns darauf, Steve Brennon zu einem Ersatz-Lead auszubilden.
Der Juni war ein arbeitsreicher Monat in allen Disziplinen, und das Team entwickelt sich dynamisch. Wir haben unsere neuen Büroräume weiter geplant, alles ist vorbereitet, um die Schlüssel zu unserem neuen festen Büro am 1. Juli zu bekommen. Wir werden sicherstellen, dass wir den neuen Standort mit allen teilen, falls jemand vorbeikommen und Hallo sagen möchte, natürlich mit Vorankündigung.
Ingenieurwesen
Im Juni implementierte Frankfurt Engineering in der Hauptcodebasis einige wichtige Elemente, die für diesen Monat geplant waren. Wie im letzten Monatsbericht erwähnt, waren die Große Welt (Verschiebung der Codebasis auf 64-Bit-Koordinaten), Camera Relative (Rendering-Koordinaten relativ zur Kamera, wodurch die Rendering-Galaxie ohne Genauigkeitsverlust möglich ist), Zone System (das neue räumliche Verteilungsschema von Star Citizen, das die Kryomaschine Octree ersetzt) nahe an der Star Citizen-Code-Mainline und wurden nun eingesetzt und werden bald ihren Weg in die verschiedenen Star Citizen-Spielmodule finden.
Die Integration relevanter CryEngine 3.7 SDK-Teile, kombiniert mit unseren neuen Änderungen, wird während der Erstellung in unsere Codebasis implementiert. Zusätzlich wurde in diesem Monat ein großer Aufwand für die Unterstützung von mehrköpfigen Fahrzeugschiffen unternommen: Lokales Physikgitter, Physik-Debugger, Entitäten und Prefabs, Unterstützung für neue 3D-VisArea-Formen, all dies in Kombination mit dem Zonensystem, werden im Rahmen des Betriebs beweglicher Schiffe bearbeitet. Unter anderem hat der Multi-Crew-Entwicklungsprozess einige Fehler und Fehlfunktionalitäten offengelegt, die seit Jahren in der CryEngine Codebasis leben....
Wir haben weiter an Optimierungen, verbesserten Speicherformaten, Fehlerbehebung, Bereinigung und allgemeiner Motorunterstützung für andere CIG-Studios gearbeitet.
KI
Im Juni konzentrierte sich das KI-Entwicklungsteam hauptsächlich auf die Basissysteme, die der menschliche Charakter benötigt, um durch die gesamte Spielwelt zu navigieren.
Wir haben den ersten Durchgang zur Integration des CryEngine MNM Navigationssystems und des multithreaded MNM Pathfinders abgeschlossen. Wir haben auch den ersten Durchlauf zur Anbindung des CryEngine Movement Systems an das aktuelle Verhaltensbaumsystem abgeschlossen. Das Bewegungssystem kümmert sich um die Analyse eines vom MNM Pathfollower zurückgegebenen Pfades und erstellt einen Plan, wie die Bewegung ausgeführt werden soll.
Stellen wir uns eine Figur vor, die sich in eine Deckungsposition bewegen muss, der NSC muss einem Weg bis zur Deckungsstelle folgen und dann die richtige Haltung einnehmen, um sich tatsächlich hinter der Deckung zu positionieren. Das Bewegungssystem ermöglicht es uns, den richtigen Kontext von der Anfrage bis zur Ausführung der Bewegung zu haben, so dass wir den notwendigen Schritt vorhersagen können, den der NSC unternehmen muss, um korrekt in eine "hintere Abdeckung" zu gelangen.
Wir sind gerade dabei, das taktische Punktesystem CryEngine mit unseren neuen Verhaltensweisen zu integrieren. Das Tactical Point System (oder TPS) ist ein Abfragesystem, das es uns ermöglicht, Sonderpositionen mit bestimmten Eigenschaften abzufragen.
Zusätzlich zur Entwicklung der Systeme kümmern wir uns um die Erstellung des gesamten Klebecodes zwischen den Systemen, damit die NPCs die bestmögliche Qualität erhalten.
Und wir koordinieren weiterhin die Verbesserungen am Kythera Behavior Tree und dessen Integration mit Dataforge.
Design
In diesem Monat hat das DE Design Team viel Zeit damit verbracht, an vier Initiativen zu arbeiten: Aufbau eines Levels für Staffel 42, Unterstützung bei der Freigabe des FPS-Moduls, Aufbau von KI-Verhaltensbäumen für FPS, Staffel 42 und das Persistent Universe und dann Zusammenarbeit mit dem britischen Team an Staffel 42 Level Feedback. Wir überprüfen die Missionen und Begegnungen, die sie für das Tempo, den Einsatz von Mechanik im gesamten Level, den Level-Flow und die Ideen für das Gameplay von Moment zu Moment aufbauen.
Animation
Derzeit verfügt das DE-Büro nur über einen Animator, der sich ganz auf die Unterstützung von Kinofilmen konzentriert. Diesen Monat arbeiteten sie daran, Szenen für Drehbuchveranstaltungen und Filmszenen im Spiel einzurichten, Pipeline-Tools zu identifizieren und zu dokumentieren und eine Überprüfung des Squadron 42-Skripts (mit dem Cinematic Director), um herauszufinden, welche Szenen den Kinematiken gehören werden.
Kinematiken
Hannes ist zurück vom langen Filmdreh. Er wird in der Lage sein, zum Monatsbericht beizutragen, der nächsten Monat beginnt. Sie hatten einige wirklich talentierte Schauspieler auf der Bühne, die erstaunliche Leistungen zeigten. Wir alle freuen uns intern darauf, diese zusammenzuführen, wie ich sicher bin, dass auch die Geldgeber dies tun.
Audio
Nicht viel Neues für Audio in diesem Monat, immer noch arbeitend an der Wwise Konvertierung, die letzten Monat begann. Die EVA-Triebwerke und Ship Shield-Schläge wurden angeschlossen, um das Wwise-Audiosystem zu nutzen, und mehrere audiobezogene Fehler behoben. Beginn der Arbeiten zur Verbesserung der entfernungsbasierten Aussortierung aktiver Schallquellen, damit die Sound-Designer detailliertere Klanglandschaften erstellen können, ohne die Sound-Engine zu überlasten.
System erstellen
Im Juni besuchte unser Senior Build Engineer unser Austin Studio (ATX) für 3 Wochen und arbeitete in enger Zusammenarbeit mit den Dev-Ops /IT-Teams an vielen Aspekten unseres Build-Prozesses, der Optimierung und der studioübergreifenden Lieferung. Unter vielen Dingen war das Hauptziel, die Zeit zu verkürzen, die benötigt wird, um einen Build zusammenzustellen, Patches zu erstellen, Server einzusetzen und so weiter.
Wir haben uns entschieden, vom aktuellen Build-System wegzugehen und uns für etwas zu entscheiden, von dem wir überzeugt sind, dass es uns viel mehr Anpassungsmöglichkeiten geben wird, um es besser auf die Bedürfnisse unseres Spiels abzustimmen. Dies ist noch in Arbeit, es wurde viel Arbeit geleistet, und in den nächsten Wochen wird noch mehr getan werden.
VFX
In den letzten Monaten haben wir hart an verschiedenen Effekten der Staffel 42 gearbeitet. Einer dieser Effekte war ein riesiger Plasma-Bohrer. Es wird verwendet, um Asteroiden in kleinere Stücke zu zerlegen, um Ressourcen zu gewinnen.
Grüße Bürger!
Ein ganzer Monat ist vergangen und wir waren beschäftigt!
Ingenieurwesen
Wie üblich hat sich ein Teil des Teams auf die Entwicklung für kurzfristige Lieferungen konzentriert, wie z.B. die Unterstützung von FPS Lobby & Flow. Wir bewegen uns auch langsam davon weg, jetzt, da es das meiste von dem unterstützt, was wir für die erste Version benötigen, und haben begonnen, die Unterstützung von Mehrbesatzungsschiffen in der Lobby-Oberfläche hinzuzufügen.
Der Monat Juni hat uns ein paar tolle Features aus anderen Studios gebracht, die es uns ermöglicht haben, gemeinsam zu arbeiten, um den Online-Hangars etwas mehr Funktionalität zu verleihen. Wir haben hart an der aktuellen Holotable-Implementierung gearbeitet, um die Notwendigkeit zu reduzieren, dass Schiffe im Spiel gelaicht werden, damit sie in Arena Commander eingesetzt werden können. Dies wird es uns ermöglichen, die Ladezeiten zu verkürzen und die Verwaltung von servergehosteten Hangars zu erleichtern. Wir haben auch einen Teil der Flairs Implementierung und des Hangar Spawning überarbeitet, um in einem solchen Kontext richtig zu funktionieren.
Auch die Erfahrung auf dem Planeten ist nicht sich selbst überlassen geblieben, da wir noch daran arbeiten, die Augmented Reality (AR)-Erfahrung mit mobiGlas sowie das Einkaufserlebnis als Ganzes um einige Features und ein gewisses Maß an Feinschliff zu erweitern.
Design
Das Designteam hat Aufzüge und Türen für Nyx eingerichtet sowie verschiedene Funktionen (wie dynamisches Spawning, mobiGlas AR-Tags und Textstring-Lokalisierung) für die Artikel, die in Casaba Outlet erscheinen werden. Wir haben auch Follow-ups über das Einkaufserlebnis, Flairobjekte und Level Design Blueprints für Hurston, Crusader und Microtech durchgeführt.
Kunst
Diesen Monat haben wir viel Arbeit für die Nyx-Asteroidenkarte geleistet, Materialien und Texturen verbessert und die Umgebung so gestaltet, dass jeder Raum eine Geschichte zu erzählen hat. Wir haben auch an der Verbesserung einer unserer vorherigen Karten gearbeitet, indem wir ihr Layout geändert haben, um die Navigation zu optimieren und die Leistung zu verbessern.
Zusätzliche Anstrengungen wurden auf unserem Shopsystem unternommen. Wir haben Details hinzugefügt, wie die Kleidung in den Regalen platziert wird, um eine gute Sicht aus der Sicht des Spielers zu ermöglichen.
Endlich, wie immer, haben wir das Flair-Objekt des nächsten Monats fertig gestellt. Viel Spaß!
UI
Das UI-Team hat schon einige Frühjahrsputzarbeiten durchgeführt (nie zu spät!). Wir haben an einem gründlichen Durchlauf des neuen holotable Designflows gearbeitet, um die gesamte Benutzerfreundlichkeit zu verbessern und die verschiedenen Bildschirme zu vereinheitlichen. Gleiches gilt für die Simpod-Schnittstelle (auch bekannt als Electronic Access). Wir haben auch viele Aufgaben mit niedriger Priorität bereinigt, die sich langsam und stetig angesammelt haben.
Bis zum nächsten Mal, Bürger!
Hallo Bürger!
Ein weiterer Monat, ein weiteres Update. In den letzten Monaten ist einiges passiert. Im Moment haben wir drei Gäste von CiG (Sean Tracy, Steve Bender und Jason Hutchins), die uns in Denver besuchen und uns helfen, wo immer sie können. Wir konzentrieren uns derzeit darauf, die Kernbewegung so solide wie möglich zu gestalten, während die Animationen in der ersten und dritten Person immer noch gut aussehen. Das ist keineswegs einfach, deshalb haben wir die zusätzlichen Verstärkungen! Weitere Updates zum FPS-Modul Push finden Sie im wöchentlichen Star Marine Update.
Ingenieurwesen
Im Laufe des letzten Monats konzentrierte sich das Engineering vor allem auf die Kernbewegung und das Start-/Stopp-/Steuerungs-/Steuerungssystem. Dies war eine enge Zusammenarbeit mit Animatoren und Designern, die alle Edge Cases ausarbeitete und versuchte, die absolut beste Balance zwischen Steuerreaktion und Animationsqualität zu finden. Alles muss dann funktionieren und für den 1st und 3rd Person Modus poliert werden. Zusätzlich zur zentralen Fortbewegung haben sie auch Regeln für Star Marine erstellt, so dass sie Statistiken auf die gleiche Weise berichtet wie Arena Commander für Ranglisten und den Aufbau von REC. Schließlich wurden 5 verschiedene Bewegungsgeschwindigkeiten implementiert. Dies macht das Bewegen mit einer Steuerung sehr flüssig und variabel, je nachdem, wie viel Neigung auf den Stick aufgebracht wird.
Animation
Die Animatoren waren alle darauf ausgerichtet, mit Starts/Stopps/Jukes alles so gut wie möglich aussehen zu lassen. Dabei handelte es sich meist um eine sehr schnelle Feedbackschleife mit Steve Bender. Sein Feedback einholen, optimieren und die Ergebnisse zurücksenden, bis alle zufrieden sind. Es ist sicher eine Menge Arbeit, aber das Team hier leistet wirklich gute Arbeit und die Geschwindigkeit dieser Arbeit steigt fast täglich, nachdem die Prozesse geklärt sind.
Kunst
Das Kunstteam hat an der Optimierung aller Anlagenteile für das Gold Horizon Station Set gearbeitet, zusammen mit der Anpassung der Anlagen an die Metriken, die bei Foundry 42 verwendet werden. Das ist nicht gerade die interessanteste Arbeit, aber es ist etwas, das auf lange Sicht für das persistente Universum und die Staffel 42 getan werden muss.
Design
Das Designteam nimmt auf Wunsch von CiG zahlreiche Optimierungen am Gold Horizon Level vor. Dazu gehören einige Anpassungen an den Positionen der Munitions- und Energieplatzierung, das Entfernen einiger Türen und das Ändern des Verhaltens anderer durch die Ebene. Darüber hinaus optimieren sie auch die Sichtlinien im gesamten Level und machen einen Poliergang bei der Platzierung der Abdeckung.
Das ist alles, was ich diesen Monat für euch Jungs und Mädels habe. Bis zum nächsten Mal!
Hier ist, was wir in diesem letzten Monat hier oben in Montreal gemacht haben:
Jump Point Interview
Zunächst einmal hatte unser Team in diesem Monat die Möglichkeit, an einem Interview zu einer Ausgabe von Jump Point teilzunehmen. Dies gab uns die Möglichkeit, einige der Projekte, an denen wir für Star Citizen gearbeitet haben, zu diskutieren und ein wenig Licht darauf zu werfen, was als nächstes kommt. Vielen Dank an David Ladyman, der es uns ermöglicht hat, etwas mehr Details (und etwas informeller) über unseren Prozess zur Neugestaltung des globalen Erscheinungsbildes der Website zu erfahren.
Starmap
Diesen Monat haben wir das Hauptwerk für den Starmap-Viewer fertiggestellt, einschließlich Galaxie- und Systemansichten. In Bezug auf die Schnittstelle haben wir einige wesentliche Änderungen am HUD sowie an den Filteroptionen (Sensoren und Wärmenetz) vorgenommen.
Auf der Datenseite haben wir gute Fortschritte bei der Datenmodellierung für die kommende Galactapedia gemacht. Wir haben auch an unseren eigenen Verwaltungstools gearbeitet, damit wir Daten aus dem Star Citizen-Universum importieren können. Dies ermöglicht es, alle Daten der verschiedenen Himmelsobjekte bereits in einem Galactapedia-Format zu haben.
Auf der 3D-Front haben wir mit der Produktion der verschiedenen Assets begonnen, die im WebGL-Viewer angezeigt werden (Planet, Jump Point, Raumstation, etc.). Das ist sehr arbeitsintensiv und es ist das, was der Benutzer auf seinem Bildschirm sehen wird, und deshalb werden wir in den nächsten Monaten daran arbeiten.
Issue Council
Wie bereits beim letzten Mal berichtet, haben wir den Issue Council kontinuierlich weiterentwickelt, um sicherzustellen, dass er den Zeit- und Arbeitsaufwand für alle Beteiligten erheblich reduziert. Wir haben auch daran gearbeitet, sicherzustellen, dass es nicht leicht von großen Gruppen von Benutzern (z.B. Organisationen) beeinflusst werden kann. Wir haben neue Funktionen hinzugefügt, Layouts neu organisiert, Dinge von einer Seite zur anderen verschoben, Seiten entfernt und so weiter - so sehr, dass wir, als wir einen Schritt zurückgingen und es uns ansahen, merkten, dass die Benutzeroberfläche nicht mehr intuitiv war. Also versammelten wir das Team um ein großes Whiteboard und arbeiteten daran, dies zu beheben.
Das Kernupdate, das wir erarbeitet haben, war ein aktualisierter Ablauf für die Benutzer. Nach der Ankunft im Issue Council werden den Nutzern drei Möglichkeiten geboten, sich dem System zu nähern:
Tragen Sie dazu bei, indem Sie versuchen, Probleme zu replizieren und ungültige Tickets (Duplikate, Feature-Anfragen, schlecht geschriebene usw.) markieren. Priorisieren Sie die bestätigten Tickets, damit die Entwickler wissen, was für die Community wichtig ist. Durchsuchen Sie alle Tickets, die jemals erstellt wurden. Wir werden bald einige Entwürfe zum Teilen haben, aber um einen kleinen Einblick zu geben, hier ist ein Foto von einem der Whiteboard-Designs von Benoit.
Community Hub
Der Community-Hub hat seine letzte Phase erreicht, und unsere Entwickler haben daran gearbeitet, ihn den ganzen Monat über tatsächlich umzusetzen. Die wichtigste Aufgabe bei diesem spezifischen Projekt war die Einrichtung der Einreichungsabläufe. Diese ermöglichen es Ihnen, Bilder und Galerien Ihrer eigenen Kreationen hochzuladen, Ihre YouTube-Spielsitzungen einzubetten oder interessante Links zu melden, die Sie anderswo gefunden haben, was eine große technische Flexibilität von der Website selbst erfordert. Noch interessanter war, dass wir uns einige Zeit Zeit genommen haben, um Filter und Sortieralgorithmen zu entwickeln, die auf der Menge und Häufigkeit der geposteten Inhalte und deren Beliebtheit durch Upvotes und Kommentare basieren. Es ist immer eine spannende Herausforderung, herauszufinden, wie eine Website ihre eigenen Inhalte präsentiert, um sie so relevant und frisch wie möglich zu halten.
Moderationswerkzeuge
Ein weiteres Projekt, an dem wir gearbeitet haben und das kürzlich gestartet wurde, waren die neuen Moderationswerkzeuge für das spezielle Moderatorenteam der Website. Diese Tools geben ihnen nun mehr Einblick in markierte Inhalte, Wiederholungstäter und berüchtigte Rückfalltäter sowie eine schnellere Verwaltung des Forumszugangs. So können sie die Foren, Kommentare und Orgs noch reibungsloser und effizienter gestalten. Mit ihrer Hilfe haben wir eine Reihe von Tools entwickelt, die dann erweiterbar sind, um alle benutzergenerierten Inhalte abzudecken, einschließlich aller Aspekte des kommenden Community Hubs.
Der Konzeptverkauf dieses Monats war eine Kurzgeschichte, die die Genesis Starli vorstellte. wie sie von Meridian Transit betrieben werden. Diese schnelle Tränendrüse (siehe Postkarten) wurde von Star Citizen's eigenen Autoren geschrieben, und zusammen mit einigen ziemlich coolen Kunstwerken und Voiceovers vom Community-Team gab sie uns viel Raum, um Spaß mit der Post zu haben. Deshalb wurde es schnell zu einer der skriptlastigsten Seiten der Website, mit Minikomponenten wie dem Flight Board oder den flippenden Postkarten. Das Flight Board selbst basierte auf einem sehr frühen Konzept für den Events-Block auf der Homepage der Website, das uns sehr am Herzen lag, aber zu viel Wert auf die Browser legte. So waren wir wirklich froh, es trotzdem als Teil der Kurzgeschichte nutzen zu können.
Was du nicht gesehen hast.
Wie in jedem anderen Monat wurden auch unsere Programmierer mit Verbesserungen und Korrekturen beauftragt, die zum Glück unbemerkt geblieben sind. Im Juni dieses Jahres standen die von uns eingesetzten Zahlungsabwickler im Vordergrund: Amazon migrierte ihr gesamtes Zahlungssystem, an das wir uns anpassen mussten, und wechselte zu einer völlig neuen Art der Abonnementverwaltung. Eine andere, die ungenannt bleiben soll, hatte auch für uns einige interessante Überraschungen, auf die wir sehr schnell reagieren mussten. Wir haben uns auch einige Zeit damit beschäftigt, dem Kundendienstteam neue Werkzeuge zur Verfügung zu stellen, um ihm zu helfen, Problemfälle noch effizienter zu bearbeiten.
Es war ein weiterer arbeitsreicher Monat am Moon Collider, also lassen Sie uns direkt darauf eingehen:
Ingenieurwesen
Es ist ein bekanntes Sprichwort, dass kein Plan den Kontakt mit dem Feind überlebt, und ich denke, ein ebenso gültiges Sprichwort wäre kein Werkzeug den Kontakt mit den Designern! Egal, wie gut Sie ein neues Werkzeug entwerfen, in dem Moment, in dem die Designer damit spielen, werden Sie sehr schnell herausfinden, was verbessert werden muss. Letzten Monat gaben wir Designern die Möglichkeit, Verhaltensbäume mit einem Editor zu schreiben, der in DataForge, dem benutzerdefinierten Datenverwaltungstool von Star Citizen, integriert ist. Wir haben versucht, es so schnell wie möglich in die Hände des Designers zu bekommen, also hatten wir bereits eine anständige Todo-Liste mit Verbesserungen, von denen wir wussten, dass sie benötigt werden, aber ein paar Stunden echter Nutzung eines Tools durch einen Designer helfen immer zu klären, welche Probleme kleine Ärgernisse sind und welche häufig ihren Workflow unterbrechen oder sie unfähig machen, eine Aufgabe zu erledigen.
Wir haben diesen Monat einige Zeit damit verbracht, Feedback von Designern zu erhalten und ihre priorisierte Liste von Problemen mit dem neuen Editor durchzugehen. Dazu gehörten Dinge wie das Verfassen von mehr Dokumentation über die Funktionsweise bestimmter Funktionen, das Umbenennen, Rekategorisieren und Neueinfärben von BT-Knoten auf eine für einen Designer intuitivere Art und Weise und sogar das Verschieben bestimmter erweiterter Funktionen aus dem Standard-Workflow, so dass es etwas mühsamer ist, diese selten benötigten Funktionen zu verwenden, aber es macht die gemeinsamen Funktionen schlanker. Wir gehen davon aus, dass wir dieses Tool im nächsten Monat weiter verbessern werden, da das Feedback der Designer immer wieder einfließt.
Da die Designer nun mit DataForge an Verhaltensbäumen arbeiten, war es auch der perfekte Zeitpunkt, um unserem webbasierten Debugging-Tool Kythera Inspector eine Live-Ansicht des Verhaltensbaums hinzuzufügen. Dies ist eine Webseite, die Designer aufrufen können, die einen direkten Zugriff auf den Zustand der KI in ihrem Spiel ermöglicht, und wir wurden ständig um Funktionen erweitert, um das Debuggen der KI zu erleichtern. Bisher haben wir uns auf einige einfache Text-Debugging auf dem Bildschirm verlassen, um den aktuellen Zustand des Verhaltensbaums einer KI zu verstehen, und während dies für einen kleinen und einfachen Baum einigermaßen gut funktionierte, war es für größere Bäume viel weniger nützlich und auch in den bereitgestellten Informationen eingeschränkt.
Die neue Live-Ansicht in Inspektor ermöglicht es Designern, den Zustand des Verhaltensbaums einer beliebigen KI zu sehen, während das Spiel läuft. Wir haben einige neue Funktionen im nächsten Monat, die es ihnen ermöglichen werden, Konfigurationsfehler mit ihren Bäumen aufzuspüren, was in Kombination mit der bereits vorhandenen Fähigkeit, die Verhaltensbäume der KI aufzuzeichnen und wiederzugeben, Designern eine umfassende Suite von Werkzeugen zum Debuggen ihrer Verhaltensbäume bieten sollte.
Ein Problem, das wir schon seit einiger Zeit zu lösen versuchen, ist ein technisches Feature, das wir einen Zeichenkettenhash nennen. Dies ist etwas, das in Kythera eingebaut ist und es uns im Grunde erlaubt, jede beliebige Textzeichenkette im Code zur Kompilierungszeit in einen numerischen Bezeichner umzuwandeln. Dies macht es billig und effizient, Zeichenketten im Code zu übergeben und zu verwenden, ohne sich Sorgen zu machen, dass es teuer ist, Vergleiche durchzuführen, was normalerweise bei Zeichenketten der Fall ist. Und das bedeutet, dass Sie viel mehr beschreibenden Text in Ihrem Code haben können, als einfache Zahlen, was Code, der einfacher zu bearbeiten und zu debuggen ist, machen kann.
Da dies ein so nützliches Feature ist, wurde dem Rest der Star Citizen Codebasis eine ähnliche Version hinzugefügt. Was wir versucht haben herauszufinden, ist, wie man diese beiden verschiedenen Versionen von Zeichenketten-Hashes am besten vereinheitlicht, so dass wir die Kosten für die Konvertierung zwischen ihnen vermeiden können. Es gibt verschiedene Details, die es schwieriger machen, dieses Problem auf eine befriedigende Weise zu lösen, als es zunächst den Anschein hat, also haben wir Zeit damit verbracht, dies mit Programmierern in einigen der anderen Studios zu besprechen, und testen derzeit einige mögliche Lösungen, um sie auszuprobieren und zu sehen, ob sie in der Praxis Probleme verursachen.
Nun, lasst uns über Schiffe reden!
Letzten Monat haben wir die Funktion hinzugefügt, die es Schiffen ermöglicht, Splines zuverlässig zu verbinden. In diesem Monat haben wir begonnen, dieses Feature in Form von Retreat-Stunt-Splines sinnvoll zu nutzen. Stuntsplines sind Pfade, die von Designern in einer Ebene festgelegt werden und es der KI ermöglichen, durch enge Bereiche zu fliegen, in denen ihre Kollisionsvermeidung sie sonst daran hindern würde, zu gehen, wie z.B. durch einen Tunnel in einem Asteroiden oder Lücken zwischen Abschnitten einer Raumstation.
Eines der Hauptziele dieser Stuntsplines ist es, Möglichkeiten für Spieler zu schaffen, die KI auf interessanten und spannenden Wegen zu verfolgen. Wir haben sie dem KI-Rückzugsverhalten hinzugefügt, so dass, wenn sich ein KI-Schiff von einem Verfolger lösen will, wenn es in der Nähe einen Stuntspline gibt, es versuchen wird, ihn zu nutzen. Um die Dinge glaubwürdig zu halten, wird die KI nur dann einen Spline wählen, wenn er schnell darauf zugreifen kann, so dass sie keinen verwenden wird, wenn er eine größere Änderung der Geschwindigkeit oder Richtung erfordert, um zu ihm zu gelangen.
Wir können sie auch verwenden, um Elite-KI-Piloten von Neulingen zu unterscheiden, indem wir ein Fertigkeitsniveau an der Spline anbringen. So kann ein wirklich haariges Manöver als nur für die besten Piloten verfügbar markiert werden. Dies bedeutet auch, dass, wenn Sie gehen, um ein fliehendes Eliteschiff zu jagen, Sie sich in einer Jagd befinden können, die Sie nicht gut genug sind, um abzuschalten, und Sie müssen eine schnelle Entscheidung treffen, wie verrückt ein Pilot ist, den Sie bereit sind zu sein!
Sobald die Designer die Möglichkeit hatten, mit dieser Funktion zu arbeiten, planen wir, den Auswahlprozess der Verzahnung zu verfeinern, um eine gute Balance zu erhalten, damit sie nicht übermäßig oder ungenutzt genutzt werden. Es ist wichtig, dass die KI für einen Spieler, der mit einer Karte vertraut ist, nicht allzu vorhersehbar wird, aber andererseits kann es auch etwas sein, zu sehen, wie ein Schiff abbricht und zu dem Tunnel fährt, von dem man weiß, dass es viel Spaß macht, durch ihn zu fliegen.
Wie immer bei neuen Features, freuen wir uns darauf, dass dieser in die Hände von echten Spielern kommt und die coolen Geschichten hört, die daraus entstehen!
Grüße Bürger,
Wir sagen immer, dass es ein arbeitsreicher Monat für das Community-Team war, aber an dieser Stelle.... welcher Monat ist nicht arbeitsreich?
Wir waren diesen Monat sehr glücklich, den ersten Jahrestag von Around the Vers zu feiern! AtV war für uns ein interessantes Projekt; letztes Jahr gingen wir auf die Frage ein, wie sehr wir die Notwendigkeit fürchteten, den Hangar des Fan-Favoriten Wingman zu ersetzen.... und wir nahmen uns die Zeit, unsere Füße zu finden und herauszufinden, was wichtig war. Dank deines Feedbacks (und deiner Unterstützung!) sind wir stolz auf das, was aus der Show geworden ist.... und wir werden versuchen, sie weiter zu verbessern. Episode 50, die letzte Woche ausgestrahlt wurde, hatte ein besonders herausragendes Segment, in dem der Designer Randy Vasquez seinen Prozess zum Bau von Starliner-Innenräumen zeigte. Erwarten Sie, dass wir in Zukunft weitere Segmente wie diese sehen werden, da wir der Meinung waren, dass es unser bisher stärkstes Stück ist.
Wir haben auch das Community-Team gebeten, in den Foren interaktiver zu sein. Wir sind genauso gespannt auf die Veröffentlichung von Star Marine wie der Rest der Community, und wir werden unser Bestes tun, um da rauszukommen und nicht nur die Flagge zu zeigen, sondern unsere Antworten und Gedanken mit euch allen zu teilen. Ein Community-Manager kann nicht immer deine Fragen beantworten.... aber wir sind hier, um das zu besprechen, was wir können, und auch um deine Bedenken anzuhören und sicherzustellen, dass die Entwickler sie kennen. Noch besser ist, dass wir an einem Relaunch des Ask a Dev-Prozesses arbeiten, der hoffentlich zu einem System für die Beantwortung Ihrer Fragen durch die Experten führen wird.
Das ganze Team hatte auch einen großen Tag mit dem Verkauf des Genesis Starliner. Wir wollten vermitteln, wie viel Tiefe das Schiff hatte, und das gesamte Team arbeitete zusammen, um der Präsentation Teile hinzuzufügen, von denen wir dachten, sie würden die Community interessieren. Von Jared's Postkarten bis zu Ryans Sicherheitskarte wollten wir Ihnen mehr zeigen, als nur, wie groß die Waffen waren (und wenn wir ehrlich sind, sind die Waffen überhaupt nicht so groß.)
Schließlich sind wir sehr traurig, einen von uns zu verlieren: Chelsea Day, Manager des Customer Service Teams, hat die CIG verlassen, um den Standort zu wechseln. Chelsea war eine gute Freundin und eine großartige CS-Managerin; wir werden sie alle vermissen! Patrick Probst, den Sie vielleicht schon im Forum gesehen haben, wird die Position des CS-Managers in Großbritannien übernehmen. Also herzlichen Glückwunsch - wir wissen, dass Sie dem beispielhaften Chelsea-Set gerecht werden!
Der Sommer ist da (jedenfalls auf der Nordhalbkugel), aber wir sind nicht im Urlaub: Große Dinge passieren bei der CIG! Wenn man von innen betrachtet, ist es erfreulich zu sehen, dass die beweglichen Teile, die den Star Citizen ausmachen, zusammenkommen. Wichtige Teile der langjährig erprobten Technologie, wie große Weltkarten, kommen intern online und es herrscht ein Hauch von Spannung unter den Entwicklungsteams, da die Realität, dass vieles, was wir geplant haben und worauf wir hinarbeiten, endlich eintritt. Wir freuen uns darauf, unsere Fortschritte mit Ihnen zu teilen, was bedeutet, dass wir uns bemühen, nicht nur das Star Marine FPS-Modul herauszubringen, sondern auch mehr über Multicrew und die persistente Welt zu erfahren. Passt auf diesen Raum auf! Wie immer haben wir unsere Projektleiter gebeten, individuelle Berichte für die Community zusammenzustellen, damit Sie genau wissen, was jeder Teil des Unternehmens getan hat. Lies weiter!
Hey zusammen! Es war ein erstaunlicher Monat voller aufregender Arbeit hier im sonnigen Santa Monica. Wir lieben es, mit dir alles zu teilen, woran wir gearbeitet haben, also genieße es und lass es uns immer wissen, wenn du irgendwelche Fragen oder Gedanken hast!
Ingenieurwesen
Unser Ingenieurteam war diesen Monat sehr beschäftigt. Alles von der Datenspeicherbereinigung über die Erstellung des neuen Charakter-Materialsystems bis hin zu großen Weltneuheiten. Also lass uns reinhauen:
Wir haben einige frühe Implementierungen der Fahrzeugparameter vorgenommen, bei denen wir die Fahrzeuge vom Parsen einer Xml bei jedem Spawn bis zum Parsen einer einzelnen Xml und von da an damit zum Bau eines Fahrzeugs entladen haben. Auch der einzige Weg, wie wir ein Schiff bauen konnten, war, es zu spawnen und dann zu sehen, was es enthält. Jetzt können andere Systeme einfach die Parameter nachschlagen, um ein Schiff aufzubauen. Wir müssen nicht mehr jedes Schiff unter dem Hangar spawnen, was eine massive Veränderung war. Wir hatten auch viele Integrationsfehlerbehebungen für FPS & Arena Commander. Wir setzten die Arbeit am Radar 2.0-System fort, bei dem wir das System von der reinen Basisversion zu praktisch allem überführten, was die Designer auf dem HUD zeigen müssen. Die Backend-Arbeit ist gebaut, jetzt müssen wir HUD und andere Fahrzeugkomponenten ändern, um diese Objekte zu handhaben, damit die Designer verrückt werden können! Wir haben auch eine Menge Fahrzeugcode bereinigt, indem wir unbenutzten Code gelöscht haben, der viele der langsamen Bits beschleunigt hat, aber das wird ein laufender Prozess sein.
Die Benutzeroberfläche hat enorm hart an den anstehenden Schiffsdesigns und der Implementierung gearbeitet. Insbesondere die Glitch-Effekte und das Booten für die Vanduul. Wir überprüften einen Vorschlag für eine verbesserte Cockpit-Interaktion und begannen mit der Vorbereitung von HUD zur Unterstützung verschiedener Sitzaktionen und Rollen.
Wir haben einige Bereinigungen des Datenspeichers durchgeführt, doppelten Code entfernt, verschiedenen verteilten Code in einem Durchgang vereinheitlicht und mit der Vorbereitung für Multicrew Spawning/MP Hangars begonnen. Wir haben das Objekt-Spawnen vom Spieler-Spawnen getrennt, um die Hangar-Beladung in die Level-Ladephase zu verschieben.
Wir haben auch an einem mehrschichtigen Materialsystem gearbeitet. Das Ziel ist es, eine feste Bibliothek von Basismaterialien zu erhalten, die miteinander vermischt werden (bis zu 4 Schichten), um komplexere Materialien mit minimalen Draw Calls zu erstellen. Texturbibliothek und Core Shader-Funktionalität sind meist fertig und arbeiten nun an der Basismaterialbibliothek, die die Renderressourcen mit den Mischmaterialien überbrücken würde.
Auf der KI-Seite haben wir viele Schiffsfehler behoben, insbesondere in Bezug auf den Lotsen, den ein KI-Schiff erstellt und betreut. Wir haben auch ein wenig am Wingmen-Kommando "defend target" gearbeitet und einen KI-Schiffsaspekt geschaffen, der die Bedrohungen in der Nähe verfolgt, so dass eskortierende Schiffe wissen, was sie angreifen sollen.
Auf der Large World-Seite haben wir verschiedene Triggerbereichsprobleme in LW-Karten behoben, wie z.B. die Entfernung der +/- 16km-Grenze für alle Triggerbereiche und die Festlegung zusätzlicher Randbedingungen. Wir haben ein wenig Interface-Bereinigung für Matrix34 / Quat durchgeführt und die Voraussetzung geschaffen, dass der Rotationsanteil all dieser Primitive floaten kann. Wir haben auch die Positionsinformationsleiste und den GOTO-Positionsdialog korrigiert und die Bewegungsgeschwindigkeit der Kamera in der Sandbox beim Erstellen von LW-Karten erhöht. Schließlich haben wir das Laden von Thread-safe Texturen mit Thread-safe Shader Parsing und Thread-safe Shader Ressourcenerstellung fast abgeschlossen. Puh, wir hatten einen tollen Monat und freuen uns auf mehr!
Design
Das Designteam hier ist unglaublich beschäftigt mit all den kommenden Schiffen, Modi, Spielanforderungen und so weiter. Einer der größeren Schwerpunkte für uns war der Genesis Starliner. Wir wollten sichergehen, dass wir alles durchdacht haben, um bereit zu sein, dieses fantastische Schiff zu dir zu bringen. Wir hatten in diesem Monat viel Arbeit vor uns, wie z.B. die Erstellung des ersten Gameplay-Balance-Plans, der mögliche Updates von Statistiken, Features, Spielmodi, Hud, Kontrollen, Raketen usw. beinhaltet. Hier sind einige der detaillierten Details dieses Monats:
Wir haben ein Problem mit der RSI Constellation Andromeda behoben, bei dem die alte Hangar Ready Version den Hangar zum Absturz bringen würde. Hoppla! Wir haben auch den Haupteingang des Aufzugs von einer Tür auf einen Schalter umgestellt, um das Ein- und Aussteigen über verschiedene Türen zu ermöglichen, ohne die Animationszustände zurückzusetzen. Wir haben auch die obere und untere Revolverhandposition festgelegt. Außerdem haben wir die Triebwerke überholt, um den Flug der Constellation vorzubereiten.
Für den Scythe Dogfighter tauchen wir in ein Problem ein, bei dem das Multilight nicht in den Lichthafen geladen wurde und der Archetyp den Client zum Absturz brachte. Wir haben auch unnötige KI-Raumschiffe entfernt und die Scythe aktualisiert, um den Modifikationsblock "Scythe_Swarm" zu verwenden, um die Gesundheit der KI-Scythe anzupassen.
Bei der Hornet F7CM haben wir ein Problem behoben, bei dem einer der harten Punkte des Triebwerks falsch benannt wurde, wodurch verhindert wurde, dass das Triebwerk auf das Schiff geladen wird. Wir haben auch die gebundene Geometrie und das Gewichtstransferwerkzeug kombiniert, während die Refactoring-Kontrollen einiges an Design haben.
Im Mustang-Delta haben wir die Einbeziehung von Standard-Animationen entfernt, die kollidierend waren und Probleme verursachten (wie z.B. falsch platzierte Schraffuren und nicht abspielbare Open/Close-Animationen). Wir haben auch den AEGS Retaliator für den Ein- und Ausstieg aus dem Pilotensitz implementiert und die Innenräume aktualisiert, um die neuesten aus der Produktion zu verwenden. Das ist einiges davon, wie unser Monat verlaufen ist und ist bereit für den Monat Juli.
Kunst
Insgesamt war es ein sehr arbeitsreicher Monat für unser Kunstteam in Santa Monica. Insbesondere waren die Fahrzeugkünstler damit beschäftigt, sich auf den Merlin zu konzentrieren, der gerade seinen letzten Kunstpass durchlaufen hat und dem Design übergeben wurde, um den Flug vorzubereiten. Darüber hinaus hat unser Senior Vehicle Artist Paul Forgy die ersten Schritte unternommen, um den Bengal Carrier außen weiß in einer Box und in der Game Engine zu präsentieren. Ich kann es kaum erwarten, diese großen Schiffe zu sehen! Mit der neuen Schadenstechnologie, die online kommt, haben die Künstler von LA hart daran gearbeitet, sicherzustellen, dass die flugbereiten Schiffe das überarbeitete System unterstützen. Die Scythe ist eine der ersten und wurde für die volle Schadensunterstützung eingerichtet. Achten Sie darauf, dass Sie in naher Zukunft darauf achten. Das ist nicht das einzige Update für die Scythe. Das Cockpit des Schiffes wurde für den Menschenflug nachgerüstet. Erwarten Sie das bald in AC!
Neben unseren ATX-Kameraden hat das LA-Studio daran gearbeitet, Charaktere nicht nur für den FPS, sondern auch für Charaktere über alle Module hinweg neu zu gestalten. Omar Aweidah nähert sich der Fertigstellung des ersten Goldstandards, um die neue Charakter-Shader-Technologie von Multi-LayerBlend, geschrieben von Okka Kyaw, vollständig zu nutzen. Jetzt sind wir bereit, die visuelle Treue des Charakters zu erhöhen und den großen Sprung in die Zukunft der Charakterentwicklung für das Star Citizen-Universum zu wagen.
Apropos Charaktere, unser Produktionsdesigner für Charakterkonzepte, Rob McKinnon bringt unsere Konzeptentwicklung wirklich stark in Schwung. Wir machen große Fortschritte bei der Entwicklung von Looks für die Charaktere von Star Citizen. 3D-Skulpturen von Rob McKinnon und seinem Team haben uns unseren ersten 3D-Blick auf Marineuniformen gegeben. Ob Brückenbüro oder BDU, die Marines sehen erstklassig aus. Die Marine hat Tonnen von Rollen und Verantwortlichkeiten und wir haben jetzt ein Outfit für jeden von ihnen. Von Offizieren an Deck bis hin zu Ärzten auf Abruf sind die Uniformen der Marine scharf und bereit, mit der 3D-Produktion zu beginnen.
Bei all der Aufregung, den Meridian Transit zu fahren, haben wir dafür gesorgt, dass Sie nicht auf einen Drink verzichten müssen. Der Genesis Starliner hat nun die allerersten Konzeptentwürfe für Flugbegleiter. Außerdem wurde die Vanduul gerade viel härter mit neuen Bildern, die vom Konzeptteam erstellt wurden und neue Rüstungssets zeigen. Die Vanduul sehen jetzt gemeiner denn je aus. Unter der Rüstung wurde eine Revision durchgeführt, um zu versuchen, die Haut dieser Alien-Rasse zu finalisieren.
Und das war's für das Santa Monica Studio-Update für diesen Monat. Vielen Dank, dass du dir die Zeit genommen hast, dir die harte Arbeit des Teams anzusehen und die Entwicklung des Spiels zu unterstützen. Nichts davon wäre ohne deine weitere Unterstützung möglich und wir fühlen uns geehrt, dieses Spiel mit dir machen zu können. Wir schätzen Ihr Feedback und Ihre Gedanken, also halten Sie sie auf dem Laufenden.
Hallo zusammen!
Es war ein ungewöhnlich regnerischer und kühler Juni in Texas und wir haben es genossen. Wir haben diesen Monat eine Reihe von Besuchern aus anderen Studios empfangen und uns sehr auf eine Reihe von verschiedenen Produktionsprioritäten konzentriert. Wir haben an verschiedenen Fronten gute Fortschritte gemacht und haben noch viel mehr zu tun, um den harten Vorstoß bis zum Ende des Sommers zu bewältigen. Hier sind einige detaillierte Berichte von den Leitern der einzelnen Teams.
Hartnäckiges Universumsteam
Kunst
Diesen Monat verbrachte das PU Concept Art Team die meiste Zeit damit, Details zu den wichtigsten Features des Spiels zu erläutern. Ted Beargeon und Ken Fairclough fertigten Stücke, die Heldenrequisiten für die Landezone Nyx>Delamar>Levski definierten. Wir schickten Konzepte von Statuen und Großmaschinen an BHVR, um sie zur Modellierung zu bringen. Ebenso wurde einige Zeit damit verbracht, das Levski-Marktgebiet zu konkretisieren, um das Einkaufserlebnis dort zu definieren, da es anders sein wird als alles, was wir bisher gemacht haben. Megan Cheever verbrachte ihre Zeit in diesem Monat damit, Details zu vertiefen und gibt verschiedene Konzepte von Militärpersonal weiter. Sie half bei der Definition der Abzeichen, Medaillen und Materialien, die du im Endspiel sehen wirst. Megan hat auch die Charaktere der Flugbegleiterin konzipiert, die Sie diesen Monat im Starliner-Verkauf gesehen haben.
Unser PU-Umweltteam hat die letzten Detailpassagen auch für Levski ausgearbeitet. Lee Amarakoon und Emre Switzer haben VFX bzw. Lighting unterstützt. Levski fängt an, durch die Arbeit dieser Jungs richtig dunkel und düster auszusehen. Lee machte sich auch an die Überarbeitung des Customs Scanner-Effekts, den Sie letztes Jahr auf der CitizenCon gesehen haben. Unsere Environment Leads, Cort Soest und Patrick Thomas, haben mit BHVR zusammengearbeitet, um die Umwelt selbst zu optimieren und die letzten 10 Prozent fertigzustellen. Nächsten Monat sollte Levski eingepackt werden und bereit sein, irgendwo auf der Straße zu zeigen.
Die Landezone Stanton>ArcCorp>Area18 war auch in diesem Monat ein großer Schwerpunkt für uns. Die Umgebung wurde einigen Layoutänderungen unterzogen, um sie für die Veröffentlichung mit dem Sozialmodul zu optimieren. Mark Skelton hat zusammen mit Tony Zurovec daran gearbeitet, die Richtung für die Veränderungen zu bestimmen. Dieses Umfeld wird dadurch besser denn je aussehen.
Das Charakter-Team hier in Austin hat erst kürzlich den SATABall-Charakter und den Helm eingepackt, und es sieht fantastisch aus! Dies war einer der ersten Charaktere, die wir von Anfang bis Ende mit unserer neuen Next-Gen Character Pipeline aufgenommen haben, und die neuen Techniken haben sich als effektiv erwiesen, um stellare Charaktere für Star Citizen zu entwickeln. Wir freuen uns darauf, David Jennison und Billy Lords Werk sehr bald zu präsentieren!
Das Austin Animation Team hatte in diesem Monat in mehreren verschiedenen Bereichen des Projekts alle Hände voll zu tun, wie gewohnt. Wir werden diese Woche die Arbeit am neuen weiblichen Skelett abschließen, was es uns ermöglichen wird, endlich einige Damen ins Spiel zu bringen! Wir unterstützen Illfonic auch bei der Implementierung und dem Polieren von FPS-Animationen sowie beim Polieren von Animationen für das Social Module. Darüber hinaus arbeiten wir an der Standardisierung von Animationsvorlagen für Schiffscockpits und Enter/Exit-Sequenzen, um die Modellierungszeit für Schiffe in Zukunft zu verkürzen. Eine Sache, die Sie schon bald sehen sollten, sind die aktualisierten G-Force-Animationen im Cockpit. Jay Brushwood, Sean Tracy und Jeff Zhu haben fantastische Arbeit geleistet, um diese auf die nächste Stufe zu bringen.
Design
Diesen Monat verbrachte das PU Design Team einen Großteil seiner Zeit damit, Ideen zu sammeln und Designs für kommende Spielerberufe in der PU zu entwickeln. Mit Tonys Anleitung haben wir die ersten Entwürfe für die Berufe Kopfgeldjäger, Söldner und Piraterie überarbeitet. Wir haben auch Entwürfe für Schmuggler- und Such- und Rettungsberufe erstellt. Der große in diesem Monat war jedoch der von Tony Zurovec entworfene Personenverkehr. Wenn du noch keine Gelegenheit hattest, den Beitrag aus dem Starliner Verkauf zu lesen, solltest du ihn unbedingt HIER nachlesen.
Eine weitere Sache, die unsere Designer diesen Monat gemacht haben, ist das Testen des neuen Usable Editors. Der Usable Editor ist Teil von Tonys "Subsumption", einem friedlichen NPC-KI-System. Es ist der erste große Schritt zur Erreichung von Tonys Vision, wie NSCs mit Objekten in Star Citizen interagieren werden. Es war ein iterativer Prozess, bei dem die Designer mit dem Usable Editor herumspielen und Feedback geben, der Gameplay-Programmierer Tom Davies basierend auf diesem Feedback anpasst und wiederholt. Wir freuen uns, den Usable Editor zum ersten Mal in Aktion zu sehen und zu testen, wie weit wir seine Grenzen erweitern können.
Schließlich beginnen wir, in die ersten Entwürfe der nächsten Landezone am Planetenrand einzutauchen, die BHVR nach Levksi in Angriff nehmen soll. Wir konzentrieren uns auf eine weitere Landezone am Planetenrand in Stanton, die zwischen Hurston, MicroTech und Crusader hin und her geht. Welche Landezone möchtest du als nächstes online sehen?
Ingenieurwesen
Im Juni wurde der Juni mit der kontinuierlichen Weiterentwicklung vieler längerfristiger Aufgaben sowie der Planung und dem Support für unsere kommenden Releases und die Gamescom-Demo verbracht.
Es wurde viel Wert darauf gelegt, Wege zur Optimierung der Serverleistung zu finden, und wir haben in dieser Hinsicht große Fortschritte bei den kommenden Versionen von Arena Commander, FPS und Social Module gemacht. Wie im letzten Monat berichtet, ist unser Generic Instance Manager (GIM) in Arbeit und im Eingang. Das GIM wird ein großer Umbau unserer Party- und Matchmaking-Systeme sein, und es wird mehrere Iterationen durchlaufen, bis wir damit zufrieden sind. Diese erste Iteration wurde mit unserem QA-Team durchgeführt und sie waren nicht davor zurückgeschreckt, uns Fehler zu schicken. Wir haben uns schnell um sie gekümmert und sind dem, was später GIM v1.0 sein wird, immer näher gekommen. Wir freuen uns, den Punkt zu erreichen, an dem wir es mit Ihnen allen teilen können, und es ist ein mit Spannung erwartetes System hier bei CIG.
Bei Wyrmbyte sind sie nicht nur ein wichtiger Mitwirkender bei unserer Untersuchung zur Serveroptimierung, sondern auch tief in ihrem iPredictor-Code.... und arbeiten fleißig daran, die restlichen Knoten herauszuarbeiten. In der Zwischenzeit war unser Tool-Team sehr beschäftigt mit Bugs und Tool-Feature-Anfragen, um unserem Team bei der Entwicklung des Spiels zu helfen. Sie bekommen nie einen freien Moment, da es keinen Mangel an Werkzeuganforderungen gibt.... und sie liefern gerne! Wir haben auch einige Gameplay-Programmierer, die weiterhin an einigen Proof-of-Concept-Funktionsprototypen für einige unserer Berufe arbeiten. Es ist berauschend, die frühen Formulierungen dessen zu sehen, was am Ende als unsere Berufe im Persistent Universe enden wird.
Also ist es leider etwas kürzer als ein Bericht in diesem Monat. Es liegt jedoch nicht daran, dass jemand bei der Arbeit schläft, das Team ist meist auf langfristige Aufgaben ausgerichtet und hat große Fortschritte gemacht! Viele von ihnen hoffen, dass sie in den kommenden Monaten zu dir kommen werden.
Bleiben Sie dran!
Live-Betrieb
QA
In diesem Monat hat Star Citizen QA erfolgreich drei studioübergreifende FPS-Playtests mit Entwicklung durchgeführt. Tyler Witkin hat die Playtests hervorragend koordiniert und anschließend Feedback eingeholt.
Die Entwicklung der Automatisierung hat sich beschleunigt. Melissa Estrada und Tyler Witkin verwenden den Sandox-Editor und den Flussdiagramm-Editor, um Ebenen zu erstellen, die den so genannten Feature-Tester verwenden. Diese Stufen werden verwendet, um verschiedene schiffs- und FPS-bezogene Funktionstests zu automatisieren.
Dank des sehr informativen Feedbacks von Senior Technical Designer Rob Reininger haben wir unsere Editor-Tests deutlich verbessert, um mehr Tests in Bezug auf Werkzeuge und Leveldesign durchzuführen.
Die Tests des Sozialmoduls und der Planetenseite werden dank der Bemühungen von Todd Raffray fortgesetzt. Sobald ein System oder Werkzeug entwickelt wurde, stellt Todd sicher, dass es als Testfall in unseren umfassenden Planetside Tests hinzugefügt wird. Der neueste Zusatz ist der Usable Editor. Der Usable Editor wird verwendet, um NSCs die Möglichkeit zu geben, mit Objekten zu interagieren. Der Usable Editor ist ein großer Teil des gesamten Subsumtion (Peaceful NPC AI) Systems.
Jeffrey Pease stellt sicher, dass der General Instance Manager während seiner offiziellen Implementierung in Alpha 1.2.0 ordnungsgemäß getestet wird. Der General Instance Manager ist unser Revamp für die Backend-Lobby und die Matchmaking-Systeme. Jeffrey leitet auch eine Untersuchung zur Verhinderung potenzieller Hacks und Exploits und hat unseren Engineering-Leads, die nun einen Aktionsplan zur Lösung dieser Probleme haben, sehr wertvolle Informationen zur Verfügung gestellt.
Herzlichen Glückwunsch an Andrew Hesse, der in die Rolle des QA Lead für das Austin Studio gewechselt ist. Andrew hat eine erstaunliche Arbeit geleistet, indem er alle Aspekte des Spiels getestet hat und war eine große Hilfe für unsere Schiffsentwickler als unser ständiger Schiffsspezialist. Diesen Monat begrüßen wir unseren neuesten Mitarbeiter im QA-Team, Andrew Rexroth. Rex verfügt über umfangreiche QS-Erfahrung und ist bereits eine große Hilfe bei speziellen Star Marine Tests.
Im nächsten Monat werden wir unsere Tests von Alpha 1.2.0 fortsetzen und gleichzeitig Mehrspieler-Hangars, deutlich größere Spielplätze, das Multi-Crew-System und vieles mehr testen.
Spielunterstützung
Der Monat Juni für Game Support wurde hauptsächlich für das Design, die Überprüfung und den Aufbau von Infrastruktur und Prozessen aufgewendet, die unseren Geldgebern auf serviceweiter Ebene helfen werden.
Besonders hilfreich ist unser systemweites administratives Broadcast-Tool, das es uns ermöglicht, allen Spielern, die mit einem Live-Service verbunden sind, eine Kommunikationsmethode zur Verfügung zu stellen, die unerlässlich ist, um Sie während des Spielens mit aktuellen Informationen zu versorgen. Wir arbeiten auch daran, unsere aktuelle forumsbasierte Live-Service-Benachrichtigungsseite durch eine eigene Webseite zu ersetzen, die letztendlich eine Server-Statusseite für alle Umgebungen (Arena Commander, Star Marine, PTU, Patches, etc.) beinhalten wird und uns ein effektives Werkzeug an die Hand gibt, um den Zustand des Dienstes an alle Spieler zu kommunizieren.
Wir haben auch weiterhin geholfen, die Probleme von May's 1.1.3 Release zu lösen. Wir haben die Probleme der aktuellen Version identifiziert und kommuniziert und aktiv mit der Produktion zusammengearbeitet, um diese Probleme zu beheben, einschließlich einiger der Probleme mit dem Zustand von Raketen und Schiffsschäden, die wir gesehen haben.
Schließlich haben wir begonnen, Ideen und Designs für das, was wir brauchen werden, um unsere verschiedenen Umgebungen und insbesondere das Persistente Universum zu unterstützen, zu entwickeln. Die Unterstützung von Spielern hängt in der Regel von der Art des Spiels ab, aber Star Citizen hat alle drei (Singleplayer, Multiplayer und PU)! Wir haben angefangen, uns zu fragen: Welche technischen Ineffizienzen haben wir bei der Unterstützung unserer Spieler heute? Was wird das erwartete Verhalten innerhalb des Spiels sein, und was werden sie von uns als Dienstleistung verlangen? Wie managen wir die Vielzahl der versuchten Account-Übernahmen, die in jeder PU vorkommen, und welche Instrumente brauchen wir, damit sich die Spieler schützen können? Wie schaffen wir es, dass die Spieler in der Lage sind, auf den sekundären Graumarkt zu gehen, ohne ihn vollständig einzuschränken?
Wir haben heute keine Antworten auf all das, aber wir haben sie stark investiert. Dies sind wichtige Fragen, die man sich bei der Bildung einer Online-Community stellen muss, insbesondere der BDSSE!
IT/Betrieb
Der Juni war ein aufregender Monat für das IT-Team. Wir haben weiterhin Leistungsoptimierungen an unseren Build-Systemen vorgenommen, und während jede Verbesserung großen Stolz hervorruft, haben wir das Gefühl, dass wir an den Punkt kommen, an dem jede neue Verbesserung, obwohl sie wichtig ist, immer kleinere und kleinere Gewinne bringt. Nicht alle Gewinne werden jedoch von der Hardware kommen, so dass wir wieder eng mit einigen Mitgliedern des DevOps-Teams zusammenarbeiten, um die Größe der Daten, die wir verschieben, zu reduzieren und ebenso wichtig ist, die Anzahl der Datenbewegungen zu reduzieren. Eine der verbleibenden Herausforderungen ist unser Asset-Build-System. Dies sind die grafischen Assets, die für jeden Build gerendert werden müssen, und mit den Treuezielen, mit denen wir arbeiten, ist dies ein sehr großer Teil des Build-Prozesses. Diesen Monat haben wir mit der Arbeit begonnen, diesen Job in viele kleinere Jobs einzubauen, damit wir mehr von dieser Arbeit parallel ausführen können, um die gesamte Buildzeit für diesen Teil des Builds zu verkürzen. Das DevOps-Team verwaltet die Build-Systemlogik und das IT-Team liefert die Hardware für die Aufträge.
Zusätzlich zum Build-System-Tuning hat die IT diesen Monat einige zusätzliche Reisen unternommen. Paul aus Austin und Hassan aus Manchester reisten hin und her zu unserem Büro in Frankfurt und halfen bei der Planung der Logistik des Büroumzugs dieses Studios. Ein gutes Maß an Planung und Vorbereitung geht in einen solchen Umzug und alles liegt bisher im Zeitplan.
Sie haben alles von der Elektrik und Kühlung über IP-Adressen bis hin zu VPN-Tunneln abgewickelt. Aufgrund ihrer harten Arbeit, alles auf ein Wochenende abzustimmen, wird das Entwicklungsteam keine Ausfallzeiten erleben.
Dennis aus LA und Chris aus Austin entwickeln weiterhin kundenspezifische Konfigurationen für Tests, basierend auf dem Feedback, das wir aus den Foren erhalten. Wir liefern nicht mehr nur gemeldete Zahnräder an die Qualitätssicherung für einmalige Tests. Dennis und Chris bauen und rekonstruieren jetzt kundenspezifische Systeme, um die gemeldeten Systeme in Fällen, in denen wir glauben, dass Hardware ein wichtiger Faktor sein könnte, anzupassen. Außerdem haben sie in unseren Testlabors mit dem frühen Testen von Windows 10 begonnen.
Der Juni war ein aufregender und lohnender Monat für die IT, aber wir haben für Juli einige noch größere Dinge geplant.
Dev Ops
Der Juni wurde hauptsächlich von 3 Großprojekten für DevOps genutzt. Der neue Launcher, der neue Build-Server und unser Umweltprojekt "Phoenix".
Der neue Launcher wurde bereits in mehrere Codeversionen unterteilt, an denen gleichzeitig gearbeitet wird. Während der aktuelle öffentliche Launcher die Version 1.6 ist, befindet sich die Version 2.0 im Test mit dem Unternehmen und wird für die FPS-Playtests verwendet. Die Version 2.1 arbeitet derzeit an der Einführung für die nächste Woche und wird schnellere Downloads, kleinere inkrementelle Patches und einige Verbesserungen der Downloadgeschwindigkeit ermöglichen. Version 2.2 kommt gleich danach mit einer Reihe weiterer Funktionen, und an Version 3.0 wird gearbeitet, während der ganze Rest dieses Prozesses stattfindet. Version 3.0 ist eine komplette Überarbeitung der Benutzeroberfläche und sollte dem Endprodukt viel näher sein.
Der neue Build-Server steht kurz vor der Fertigstellung. Wir streben weiterhin ein Release für das Unternehmen Mitte Juli an, wobei die ersten Builds aus diesem System im September an die Öffentlichkeit gehen. Für die Spieler sollten sie bei diesem Wechsel überhaupt keinen Unterschied sehen. Für das Unternehmen und die Entwickler sollten die Verbesserungen durch dieses System jedoch enorm sein. Es sollte uns nicht nur ermöglichen, mehr Builds gleichzeitig auszuführen, was den Arbeitsdurchsatz erhöht, sondern auch die Zeit, die Entwickler auf den Build warten, reduziert, sondern auch die Gesamtgeschwindigkeit des Builds verringert. Derzeit dauert es 4 Stunden, um einen Build zu erstellen, und wir müssen etwa 6-8 Builds pro Tag erstellen, damit die Entwicklung voranschreitet. Wie du wahrscheinlich sehen kannst, ist dies mehr Zeit am Tag als wir haben. So werden Builds gesichert, übersprungen und die Arbeit verlangsamt. Der neue Build-Server wird es uns ermöglichen, 2-4 Builds gleichzeitig auszuführen und sollte die 4 Stunden reduzieren. Wir müssen noch genaue Messungen durchführen, um herauszufinden, wie schnell die Builds sein werden.
Wie Chris Robert in seinem Brief des Vorsitzenden erwähnt hat, haben wir an dem, was wir das dynamische Umgebungssystem "Phoenix" nennen, gearbeitet. Jedes Mal, wenn das Team einen neuen Build von Star Citizen startet, werden alle Daten, die die Server benötigen, automatisch auf Festplatten in Google kopiert; dies ist eine Momentaufnahme unserer Spieldaten. Diese Scheiben sind in zwei bis drei konzeptionelle Teile unterteilt: Basis-Image (das Betriebssystem und ein paar andere Dinge), Protokolle und Serverdaten (Code und Assets). Wenn wir eine Umgebung aufbauen, mounten wir Duplikate dieser Festplatten an jede Virtual Machine (VM), die wir aufspielen. Duplikate des Snapshots werden sehr schnell erstellt, etwa 45 Sekunden für 200 Gigabyte Daten. Wir haben einen Automatisierungscode geschrieben, um automatisch Befehle auf der VM auszuführen, um sie entsprechend dem Servertyp zu konfigurieren (Spiel, Matchmaking, Party, etc.). Dabei wird dem Server ein neuer DNS-Eintrag zugewiesen, der auf der Version der hochgeladenen Daten basiert. Wenn ein neuer Build erstellt wird und wir ihn in eine Umgebung verschieben müssen, lösen wir einen Befehl aus, der automatisch alle VMs herunterfährt, die Duplikate der Basis-Image- und Serverdatenplatte entfernt (Protokollplatten werden immer für die Fehlerbehebung aufbewahrt) und den Server mit den neuen Duplikaten neu startet, basierend auf dem neuen Snapshot und die Umgebung läuft und ist bereit für die neue Version.
Dieser gesamte Prozess dauert ca. 8 Minuten. Wenn wir eine QA-Umgebung, die auf diese Weise aufgebaut ist, zu einer PTU-Umgebung ausbauen wollen, senden wir einen Befehl an unsere Provisionierungsschicht und sie geht an Google, fordert mehr VMs an, erstellt mehr Festplattenduplikate, mountet diese Snapshots, führt Chefbefehle aus, um sie zu konfigurieren, fügt ihre DNS-Einträge hinzu und verbindet sie mit der vorhandenen Infrastruktur, die verwendet werden soll. Zu diesem Zeitpunkt haben wir eine PTU-Umgebung. Wir wiederholen diesen Prozess, um die Produktion aufzubauen. Jedes Mal, wenn wir eine Umgebung erweitern, dauert es etwa 8 bis 10 Minuten, je nach Art der Umgebung und den von uns benötigten Konfigurationen.
Der Nutzen dieser dynamischen Schöpfung und der Umwelterweiterung ist dreifach. Zunächst werden alle geänderten Konfigurationen, fehlgeleiteten Einstellungen oder fehlerhaften Prozesse vollständig entfernt, wenn die VMs mit den neuen Festplattenduplikaten neu erstellt werden. Alle Konfigurationsänderungen, die fortbestehen müssen, sollten auf der Chefebene vorgenommen werden. Zweitens können wir absolut sicherstellen, dass PTU und Produktion genau die gleichen Umgebungen sind, auf denen QA getestet wurde, so dass es keine seltsamen Unterschiede geben wird, die wir in QA nicht erkannt haben, wenn wir live gehen. Der dritte Vorteil ist einfach die Geschwindigkeit. Es ist viel schneller, Umgebungen während des Betriebs dynamisch zu erstellen, als jedes Mal Daten zu kopieren. Die letzten beiden Punkte sind eine ziemlich große Sache. Wenn unsere Erfahrung uns etwas gelehrt hat, dann ist es, dass eine einheitliche Testumgebung, die schnell eingeführt werden kann, von entscheidender Bedeutung ist, und dieses neue System ist ziemlich schnell. Es ist ein enormer Kraftmultiplikator für unsere Fähigkeit, unsere Testversionen schnell zu wiederholen, was bedeutet, dass QA und letztendlich unsere Geldgeber in der Lage sein werden, vielfältigere Tests schneller durchzuführen. Je genauer wir Versionen zu unserer Qualitätssicherung und zu unseren Geldgebern bekommen können, desto besser können wir das Spiel letztendlich gestalten. Juli dürfte ein sehr spannender Monat werden, in dem einige dieser Großprojekte aus der Entwicklung in die Produktion gehen.
Grüße Bürger,
Die Gießerei 42 ist unter Spannung und bereit, weiterhin hart zu arbeiten! Zwischen der Unterstützung des p-cap-Shootings in London, der Arbeit an der eigenständigen Staffel 42 und der Fortführung der Engineering-Aufgaben für den mehrköpfigen Arena Commander waren wir beschäftigt! Hier sind die Details von unseren Abteilungsleitern:
Animation
Wir haben mit der Arbeit begonnen, einige der systemischen Ai-Animationen für feindliche Aktionen aufzubrechen. Dazu gehören Dinge wie das Betreten und Einlaufen, um aus verschiedenen Blickwinkeln abzudecken. Reagieren auf Granaten und gehen aus dem Weg. Darüber hinaus hat das Team an der Verfeinerung einiger der Mechanismen gearbeitet, die derzeit im Spiel implementiert sind, um ein reaktionsschnelleres Gefühl zu erreichen und gleichzeitig die realistisch erfassten Bewegungsdaten zu erhalten. Wie immer sind wir für die Kunst- und Designteams hier in der Gießerei 42 für alle Ausblendmechaniken und Umweltanimationen da.
Ingenieurwesen
Zwei Bereiche, über die ich diesen Monat sprechen möchte und mit denen wir uns hier in Großbritannien stärker beschäftigen, sind die Benutzeroberfläche und die KI.
Auf der KI-Seite nehmen wir eine aktivere Rolle bei der Entwicklung ein und haben gemeinsam mit unseren Kollegen in Frankfurt und Moon Collider einen Großteil der Grundlagenarbeit geleistet, um unser neues CIGAI-System in Betrieb zu nehmen. Wir haben uns mit einem neuen Kommunikationssystem beschäftigt und wie wir es in Verbindung mit unserer aktuellen Dialoglogik nutzen können, um die Grundlagenarbeit der Warlord und Vixen KI-Charaktere des DFM-Überlebensmodus zu erweitern und das Cockpit-Audiosystem (alias Bitching Betty) intelligenter zu gestalten.
Wir haben auch einige der Funktionen von CryAI in unser System übernommen und dann so angepasst, dass sie besser zu unseren Anforderungen an Star Citizen passen. So vor kurzem hat das das Tactical Point System, das Dinge wie Cover beinhaltet, und das Group AI System, das eine bessere und einfachere Handhabung mehrerer KI-Objekte ermöglicht, besonders in den visuellen Gameplay-Skripten (oder dem Flow-Graphen, was immer Sie bevorzugen!).
Auf der Benutzeroberfläche arbeiten wir hier schon seit geraumer Zeit, haben aber in letzter Zeit begonnen, eine größere Verantwortung zu übernehmen und mehr von der Arbeit zu übernehmen. Wir haben das Team um einen neuen Künstler und einen neuen Ingenieur erweitert. Den neuen Ingenieur zu haben bedeutet, dass wir jetzt jemanden haben können, der sich ausschließlich darauf konzentriert, die Anforderungen an die Benutzeroberfläche der Staffel 42 zum Leben zu erwecken. Einige der vielen Features, die wir ihm in den Weg gelegt haben, sind die Entwicklung der Schnittstelle für das taktische Visier und die Plünderung. Diese erfordern verschiedene Augmented-Reality-Overlays und Post-Process-Effekte, um Menschen und Objekte hervorzuheben und dem Spieler zusätzliche Informationen über die Welt um ihn herum zu geben. Wir haben auch eine Iteration auf den Visieranzeigen für Star Marine durchgeführt, da jeder Helmtyp sein eigenes, einzigartiges Aussehen und Gefühl haben wird, das sein eigenes, individuelles UI-Setup erfordert.
Unser neuer Künstler arbeitet derzeit am Look-dev' der Schiffshersteller, parallel dazu wird der Schiffs-UI-Code viel Planungsarbeit geleistet, um mit Multi-Crew-Schiffen und all den Herausforderungen, die uns auf den Weg bringen, umgehen zu können, wie z.B. die Möglichkeit, dass ein Kapitän verschiedene Kontrollen an den Co-Piloten oder Turmschützen delegieren (oder ausschließen) kann. Es wird auch geplant, dass die Spieler ihr Display individuell gestalten können. setzt ihre Cockpits ein und gibt ihnen die Möglichkeit, verschiedene Ausgaben auf verschiedene Displays zu übertragen. All diese Planung ist, weil, um die von uns benötigte Funktionalität zu unterstützen, die zugrunde liegende Struktur, auf der der UI-Code sitzt, ein wenig einen Refactor benötigen wird. Wir haben bereits viel von der fest programmierten Einrichtung der Benutzeroberfläche genommen und sie viel datengesteuerter gemacht (mit unserem DataForge-Tool), aber wir haben sie auch geändert, um sie viel flexibler zu machen, so dass jeder Teil des HUD an alles andere im Spiel angehängt werden kann, was die Benutzeroberfläche aufnehmen kann. So wird es plötzlich einfach, das Radar von Ihrem Visier auf eines Ihrer Cockpit-Displays zu bewegen. Das wird fantastisch!
Grafiken
In diesem Monat hat sich das britische Grafikteam auf mehrere Bereiche parallel konzentriert. Die Arbeit an der Mesh-Merging-Technologie geht weiter und wird in größeren Umgebungen wie Asteroidenfeldern getestet, um sicherzustellen, dass sie mit einer beliebigen Anzahl von Objekten umgehen kann. Dies kommt gut an und wird sehr bald serienreif sein und bald in öffentlichen Veröffentlichungen eingesetzt werden, um Ihnen eine bessere Leistung auf neuen Ebenen zu bieten.
Wir haben einen neuen Senior-Programmierer, der an der volumetrischen Gaswolkenwiedergabe arbeitet, dichte Wolken und weichen Nebel mit anisotroper Beleuchtung untersucht (der helle Rand, den man am Rande von Wolken bekommt). Dies wird eine sehr langfristige Aufgabe sein, da sie sehr komplex ist, aber etwas ist, das wir in unserem Spiel wirklich vorantreiben wollen. Wir haben uns auch mit der Technologie der Gesichtsanimation beschäftigt und verschiedene Setups profiliert, um zu sehen, wie weit wir die Technologie vorantreiben können, während wir eine angemessene Bildrate beibehalten. Dazu gehören das Ausprobieren verschiedener Polygonzahlen, die Anzahl der Verbindungen/Knochen im Gesicht und die Anzahl der Posen/Mischformen, die jeder Charakter verwenden kann. In diesem Zusammenhang haben wir auch untersucht, was wir tun können, um das Rendern unserer Gesichter voranzutreiben, was keine leichte Aufgabe ist, wenn man auch viele Charaktere auf dem Bildschirm unterstützen muss. Wir werden hoffentlich nächsten Monat mit der R'n'D. beginnen und freuen uns darauf, das Ergebnis zu teilen (gut oder schlecht!)."
Design
Der Juni war hier ein arbeitsreicher Monat für das Design mit GamesCom. Wir sind immer noch mit voller Wucht bei Squadron 42 und unterstützen das Performance Capture Shooting mit last minute Level Optimierungen auf dem Studiogelände, damit es so fantastisch wie möglich aussieht. Alle Ebenen sehen mehr und mehr poliert aus mit einem stetigen Strom von großartig aussehenden Gebäudefliesen, die von unserem Umweltteam stammen und so lange wiederholt werden, bis sie fantastisch aussehen, während sie es den Leveldesignern dennoch ermöglichen, die Umgebungen glaubhaft zu gestalten.
Wir hatten diesen Monat ein internes "Show-and-Tell", da viele der neuen Mitarbeiter die volle Tiefe des Plans für Star Citizen noch nicht gesehen hatten, und es ist sicher zu sagen, dass es fantastisch gut gelaufen ist, mit vielen Kiefern, die das Staunen in der Tiefe des Spiels verloren haben. Es war großartig zu sehen, wie viel Arbeit in so kurzer Zeit tatsächlich geleistet wurde.
Das technische Designteam ist gewachsen und deckt nun Aufgaben ab, von der Ausbalancierung der FPS-Waffen bis hin zur Inbetriebnahme der Vanduul-Flotte im Motor, von Großschiffen bis hin zu Jägern.
Das Arena Commander Team hat nun den "Large-World"-Code vom Engineering-Team erhalten und beginnt zu erkennen, was in Bezug auf die Größe des Universums erreicht werden kann, genug um zu sagen, dass Sie die Früchte ihrer Arbeit bald sehen sollten.
Die Systemdesigner haben die Spezifikation für die "Multifunktionsdisplays" in den Cockpits fertiggestellt, so dass die Funktionalität auf alle Schiffe ausgedehnt werden kann und vom Einmannschiff bis zum größeren Großschiff vollständig skalierbar ist. Dies ist eine weitere unserer dringenden Aufgaben für GamesCom und wird hoffentlich in Kürze näher erläutert.
Wir versuchen auch, eine erste Implementierung von "Quantum Jumping" vorzubereiten, um eine schnellere Navigation durch die neue "large-world"-Technologie zu ermöglichen, die sehr vielversprechend ist.
Alles in allem ein großer Monat für uns, aber ich habe das Gefühl, dass wir in den nächsten Monaten viel beschäftigter werden. Vielleicht ist es an der Zeit, bald eine Hängematte im Büro aufzustellen. Vielen Dank an alle wie immer.
Kunst
Konzeptkunst
Biggies in diesem Monat waren das Update der Bengalbrücke und der Mining Bot, weitere Arbeiten an der Behring Ballistic Flinte, dem Transportschiff Xi'an, der Vanduul-Flotte und der weiteren Definition des Requisitenkonzepts, um die Shubin-Minenbasis und einige Piratenbasen, die für die Sq42-Handlung benötigt werden (keine Spoiler!), zu erweitern.
Schiffe
Der Vergelter wurde in diesem Monat daran gearbeitet, ihn weiterhin flugbereit zu machen - aufregende Zeiten! Argo RUV erreicht die finale Kunst (mit Ausnahme des Pod, das für die Filmkunst überarbeitet werden muss), der Idris sieht stellenweise sehr gut aus, kann es kaum erwarten, etwas davon zu enthüllen. Cutlass startete seine neue Greybox unter Berücksichtigung von Designrevisionen, Mining-Bot geht in die Textur- und Materialphase, Starfarer - langsamer als wir es gerne hätten, es ist eine Frage der Ressourcen, und wir brauchen mehr talentierte Leute, um dieses Schiff so komplex wie möglich zu bauen. Die Bengal Bridge wird beginnen, sobald die Konzepte unterzeichnet sind.
Umwelt Kunst
Ein kurzes Update diesen Monat, da vieles von dem, was wir getan haben, vorerst geheim gehalten werden muss. Die Fortschritte in unserer VS-Umgebung mit Hangars, Kontrollräumen, Korridoren, Luftschleusen und Außenlandeplätzen, die alle nahtlos durchquert werden können, gehen weiter. Hoffentlich können wir euch einige der wirklich coolen Dinge zeigen, an denen wir in nicht allzu ferner Zukunft gearbeitet haben, also bleibt dran!
Requisiten
Wir bereiten eine klare Dokumentation für das Outsourcing vor, wählen uns mit den Techniken ein, die für Materialien benötigt werden, die uns die meisten Probleme bereiten, und dann, nächsten Monat, sollten wir loslegen.
VFX
Das VFX-Team hat hart daran gearbeitet, mehr Schiffe "flugbereit" zu machen - dazu gehören Effekte für Triebwerke, Waffen und Schäden. Insbesondere die Effekte der Scythe sehen ziemlich knallhart aus! Wir haben auch weiterhin an den Umwelteffekten - sowohl im Innen- als auch im Außenbereich - für den Vertikalschnitt gearbeitet. Wir begannen uns auch auf Star Marine's Waffen-VFX zu konzentrieren, um sicherzustellen, dass sie der Gesamtqualität der Level, Charaktere und natürlich der Waffen entsprechen. Wirklich aufregende Zeiten, um ein VFX-Künstler in der Foundry 42 zu sein!
Audio
Hey zusammen! Dieser CIG Audio Community-Bericht könnte sich ein wenig schlängeln, es ist viel los, aber ich denke, das sollte die meisten interessanten Teile abdecken.
Erstens, Wise. Wir sind fast da, was unsere Masse an Asset Conversion/Reengineering betrifft, zumindest ist das Ende in Sicht. Also haben Stefan, Darren und ich einige Zeit darüber nachgedacht, wie man die Dinge einrichtet, damit wir das Spiel gut mischen können. Unser Spiel ist im Gange und wird natürlich ständig überarbeitet, so dass die Strategie, die wir verfolgen müssen, nicht typisch für einen One-Shot-Release Titel ist. Wir denken, dass wir die Grundlage dafür haben, was uns gut dienen sollte, und wir ändern die Projektstruktur, um dies zu berücksichtigen.
Auf der Seite der Audiotechnik ist viel davon immer noch die Sicherstellung, dass Dinge, die früher funktionierten, wieder funktionierten; und das Ausbügeln von noch vorhandenen auftretenden Bugs/Foibles. Eine gewisse Ironie dessen, was wir tun, ist, dass wir umso mehr zum Problem beitragen, dass zu viele Sounds gleichzeitig abgespielt oder auf einer bestimmten Ebene bearbeitet werden, je mehr wir einzelne Sounds in allen möglichen Systemen zum Einsatz bringen. Wwise hat einige Möglichkeiten, mit dieser Situation umzugehen, aber das Ideal ist, sicherzustellen, dass Wwise sich nicht in Verarbeitungselementen verfängt, die außerhalb des Interessenbereichs des Spielers liegen. Im Kern, wenn etwas zu weit weg ist, um gehört zu werden, dann bringen wir es in einen Schwebezustand, wenn es um Audio geht, aber nur in dem Maße, wie wir es brauchen, damit es, wenn es wieder zum Leben erwacht, wie erwartet funktioniert. Es gibt alle möglichen Dinge, die dabei zu berücksichtigen sind, aber genau hier sind wir im Moment in Bezug auf die Kern-Audiotechnik. Es ist nicht glamourös, ich weiß, aber es wird die Dinge am Laufen halten, wenn wir das früher oder später richtig machen.
Wir haben ein paar neue Schiffe, von denen eines, an dem Darren viel gearbeitet hat. Dies musste auch für seinen Schiffscomputer neu aufgenommen werden, und er hat sich den UI-Aspekt angesehen, Sounds entworfen und gesehen, wie man sie am besten einbezieht. So viel Spieloberfläche in diesen Tagen basiert irgendwie in Flash und das kann problematisch für die Implementierung von Sound in einer Weise sein, dass wir leicht iterieren können. Während wir das tun, überlegen wir uns also, wie wir diese Pipeline verbessern können.
Übrigens, was den Origin-Schiffscomputer betrifft, halte ich meine Hände hoch und gebe zu, dass ich es versäumt habe, die bisherige Essenz dessen zu erfassen, was den Schiffscomputer für die Origin-Modelle so großartig gemacht hat. Im Grunde genommen haben wir auf Sie gehört und das Feedback, das Sie zu dem neuen gegeben haben, aufgenommen - und ich bin fest entschlossen, dass wir dieses zurückgewinnen werden. Ich bin damit nicht zufrieden und das wird behoben!
Persistentes Universum. Wir können noch nicht allzu viel darüber sagen, aber wir unterstützen die Umweltaudiosignale dafür kontinuierlich.
FPS. So viel davon ist in Wwise gebunden, es gab viele neue Inhalte, die für FPS in Bezug auf Waffen, Charakter Foley und Dialog benötigt wurden, und das kommt gut voran. Wir bekommen auch einen Haufen neuer Musikinhalte für FPS. So haben wir einen Workflow ausprobiert, in dem unser Komponist Pedro Macedo Camacho von seinem Studio in Wwise aus arbeitet, und wir importieren das, was er von seiner Musik aufbaut, in Wwise an unserem Ende. Es ist in logistischer Hinsicht nicht praktikabel, Zugang zu unserem eigenen Wwise Projekt zu gewähren (das ständig wächst), so dass sich das Testen dieses Workflows, bei dem er uns eine Projektdatei übergibt, als sehr wertvoll erwiesen hat.
Es war eigentlich überraschend einfach, seine Workunits in unser Wwise Projekt zu importieren, und ließ mich denken, dass dies ein Weg für diejenigen unserer Modding-Community sein könnte, die ihre Mods/Materialien in Star Citizen importieren möchten. Neue Assets könnten von Moddern innerhalb von Wwise produziert werden, die dann an uns zur Integration in das Wwise Projekt weitergeleitet werden, so dass wir an solide Banken exportieren usw. und die Event-Trigger zur Verwendung an Sie zurückgeben. Es mag auf den ersten Blick etwas unhandlich erscheinen, aber ich denke, dass die Zusammenarbeit mit der Modding-Community der richtige Weg ist, um ein qualitativ hochwertiges Erlebnis zu gewährleisten, und ich würde das gerne ausprobieren.
Arena Commander (oder Hundekampfmodul); eine ganze Reihe von Materialien wurden konvertiert oder einige Fälle vollständig neu erstellt, um besser als zuvor zu funktionieren. Als Audio Director kann ich im Moment nicht oft viel Sound Design machen, was natürlich etwas schade ist, da es das ist, was ich bin, in meinem Kern. Es war also so gut, dass ich in der Lage war, irgendwann für die Arbeit an einigen Schiffsantrieben zu passen und in materieller Hinsicht zu einem Schubdüsen-Design beizutragen! Luke hat das, was ich getan habe, genommen und es auch ein wenig repariert, er ist sehr in den Raumschiff-Audioaspekt unseres Spiels verliebt, so dass es für ihn beruhigend war, meine Implementierung zu reparieren. Im Allgemeinen nimmt viel von diesem Material Zeit für alle unsere Sound-Designer in Anspruch, denn es ist der Löwenanteil von Star Citizen, im Moment gibt es einfach viel zu tun, aber wir schnitzen es gut durch.
Re: Dialogunterstützung für die Staffel 42. Unser Dialogue Superman (kein offizieller Titel) Bob Rissolo war in London immer noch hart dabei. Es geht bald zu Ende, zumindest für den Moment, was bedeutet, dass er hier im Haus dauerhaft in die Gießerei 42 umziehen wird. Ein großer Schritt für ihn, wir sind immer noch sehr dankbar, dass er das sonnige San Diego gegen das mehr, nun, variable Klima von Manchester eintauscht!
Was unsere Tonstudios betrifft. Wenn Sie dies lesen, werden wir unsere neuen Türen für diese Türen installiert haben. Ich weiß, Türen scheinen eine so offensichtliche Sache zu sein, und das sind sie natürlich, wenn man versucht, den Rest des Studios nicht mit FPS-Gun-Soundeffekten, Explosionen und dergleichen zu überfallen. Aber wir haben eine Weile darauf gewartet, dass ein bestimmter Satz Türen hergestellt wird, wir waren einfach am falschen Ende einiger herstellerseitiger Produktionsprobleme, bei denen sie jeweils eine andere Farbe haben. Ich weiß, dass das leichtfertig erscheint, aber wenn man eine Reihe von isolierten Zimmern hat und aus einer anderen Disziplin kommt, spart man Zeit, um jemanden in das "Orangetonstudio" leiten zu können, anstatt einen Raum festzulegen, wer da sein könnte oder nicht. Das bedeutet auch, dass wir Räume bis zu einem gewissen Grad tauschen können. Mein eigener Raum wird ein Referenzraum für den Rest von CIG Audio sein, um zum Beispiel unseren Surround-Mix zu testen.
Im Moment sind Werkzeugverbesserungen etwas, das wir in Betracht ziehen. Je besser unsere Werkzeuge, desto einfacher ist es für uns, die Dinge ständig zu verbessern. Wwise ist ein ereignisbasiertes System und ist auf externe Ereignisse in irgendeiner Form angewiesen, um Sounds auf bestimmte Weise auszulösen. Zum Beispiel wollen wir bestimmte One-Shot-Sounds auslösen, wenn ein Triebwerk von Nullschub auf Vollschub umschaltet, zusätzlich zu dem, was wir für Triebwerke im Allgemeinen auslösen. Und dann lösen Sie verschiedene One-Shot-Ereignisse aus, wenn das gleiche Triebwerk vom vollen Schub zurück zum Nullschub übergeht. Das ist eigentlich etwas, das in der Box knifflig ist, da die Box in diesem Fall Wise ist, also wollen wir diese Events leichter als Sounddesigner und nicht als Programmierer einrichten können, also gibt es ein ganzes Toolset, das wir für die Definition von Logik in Betracht ziehen. Dies ist nur eines von vielen Werkzeugen, an denen wir einen echten Bedarf erkennen können.
Wir arrangieren, zurück nach Pinewood zu gehen, um eine ganze Reihe von Nötigungselementen für die Schiffe aufzunehmen. Sie erinnern sich vielleicht, dass sie mit uns an Foley für FPS gearbeitet haben. Es gibt eine neue Bibliothek mit dieser Art von klapperndem, knochenschüttelndem Material, das wir uns auch ansehen (man kann nie genug Quelle haben), aber wir wollen auch sicherstellen, dass unsere Sachen etwas individueller auf unsere Bedürfnisse zugeschnitten sind. Dafür werden wir die Butt-kickers niedermachen, ganz sicher.
Ich bin sicher, dass es noch mehr Dinge gibt, die ich von diesem Update verpasst habe, zögere nicht, uns mehr über den Ask A Dev-Teil der Community-Foren zu fragen, und wir werden weiterhin unser Bestes tun, um zu antworten. Danke fürs Zuhören!
QA
UK QA musste unsere Bemühungen in diesem Monat aufteilen, um sich mit den bevorstehenden wichtigen Ereignissen und Veröffentlichungen zu befassen. Star Marine (das FPS-Modul) und die Vorbereitung auf die Gamescom sind für die nahe Zukunft geplant, und die Tests der Staffel 42 laufen wie gewohnt weiter.
Star Marine hat sich sehr stark darauf konzentriert, wichtige Multiplayer-Bugs auszulöschen und zu versuchen, allgemeine Polarfehler zu finden. Glenn Kneale aus Großbritannien und Tyler Witkin von ATX QA haben zusammengearbeitet, um sicherzustellen, dass dieser Spielmodus gründlich getestet wird. Es gab eine Menge Cross-Studio-Stresstests, um sicherzustellen, dass es nach der Veröffentlichung stabil sein sollte.
Wir konzentrieren uns ganz besonders darauf, die Teile des Spiels zu testen, die auf der GamesCom gezeigt werden. Leider kann dort nicht allzu viel erwähnt werden, aber wir sind alle sehr gespannt, wie das, was derzeit gezeigt werden soll, ankommt.
Schließlich erhält Staffel 42 mehr Testzeit, die ihr gewidmet ist, während das Spiel voranschreitet, müssen wir sicherstellen, dass die neuen Mechaniken vorhanden sind und Alpha-Level-Rundgänge abgeschlossen werden können. Wir haben auch einige Zeit damit verbracht, etwas mehr Dokumentation zu erstellen, um unsere aktuellen Pläne zur Erweiterung der Tests auf S42 zu berücksichtigen.
Steven Brennon hat weiterhin Feedback von euch gesammelt und dafür gesorgt, dass es angemessen zusammengestellt und an die relevanten Personen geschickt wird.
Leider werden wir auch Chris "Chill" Hill am Ende des Monats verlieren. Wir wünschen ihm alles Gute, denn er ist einfach fantastisch, seit er letztes Jahr zu uns kam, aber wir freuen uns darauf, Steve Brennon zu einem Ersatz-Lead auszubilden.
Der Juni war ein arbeitsreicher Monat in allen Disziplinen, und das Team entwickelt sich dynamisch. Wir haben unsere neuen Büroräume weiter geplant, alles ist vorbereitet, um die Schlüssel zu unserem neuen festen Büro am 1. Juli zu bekommen. Wir werden sicherstellen, dass wir den neuen Standort mit allen teilen, falls jemand vorbeikommen und Hallo sagen möchte, natürlich mit Vorankündigung.
Ingenieurwesen
Im Juni implementierte Frankfurt Engineering in der Hauptcodebasis einige wichtige Elemente, die für diesen Monat geplant waren. Wie im letzten Monatsbericht erwähnt, waren die Große Welt (Verschiebung der Codebasis auf 64-Bit-Koordinaten), Camera Relative (Rendering-Koordinaten relativ zur Kamera, wodurch die Rendering-Galaxie ohne Genauigkeitsverlust möglich ist), Zone System (das neue räumliche Verteilungsschema von Star Citizen, das die Kryomaschine Octree ersetzt) nahe an der Star Citizen-Code-Mainline und wurden nun eingesetzt und werden bald ihren Weg in die verschiedenen Star Citizen-Spielmodule finden.
Die Integration relevanter CryEngine 3.7 SDK-Teile, kombiniert mit unseren neuen Änderungen, wird während der Erstellung in unsere Codebasis implementiert. Zusätzlich wurde in diesem Monat ein großer Aufwand für die Unterstützung von mehrköpfigen Fahrzeugschiffen unternommen: Lokales Physikgitter, Physik-Debugger, Entitäten und Prefabs, Unterstützung für neue 3D-VisArea-Formen, all dies in Kombination mit dem Zonensystem, werden im Rahmen des Betriebs beweglicher Schiffe bearbeitet. Unter anderem hat der Multi-Crew-Entwicklungsprozess einige Fehler und Fehlfunktionalitäten offengelegt, die seit Jahren in der CryEngine Codebasis leben....
Wir haben weiter an Optimierungen, verbesserten Speicherformaten, Fehlerbehebung, Bereinigung und allgemeiner Motorunterstützung für andere CIG-Studios gearbeitet.
KI
Im Juni konzentrierte sich das KI-Entwicklungsteam hauptsächlich auf die Basissysteme, die der menschliche Charakter benötigt, um durch die gesamte Spielwelt zu navigieren.
Wir haben den ersten Durchgang zur Integration des CryEngine MNM Navigationssystems und des multithreaded MNM Pathfinders abgeschlossen. Wir haben auch den ersten Durchlauf zur Anbindung des CryEngine Movement Systems an das aktuelle Verhaltensbaumsystem abgeschlossen. Das Bewegungssystem kümmert sich um die Analyse eines vom MNM Pathfollower zurückgegebenen Pfades und erstellt einen Plan, wie die Bewegung ausgeführt werden soll.
Stellen wir uns eine Figur vor, die sich in eine Deckungsposition bewegen muss, der NSC muss einem Weg bis zur Deckungsstelle folgen und dann die richtige Haltung einnehmen, um sich tatsächlich hinter der Deckung zu positionieren. Das Bewegungssystem ermöglicht es uns, den richtigen Kontext von der Anfrage bis zur Ausführung der Bewegung zu haben, so dass wir den notwendigen Schritt vorhersagen können, den der NSC unternehmen muss, um korrekt in eine "hintere Abdeckung" zu gelangen.
Wir sind gerade dabei, das taktische Punktesystem CryEngine mit unseren neuen Verhaltensweisen zu integrieren. Das Tactical Point System (oder TPS) ist ein Abfragesystem, das es uns ermöglicht, Sonderpositionen mit bestimmten Eigenschaften abzufragen.
Zusätzlich zur Entwicklung der Systeme kümmern wir uns um die Erstellung des gesamten Klebecodes zwischen den Systemen, damit die NPCs die bestmögliche Qualität erhalten.
Und wir koordinieren weiterhin die Verbesserungen am Kythera Behavior Tree und dessen Integration mit Dataforge.
Design
In diesem Monat hat das DE Design Team viel Zeit damit verbracht, an vier Initiativen zu arbeiten: Aufbau eines Levels für Staffel 42, Unterstützung bei der Freigabe des FPS-Moduls, Aufbau von KI-Verhaltensbäumen für FPS, Staffel 42 und das Persistent Universe und dann Zusammenarbeit mit dem britischen Team an Staffel 42 Level Feedback. Wir überprüfen die Missionen und Begegnungen, die sie für das Tempo, den Einsatz von Mechanik im gesamten Level, den Level-Flow und die Ideen für das Gameplay von Moment zu Moment aufbauen.
Animation
Derzeit verfügt das DE-Büro nur über einen Animator, der sich ganz auf die Unterstützung von Kinofilmen konzentriert. Diesen Monat arbeiteten sie daran, Szenen für Drehbuchveranstaltungen und Filmszenen im Spiel einzurichten, Pipeline-Tools zu identifizieren und zu dokumentieren und eine Überprüfung des Squadron 42-Skripts (mit dem Cinematic Director), um herauszufinden, welche Szenen den Kinematiken gehören werden.
Kinematiken
Hannes ist zurück vom langen Filmdreh. Er wird in der Lage sein, zum Monatsbericht beizutragen, der nächsten Monat beginnt. Sie hatten einige wirklich talentierte Schauspieler auf der Bühne, die erstaunliche Leistungen zeigten. Wir alle freuen uns intern darauf, diese zusammenzuführen, wie ich sicher bin, dass auch die Geldgeber dies tun.
Audio
Nicht viel Neues für Audio in diesem Monat, immer noch arbeitend an der Wwise Konvertierung, die letzten Monat begann. Die EVA-Triebwerke und Ship Shield-Schläge wurden angeschlossen, um das Wwise-Audiosystem zu nutzen, und mehrere audiobezogene Fehler behoben. Beginn der Arbeiten zur Verbesserung der entfernungsbasierten Aussortierung aktiver Schallquellen, damit die Sound-Designer detailliertere Klanglandschaften erstellen können, ohne die Sound-Engine zu überlasten.
System erstellen
Im Juni besuchte unser Senior Build Engineer unser Austin Studio (ATX) für 3 Wochen und arbeitete in enger Zusammenarbeit mit den Dev-Ops /IT-Teams an vielen Aspekten unseres Build-Prozesses, der Optimierung und der studioübergreifenden Lieferung. Unter vielen Dingen war das Hauptziel, die Zeit zu verkürzen, die benötigt wird, um einen Build zusammenzustellen, Patches zu erstellen, Server einzusetzen und so weiter.
Wir haben uns entschieden, vom aktuellen Build-System wegzugehen und uns für etwas zu entscheiden, von dem wir überzeugt sind, dass es uns viel mehr Anpassungsmöglichkeiten geben wird, um es besser auf die Bedürfnisse unseres Spiels abzustimmen. Dies ist noch in Arbeit, es wurde viel Arbeit geleistet, und in den nächsten Wochen wird noch mehr getan werden.
VFX
In den letzten Monaten haben wir hart an verschiedenen Effekten der Staffel 42 gearbeitet. Einer dieser Effekte war ein riesiger Plasma-Bohrer. Es wird verwendet, um Asteroiden in kleinere Stücke zu zerlegen, um Ressourcen zu gewinnen.
Grüße Bürger!
Ein ganzer Monat ist vergangen und wir waren beschäftigt!
Ingenieurwesen
Wie üblich hat sich ein Teil des Teams auf die Entwicklung für kurzfristige Lieferungen konzentriert, wie z.B. die Unterstützung von FPS Lobby & Flow. Wir bewegen uns auch langsam davon weg, jetzt, da es das meiste von dem unterstützt, was wir für die erste Version benötigen, und haben begonnen, die Unterstützung von Mehrbesatzungsschiffen in der Lobby-Oberfläche hinzuzufügen.
Der Monat Juni hat uns ein paar tolle Features aus anderen Studios gebracht, die es uns ermöglicht haben, gemeinsam zu arbeiten, um den Online-Hangars etwas mehr Funktionalität zu verleihen. Wir haben hart an der aktuellen Holotable-Implementierung gearbeitet, um die Notwendigkeit zu reduzieren, dass Schiffe im Spiel gelaicht werden, damit sie in Arena Commander eingesetzt werden können. Dies wird es uns ermöglichen, die Ladezeiten zu verkürzen und die Verwaltung von servergehosteten Hangars zu erleichtern. Wir haben auch einen Teil der Flairs Implementierung und des Hangar Spawning überarbeitet, um in einem solchen Kontext richtig zu funktionieren.
Auch die Erfahrung auf dem Planeten ist nicht sich selbst überlassen geblieben, da wir noch daran arbeiten, die Augmented Reality (AR)-Erfahrung mit mobiGlas sowie das Einkaufserlebnis als Ganzes um einige Features und ein gewisses Maß an Feinschliff zu erweitern.
Design
Das Designteam hat Aufzüge und Türen für Nyx eingerichtet sowie verschiedene Funktionen (wie dynamisches Spawning, mobiGlas AR-Tags und Textstring-Lokalisierung) für die Artikel, die in Casaba Outlet erscheinen werden. Wir haben auch Follow-ups über das Einkaufserlebnis, Flairobjekte und Level Design Blueprints für Hurston, Crusader und Microtech durchgeführt.
Kunst
Diesen Monat haben wir viel Arbeit für die Nyx-Asteroidenkarte geleistet, Materialien und Texturen verbessert und die Umgebung so gestaltet, dass jeder Raum eine Geschichte zu erzählen hat. Wir haben auch an der Verbesserung einer unserer vorherigen Karten gearbeitet, indem wir ihr Layout geändert haben, um die Navigation zu optimieren und die Leistung zu verbessern.
Zusätzliche Anstrengungen wurden auf unserem Shopsystem unternommen. Wir haben Details hinzugefügt, wie die Kleidung in den Regalen platziert wird, um eine gute Sicht aus der Sicht des Spielers zu ermöglichen.
Endlich, wie immer, haben wir das Flair-Objekt des nächsten Monats fertig gestellt. Viel Spaß!
UI
Das UI-Team hat schon einige Frühjahrsputzarbeiten durchgeführt (nie zu spät!). Wir haben an einem gründlichen Durchlauf des neuen holotable Designflows gearbeitet, um die gesamte Benutzerfreundlichkeit zu verbessern und die verschiedenen Bildschirme zu vereinheitlichen. Gleiches gilt für die Simpod-Schnittstelle (auch bekannt als Electronic Access). Wir haben auch viele Aufgaben mit niedriger Priorität bereinigt, die sich langsam und stetig angesammelt haben.
Bis zum nächsten Mal, Bürger!
Hallo Bürger!
Ein weiterer Monat, ein weiteres Update. In den letzten Monaten ist einiges passiert. Im Moment haben wir drei Gäste von CiG (Sean Tracy, Steve Bender und Jason Hutchins), die uns in Denver besuchen und uns helfen, wo immer sie können. Wir konzentrieren uns derzeit darauf, die Kernbewegung so solide wie möglich zu gestalten, während die Animationen in der ersten und dritten Person immer noch gut aussehen. Das ist keineswegs einfach, deshalb haben wir die zusätzlichen Verstärkungen! Weitere Updates zum FPS-Modul Push finden Sie im wöchentlichen Star Marine Update.
Ingenieurwesen
Im Laufe des letzten Monats konzentrierte sich das Engineering vor allem auf die Kernbewegung und das Start-/Stopp-/Steuerungs-/Steuerungssystem. Dies war eine enge Zusammenarbeit mit Animatoren und Designern, die alle Edge Cases ausarbeitete und versuchte, die absolut beste Balance zwischen Steuerreaktion und Animationsqualität zu finden. Alles muss dann funktionieren und für den 1st und 3rd Person Modus poliert werden. Zusätzlich zur zentralen Fortbewegung haben sie auch Regeln für Star Marine erstellt, so dass sie Statistiken auf die gleiche Weise berichtet wie Arena Commander für Ranglisten und den Aufbau von REC. Schließlich wurden 5 verschiedene Bewegungsgeschwindigkeiten implementiert. Dies macht das Bewegen mit einer Steuerung sehr flüssig und variabel, je nachdem, wie viel Neigung auf den Stick aufgebracht wird.
Animation
Die Animatoren waren alle darauf ausgerichtet, mit Starts/Stopps/Jukes alles so gut wie möglich aussehen zu lassen. Dabei handelte es sich meist um eine sehr schnelle Feedbackschleife mit Steve Bender. Sein Feedback einholen, optimieren und die Ergebnisse zurücksenden, bis alle zufrieden sind. Es ist sicher eine Menge Arbeit, aber das Team hier leistet wirklich gute Arbeit und die Geschwindigkeit dieser Arbeit steigt fast täglich, nachdem die Prozesse geklärt sind.
Kunst
Das Kunstteam hat an der Optimierung aller Anlagenteile für das Gold Horizon Station Set gearbeitet, zusammen mit der Anpassung der Anlagen an die Metriken, die bei Foundry 42 verwendet werden. Das ist nicht gerade die interessanteste Arbeit, aber es ist etwas, das auf lange Sicht für das persistente Universum und die Staffel 42 getan werden muss.
Design
Das Designteam nimmt auf Wunsch von CiG zahlreiche Optimierungen am Gold Horizon Level vor. Dazu gehören einige Anpassungen an den Positionen der Munitions- und Energieplatzierung, das Entfernen einiger Türen und das Ändern des Verhaltens anderer durch die Ebene. Darüber hinaus optimieren sie auch die Sichtlinien im gesamten Level und machen einen Poliergang bei der Platzierung der Abdeckung.
Das ist alles, was ich diesen Monat für euch Jungs und Mädels habe. Bis zum nächsten Mal!
Hier ist, was wir in diesem letzten Monat hier oben in Montreal gemacht haben:
Jump Point Interview
Zunächst einmal hatte unser Team in diesem Monat die Möglichkeit, an einem Interview zu einer Ausgabe von Jump Point teilzunehmen. Dies gab uns die Möglichkeit, einige der Projekte, an denen wir für Star Citizen gearbeitet haben, zu diskutieren und ein wenig Licht darauf zu werfen, was als nächstes kommt. Vielen Dank an David Ladyman, der es uns ermöglicht hat, etwas mehr Details (und etwas informeller) über unseren Prozess zur Neugestaltung des globalen Erscheinungsbildes der Website zu erfahren.
Starmap
Diesen Monat haben wir das Hauptwerk für den Starmap-Viewer fertiggestellt, einschließlich Galaxie- und Systemansichten. In Bezug auf die Schnittstelle haben wir einige wesentliche Änderungen am HUD sowie an den Filteroptionen (Sensoren und Wärmenetz) vorgenommen.
Auf der Datenseite haben wir gute Fortschritte bei der Datenmodellierung für die kommende Galactapedia gemacht. Wir haben auch an unseren eigenen Verwaltungstools gearbeitet, damit wir Daten aus dem Star Citizen-Universum importieren können. Dies ermöglicht es, alle Daten der verschiedenen Himmelsobjekte bereits in einem Galactapedia-Format zu haben.
Auf der 3D-Front haben wir mit der Produktion der verschiedenen Assets begonnen, die im WebGL-Viewer angezeigt werden (Planet, Jump Point, Raumstation, etc.). Das ist sehr arbeitsintensiv und es ist das, was der Benutzer auf seinem Bildschirm sehen wird, und deshalb werden wir in den nächsten Monaten daran arbeiten.
Issue Council
Wie bereits beim letzten Mal berichtet, haben wir den Issue Council kontinuierlich weiterentwickelt, um sicherzustellen, dass er den Zeit- und Arbeitsaufwand für alle Beteiligten erheblich reduziert. Wir haben auch daran gearbeitet, sicherzustellen, dass es nicht leicht von großen Gruppen von Benutzern (z.B. Organisationen) beeinflusst werden kann. Wir haben neue Funktionen hinzugefügt, Layouts neu organisiert, Dinge von einer Seite zur anderen verschoben, Seiten entfernt und so weiter - so sehr, dass wir, als wir einen Schritt zurückgingen und es uns ansahen, merkten, dass die Benutzeroberfläche nicht mehr intuitiv war. Also versammelten wir das Team um ein großes Whiteboard und arbeiteten daran, dies zu beheben.
Das Kernupdate, das wir erarbeitet haben, war ein aktualisierter Ablauf für die Benutzer. Nach der Ankunft im Issue Council werden den Nutzern drei Möglichkeiten geboten, sich dem System zu nähern:
Tragen Sie dazu bei, indem Sie versuchen, Probleme zu replizieren und ungültige Tickets (Duplikate, Feature-Anfragen, schlecht geschriebene usw.) markieren. Priorisieren Sie die bestätigten Tickets, damit die Entwickler wissen, was für die Community wichtig ist. Durchsuchen Sie alle Tickets, die jemals erstellt wurden. Wir werden bald einige Entwürfe zum Teilen haben, aber um einen kleinen Einblick zu geben, hier ist ein Foto von einem der Whiteboard-Designs von Benoit.
Community Hub
Der Community-Hub hat seine letzte Phase erreicht, und unsere Entwickler haben daran gearbeitet, ihn den ganzen Monat über tatsächlich umzusetzen. Die wichtigste Aufgabe bei diesem spezifischen Projekt war die Einrichtung der Einreichungsabläufe. Diese ermöglichen es Ihnen, Bilder und Galerien Ihrer eigenen Kreationen hochzuladen, Ihre YouTube-Spielsitzungen einzubetten oder interessante Links zu melden, die Sie anderswo gefunden haben, was eine große technische Flexibilität von der Website selbst erfordert. Noch interessanter war, dass wir uns einige Zeit Zeit genommen haben, um Filter und Sortieralgorithmen zu entwickeln, die auf der Menge und Häufigkeit der geposteten Inhalte und deren Beliebtheit durch Upvotes und Kommentare basieren. Es ist immer eine spannende Herausforderung, herauszufinden, wie eine Website ihre eigenen Inhalte präsentiert, um sie so relevant und frisch wie möglich zu halten.
Moderationswerkzeuge
Ein weiteres Projekt, an dem wir gearbeitet haben und das kürzlich gestartet wurde, waren die neuen Moderationswerkzeuge für das spezielle Moderatorenteam der Website. Diese Tools geben ihnen nun mehr Einblick in markierte Inhalte, Wiederholungstäter und berüchtigte Rückfalltäter sowie eine schnellere Verwaltung des Forumszugangs. So können sie die Foren, Kommentare und Orgs noch reibungsloser und effizienter gestalten. Mit ihrer Hilfe haben wir eine Reihe von Tools entwickelt, die dann erweiterbar sind, um alle benutzergenerierten Inhalte abzudecken, einschließlich aller Aspekte des kommenden Community Hubs.
Der Konzeptverkauf dieses Monats war eine Kurzgeschichte, die die Genesis Starli vorstellte. wie sie von Meridian Transit betrieben werden. Diese schnelle Tränendrüse (siehe Postkarten) wurde von Star Citizen's eigenen Autoren geschrieben, und zusammen mit einigen ziemlich coolen Kunstwerken und Voiceovers vom Community-Team gab sie uns viel Raum, um Spaß mit der Post zu haben. Deshalb wurde es schnell zu einer der skriptlastigsten Seiten der Website, mit Minikomponenten wie dem Flight Board oder den flippenden Postkarten. Das Flight Board selbst basierte auf einem sehr frühen Konzept für den Events-Block auf der Homepage der Website, das uns sehr am Herzen lag, aber zu viel Wert auf die Browser legte. So waren wir wirklich froh, es trotzdem als Teil der Kurzgeschichte nutzen zu können.
Was du nicht gesehen hast.
Wie in jedem anderen Monat wurden auch unsere Programmierer mit Verbesserungen und Korrekturen beauftragt, die zum Glück unbemerkt geblieben sind. Im Juni dieses Jahres standen die von uns eingesetzten Zahlungsabwickler im Vordergrund: Amazon migrierte ihr gesamtes Zahlungssystem, an das wir uns anpassen mussten, und wechselte zu einer völlig neuen Art der Abonnementverwaltung. Eine andere, die ungenannt bleiben soll, hatte auch für uns einige interessante Überraschungen, auf die wir sehr schnell reagieren mussten. Wir haben uns auch einige Zeit damit beschäftigt, dem Kundendienstteam neue Werkzeuge zur Verfügung zu stellen, um ihm zu helfen, Problemfälle noch effizienter zu bearbeiten.
Es war ein weiterer arbeitsreicher Monat am Moon Collider, also lassen Sie uns direkt darauf eingehen:
Ingenieurwesen
Es ist ein bekanntes Sprichwort, dass kein Plan den Kontakt mit dem Feind überlebt, und ich denke, ein ebenso gültiges Sprichwort wäre kein Werkzeug den Kontakt mit den Designern! Egal, wie gut Sie ein neues Werkzeug entwerfen, in dem Moment, in dem die Designer damit spielen, werden Sie sehr schnell herausfinden, was verbessert werden muss. Letzten Monat gaben wir Designern die Möglichkeit, Verhaltensbäume mit einem Editor zu schreiben, der in DataForge, dem benutzerdefinierten Datenverwaltungstool von Star Citizen, integriert ist. Wir haben versucht, es so schnell wie möglich in die Hände des Designers zu bekommen, also hatten wir bereits eine anständige Todo-Liste mit Verbesserungen, von denen wir wussten, dass sie benötigt werden, aber ein paar Stunden echter Nutzung eines Tools durch einen Designer helfen immer zu klären, welche Probleme kleine Ärgernisse sind und welche häufig ihren Workflow unterbrechen oder sie unfähig machen, eine Aufgabe zu erledigen.
Wir haben diesen Monat einige Zeit damit verbracht, Feedback von Designern zu erhalten und ihre priorisierte Liste von Problemen mit dem neuen Editor durchzugehen. Dazu gehörten Dinge wie das Verfassen von mehr Dokumentation über die Funktionsweise bestimmter Funktionen, das Umbenennen, Rekategorisieren und Neueinfärben von BT-Knoten auf eine für einen Designer intuitivere Art und Weise und sogar das Verschieben bestimmter erweiterter Funktionen aus dem Standard-Workflow, so dass es etwas mühsamer ist, diese selten benötigten Funktionen zu verwenden, aber es macht die gemeinsamen Funktionen schlanker. Wir gehen davon aus, dass wir dieses Tool im nächsten Monat weiter verbessern werden, da das Feedback der Designer immer wieder einfließt.
Da die Designer nun mit DataForge an Verhaltensbäumen arbeiten, war es auch der perfekte Zeitpunkt, um unserem webbasierten Debugging-Tool Kythera Inspector eine Live-Ansicht des Verhaltensbaums hinzuzufügen. Dies ist eine Webseite, die Designer aufrufen können, die einen direkten Zugriff auf den Zustand der KI in ihrem Spiel ermöglicht, und wir wurden ständig um Funktionen erweitert, um das Debuggen der KI zu erleichtern. Bisher haben wir uns auf einige einfache Text-Debugging auf dem Bildschirm verlassen, um den aktuellen Zustand des Verhaltensbaums einer KI zu verstehen, und während dies für einen kleinen und einfachen Baum einigermaßen gut funktionierte, war es für größere Bäume viel weniger nützlich und auch in den bereitgestellten Informationen eingeschränkt.
Die neue Live-Ansicht in Inspektor ermöglicht es Designern, den Zustand des Verhaltensbaums einer beliebigen KI zu sehen, während das Spiel läuft. Wir haben einige neue Funktionen im nächsten Monat, die es ihnen ermöglichen werden, Konfigurationsfehler mit ihren Bäumen aufzuspüren, was in Kombination mit der bereits vorhandenen Fähigkeit, die Verhaltensbäume der KI aufzuzeichnen und wiederzugeben, Designern eine umfassende Suite von Werkzeugen zum Debuggen ihrer Verhaltensbäume bieten sollte.
Ein Problem, das wir schon seit einiger Zeit zu lösen versuchen, ist ein technisches Feature, das wir einen Zeichenkettenhash nennen. Dies ist etwas, das in Kythera eingebaut ist und es uns im Grunde erlaubt, jede beliebige Textzeichenkette im Code zur Kompilierungszeit in einen numerischen Bezeichner umzuwandeln. Dies macht es billig und effizient, Zeichenketten im Code zu übergeben und zu verwenden, ohne sich Sorgen zu machen, dass es teuer ist, Vergleiche durchzuführen, was normalerweise bei Zeichenketten der Fall ist. Und das bedeutet, dass Sie viel mehr beschreibenden Text in Ihrem Code haben können, als einfache Zahlen, was Code, der einfacher zu bearbeiten und zu debuggen ist, machen kann.
Da dies ein so nützliches Feature ist, wurde dem Rest der Star Citizen Codebasis eine ähnliche Version hinzugefügt. Was wir versucht haben herauszufinden, ist, wie man diese beiden verschiedenen Versionen von Zeichenketten-Hashes am besten vereinheitlicht, so dass wir die Kosten für die Konvertierung zwischen ihnen vermeiden können. Es gibt verschiedene Details, die es schwieriger machen, dieses Problem auf eine befriedigende Weise zu lösen, als es zunächst den Anschein hat, also haben wir Zeit damit verbracht, dies mit Programmierern in einigen der anderen Studios zu besprechen, und testen derzeit einige mögliche Lösungen, um sie auszuprobieren und zu sehen, ob sie in der Praxis Probleme verursachen.
Nun, lasst uns über Schiffe reden!
Letzten Monat haben wir die Funktion hinzugefügt, die es Schiffen ermöglicht, Splines zuverlässig zu verbinden. In diesem Monat haben wir begonnen, dieses Feature in Form von Retreat-Stunt-Splines sinnvoll zu nutzen. Stuntsplines sind Pfade, die von Designern in einer Ebene festgelegt werden und es der KI ermöglichen, durch enge Bereiche zu fliegen, in denen ihre Kollisionsvermeidung sie sonst daran hindern würde, zu gehen, wie z.B. durch einen Tunnel in einem Asteroiden oder Lücken zwischen Abschnitten einer Raumstation.
Eines der Hauptziele dieser Stuntsplines ist es, Möglichkeiten für Spieler zu schaffen, die KI auf interessanten und spannenden Wegen zu verfolgen. Wir haben sie dem KI-Rückzugsverhalten hinzugefügt, so dass, wenn sich ein KI-Schiff von einem Verfolger lösen will, wenn es in der Nähe einen Stuntspline gibt, es versuchen wird, ihn zu nutzen. Um die Dinge glaubwürdig zu halten, wird die KI nur dann einen Spline wählen, wenn er schnell darauf zugreifen kann, so dass sie keinen verwenden wird, wenn er eine größere Änderung der Geschwindigkeit oder Richtung erfordert, um zu ihm zu gelangen.
Wir können sie auch verwenden, um Elite-KI-Piloten von Neulingen zu unterscheiden, indem wir ein Fertigkeitsniveau an der Spline anbringen. So kann ein wirklich haariges Manöver als nur für die besten Piloten verfügbar markiert werden. Dies bedeutet auch, dass, wenn Sie gehen, um ein fliehendes Eliteschiff zu jagen, Sie sich in einer Jagd befinden können, die Sie nicht gut genug sind, um abzuschalten, und Sie müssen eine schnelle Entscheidung treffen, wie verrückt ein Pilot ist, den Sie bereit sind zu sein!
Sobald die Designer die Möglichkeit hatten, mit dieser Funktion zu arbeiten, planen wir, den Auswahlprozess der Verzahnung zu verfeinern, um eine gute Balance zu erhalten, damit sie nicht übermäßig oder ungenutzt genutzt werden. Es ist wichtig, dass die KI für einen Spieler, der mit einer Karte vertraut ist, nicht allzu vorhersehbar wird, aber andererseits kann es auch etwas sein, zu sehen, wie ein Schiff abbricht und zu dem Tunnel fährt, von dem man weiß, dass es viel Spaß macht, durch ihn zu fliegen.
Wie immer bei neuen Features, freuen wir uns darauf, dass dieser in die Hände von echten Spielern kommt und die coolen Geschichten hört, die daraus entstehen!
Grüße Bürger,
Wir sagen immer, dass es ein arbeitsreicher Monat für das Community-Team war, aber an dieser Stelle.... welcher Monat ist nicht arbeitsreich?
Wir waren diesen Monat sehr glücklich, den ersten Jahrestag von Around the Vers zu feiern! AtV war für uns ein interessantes Projekt; letztes Jahr gingen wir auf die Frage ein, wie sehr wir die Notwendigkeit fürchteten, den Hangar des Fan-Favoriten Wingman zu ersetzen.... und wir nahmen uns die Zeit, unsere Füße zu finden und herauszufinden, was wichtig war. Dank deines Feedbacks (und deiner Unterstützung!) sind wir stolz auf das, was aus der Show geworden ist.... und wir werden versuchen, sie weiter zu verbessern. Episode 50, die letzte Woche ausgestrahlt wurde, hatte ein besonders herausragendes Segment, in dem der Designer Randy Vasquez seinen Prozess zum Bau von Starliner-Innenräumen zeigte. Erwarten Sie, dass wir in Zukunft weitere Segmente wie diese sehen werden, da wir der Meinung waren, dass es unser bisher stärkstes Stück ist.
Wir haben auch das Community-Team gebeten, in den Foren interaktiver zu sein. Wir sind genauso gespannt auf die Veröffentlichung von Star Marine wie der Rest der Community, und wir werden unser Bestes tun, um da rauszukommen und nicht nur die Flagge zu zeigen, sondern unsere Antworten und Gedanken mit euch allen zu teilen. Ein Community-Manager kann nicht immer deine Fragen beantworten.... aber wir sind hier, um das zu besprechen, was wir können, und auch um deine Bedenken anzuhören und sicherzustellen, dass die Entwickler sie kennen. Noch besser ist, dass wir an einem Relaunch des Ask a Dev-Prozesses arbeiten, der hoffentlich zu einem System für die Beantwortung Ihrer Fragen durch die Experten führen wird.
Das ganze Team hatte auch einen großen Tag mit dem Verkauf des Genesis Starliner. Wir wollten vermitteln, wie viel Tiefe das Schiff hatte, und das gesamte Team arbeitete zusammen, um der Präsentation Teile hinzuzufügen, von denen wir dachten, sie würden die Community interessieren. Von Jared's Postkarten bis zu Ryans Sicherheitskarte wollten wir Ihnen mehr zeigen, als nur, wie groß die Waffen waren (und wenn wir ehrlich sind, sind die Waffen überhaupt nicht so groß.)
Schließlich sind wir sehr traurig, einen von uns zu verlieren: Chelsea Day, Manager des Customer Service Teams, hat die CIG verlassen, um den Standort zu wechseln. Chelsea war eine gute Freundin und eine großartige CS-Managerin; wir werden sie alle vermissen! Patrick Probst, den Sie vielleicht schon im Forum gesehen haben, wird die Position des CS-Managers in Großbritannien übernehmen. Also herzlichen Glückwunsch - wir wissen, dass Sie dem beispielhaften Chelsea-Set gerecht werden!
Greetings Citizens,
Summer is here (in the northern hemisphere, anyway) but we aren’t on vacation: big things are happening at CIG! Watching from the inside, it’s gratifying to see the moving parts that will form Star Citizen starting to come together. Important pieces of long-talked-about technology, like large world maps, are coming online internally and there’s an air of excitement among the development teams as the reality that a lot of what we’ve been planning for and working towards is finally happening sets in. We’re eager to share our progress with you, which means a push to get not just the Star Marine FPS module out, but to start sharing more about multicrew and the persistent world. Watch this space! As always, we’ve asked our project leads to put together individual reports for the community to let you know exactly what every part of the company has been doing. Read on!
Hey everyone! It’s been an amazing month chalked full of exciting work here in sunny Santa Monica. We love sharing with you everything we’ve been working on so enjoy and always let us know if you have any questions or thoughts!
Engineering
Our engineering team has been really busy this month. Everything from datastore clean up to the new character material system creation to large world updates. So let’s dig in:
We did some early implementation of the vehicle parameters where we were off loading the vehicles from parsing an xml on every spawn to parsing a single xml once and using it from then on to build a vehicle. Also, the only way we knew how to build a ship is to spawn it then look at what it contains. Now, other systems can just look up the parameters to build out a ship. We no longer need to spawn every ship below the hangar which was a massive change. We also had lots of integration bug fixes for FPS & Arena Commander. We continued working on the Radar 2.0 system where we moved the system from entity-only-based to practically anything the designers need to show on the HUD. The back end work is built, now we need to change HUD and other vehicle components to handle those objects so the designers can go nuts! We also did a lot of vehicle code clean up by deleting unused code which sped up a lot of the slow bits but this is going to be an ongoing process.
UI has been working tremendously hard on upcoming ship designs and implementation. Specifically, the glitch effects and boot up for the Vanduul. We reviewed a proposal for improved cockpit interaction and began preparation for HUD to support different seat actions and roles.
We’ve been doing some datastore cleanup, removing duplicated code, unifying different spread out code into single pass, and began preparation for Multicrew spawning/MP hangars. We separated object spawning from player spawning to move Hangar loading into level loading phase.
We’ve also been working on multi-layer material system. The goal is to end up with a fixed library of base materials that are blended together (up to 4 layers) to create more complex materials with minimal draw calls. Texture library and core shader functionality are mostly done, now working on the base material library that would bridge the render resources with the blended materials.
On the AI side, we’ve been doing a lot of ship bug fixing, particularly in regards to the pilot an AI ship creates and maintains. We also did a bit of work on the “defend target” wingmen command, creating an AI ship aspect that keeps track of nearby threats so that escorting ships will know what to attack.
On the Large World side, we fixed various trigger area issues in LW maps such as removed the +/- 16km limit for all the trigger areas and additional boundary conditions fix-up. We did a bit of interface clean-up for Matrix34 / Quat and established the prerequisite to make the rotational part of all those primitives to float. We also fixed the position info bar and GOTO position dialog and increased camera move speed in Sandbox while authoring LW maps. Lastly, we finished thread-safe texture loading with thread-safe shader parsing and thread-safe shader resource creation almost done. Phew, we had a great month and are looking forward to more!
Design
The design team here are keeping incredibly busy with all the upcoming ships, modes, gameplay needs, and so on. One of the bigger focuses for us was on the Genesis Starliner. We wanted to make sure we thought everything through to be ready to bring this awesome ship to you. We had a lot of work to get through this month such as establishing the initial gameplay balance plan which includes potential updates to stats, features, game modes, hud, controls, missiles, etc. Here are some of the in-depth details of this month:
We fixed an issue with the RSI Constellation Andromeda where the old Hangar Ready version would crash the hangar. Oops! We also switched the main elevator entrance from being a door to a switch to allow for entering/exiting via different doors without resetting the animation states. We also fixed both upper and lower turret hand positions. Also, in an effort to make the Constellation flight ready we overhauled thrusters.
For the Scythe dogfighter we dove into an issue in which the multilight was not loading into the light port and the archetype was crashing the client. We also removed unnecessary AI Space Ships and updated the Scythe to utilize “Scythe_Swarm” modification block to adjust AI Scythe health.
On the Hornet F7CM, we fixed an issue in which one of the thruster hard points was misnamed, preventing the thruster from loading onto the ship. We also combined the bound geometry and Weight Transfer Tool while refactoring controls design quite a bit.
On the Mustang Delta, we removed inclusion of default animations, which were colliding and causing problems (such as misplaced hatch and open/close animations not playing). We also implemented the AEGS Retaliator enter and exit Pilot Seat and updated the Interiors to use latest from Production level. That’s quite a bit of how our month went and are ready to go for the month of July.
Art
Overall, it’s been a very busy month for our art team in Santa Monica. Specifically, the vehicle artists have been busy focusing on the Merlin that just went through its final art pass and delivered to design to get flight ready. In addition, our Senior Vehicle Artist, Paul Forgy kicked off the first stages of getting the Bengal Carrier exterior white boxed and in the game engine. Can’t wait for those capital ships! With the new damage tech coming online, LA artists have been working hard to make sure the flight ready ships support the revised system. The Scythe is one of the first and has been setup for full damage support. Be sure to look for that in the near future. Now that’s not the only update to the Scythe. The ship’s cockpit has been retrofitted for human flight. Be expecting that in AC soon!
Alongside our ATX comrades, the LA studio has been working on revamping characters for not only the FPS, but for characters across all modules. Omar Aweidah is nearing finalizing the first gold standard to fully utilize the new character shader tech powered by Multi-LayerBlend written by our very own, Okka Kyaw. Now, we are ready to step up the character’s visual fidelity and take the massive leap into the future of character development for the Star Citizen universe.
Speaking of characters, our Production Designer of character concepts, Rob McKinnon is really ramping up our concept development quite heavily. We’re making great strides in developing looks for the characters of Star Citizen. 3D sculpts provided by Rob McKinnon and his team have given us our first 3d look at marine uniforms. Whether it’s a bridge office or a BDU, the marines are looking top notch. The Navy has tons of roles and responsibilities and we now have an outfit for each of them. From Officers on deck, to medics on call, the Navy uniforms are sharp and ready to begin 3d production.
With all the excitement of getting to ride the Meridian Transit, we have made sure you weren’t without a drink. The Genesis Starliner now has the very first concept designs for flight attendants. Also, the Vanduul just got a lot tougher with new images created from the concept team showing off new armor sets. The Vanduul now look meaner than ever. Under the armor has gone through revisions to attempt at finalizing the skin of this Alien race.
And that does it for the Santa Monica studio update for this month. Thank you so much for taking the time to look over all of the team’s hard work and supporting the creation of the game. None of this would be possible without your continued support and we’re honored to be able to make this game with you. We value your feedback and thoughts so keep them coming.
Hi Everyone!
It has been an unusually rainy and cool June in Texas and we’ve been enjoying it. We have hosted a number of visitors from other studios this month and we’ve been very focused on a number of different production priorities. We’ve made good progress on a number of fronts, and have a lot more work to do on the hard push to the end of the summer. Here are some detailed reports from the head of each team.
Persistent Universe Team
Art
This month the PU Concept Art Team spent the majority of their time fleshing out details of major features of the game. Ted Beargeon and Ken Fairclough crafted pieces that defined hero props for the Nyx>Delamar>Levski landing zone. We sent concepts of statues and large machinery over to BHVR to take to modeling. Likewise, some time was spent on fleshing out the Levski market area to help define the shopping experience there, as it will be different than anything we’ve done so far. Megan Cheever spent her time this month doing detail passes on various concepts of military personnel. She helped define the badges, medals, and materials you’ll see in the final game. Megan also concepted the flight attendant characters you saw in the Starliner sale this month.
Our PU Environment Team has been wrapping up the final detail passes on Levski as well. Lee Amarakoon and Emre Switzer have been providing VFX and Lighting support, respectively. Levski is beginning to look properly dark and gritty as a result of these guys’ work. Lee also got to work on revising the Customs Scanner effect you saw shown off at CitizenCon last year. Our Environment Leads, Cort Soest and Patrick Thomas, have been working with BHVR to optimize the environment itself and bring it the last 10 percent to completion. Next month Levski should be wrapped up and ready to show off somewhere down the road.
The Stanton>ArcCorp>Area18 landing zone has also been a huge focus for us this month. The environment has undergone some layout revisions to aid in optimizing it for release with the Social Module. Mark Skelton has been working in tandem with Tony Zurovec to provide direction for the changes. This environment is going to look better than ever as result.
The Character Team here in Austin just recently wrapped up the SATABall character and helmet, and it looks amazing! This was one of the first characters we took from start to finish utilizing our new Next-Gen Character Pipeline, and the new techniques have proven effective in making stellar characters for Star Citizen. We look forward to showing off David Jennison and Billy Lord’s work very soon!
The Austin Animation Team has had their hands full in several different areas of the project this month, per usual. We’re wrapping up work on the new female skeleton this week, which will allow us to finally get some ladies into the game proper! We’re also supporting Illfonic in implementing and polishing FPS animations, as well as polishing animations for Social Module. In addition, we’re working on standardizing animation templates for ship cockpits and enter/exit sequences to cut down on ship modeling time going forward. One thing you should see fairly soon are the updated G-Force animations in the cockpit. Jay Brushwood, Sean Tracy, and Jeff Zhu did a fantastic job bringing those to the next level.
Design
This month the PU Design Team spent much of their time brainstorming and fleshing out designs for upcoming player occupations in the PU. With Tony’s guidance, we have revamped the initial designs for the Bounty Hunter, Mercenary, and Piracy occupations. We’ve also drafted up designs for Smuggler and Search&Rescue occupations. The big one this month though was the Passenger Transport occupation designed by Tony Zurovec. If you haven’t had a chance to read the post from the Starliner Sale, you should totally check it out HERE.
Another thing our designers have been doing this month is testing out the new Usable Editor. The Usable Editor is part of Tony’s “Subsumption” peaceful NPC AI system. It’s the first major step towards achieving Tony’s vision for how NPC’s will interact with objects in Star Citizen. It’s been an iterative process, with the designers playing around with the Usable Editor and giving feedback, gameplay programmer Tom Davies adjusting based on that feedback, and repeat. We’re excited to see the Usable Editor in action for the first time and testing out how far we can stretch its limits.
Lastly, we are starting to dive in to the initial layouts/designs of the next planetside landing zone we want BHVR to tackle after Levksi. We’re focusing on another planetside landing zone in Stanton, going back and forth between Hurston, MicroTech, and Crusader. Which landing zone do YOU want to see come online next?
Engineering
June was spent continuing progress on a lot of longer term tasks, as well as planning and support for our upcoming releases and Gamescom demo.
There was a lot of focus on investigating ways to optimize server performance and we made some great progress on that front for upcoming Arena Commander, FPS and Social Module releases. As reported last month, our Generic Instance Manager (GIM) is in the works and incoming. The GIM will be a huge revamp of our party and matchmaking systems and it will go through multiple iterations until we’re happy with it. This first iteration has been with our QA team and they haven’t been shy about sending us bugs. We’ve been handling them quickly and getting closer and closer to what will eventually be GIM v1.0. We’re excited to reach the point when we can share it with you all, and it’s a highly anticipated system here within CIG.
Over at Wyrmbyte, in addition to being an important contributor to our server optimization investigation, they’re been deep in their iPredictor code…working diligently on hammering out the remaining kinks. Meanwhile, our tools team has been super busy with bugs and tool feature requests to help our team make the game. They never get a free moment as there’s no shortage of tools requests…and they’re happy to deliver! We also have some game-play programmers continuing to work on some proof-of-concept functional prototypes for some ofour occupations. It’s exhilarating to start seeing the early formulations of what will end up as our occupations in the Persistent Universe.
So unfortunately it’s a bit shorter of a report this month. However, it’s not due to anyone sleeping on the job, the team is mostly on long term tasks and have been making great progress on them! Many of these hope to be rolling out to you in the coming months.
Stay tuned!
Live Operations
QA
This month Star Citizen QA successfully conducted three cross-studio FPS playtests with development. Tyler Witkin has done a great job coordinating the playtests and gathering subsequent feedback.
Automation development has ramped up. Melissa Estrada and Tyler Witkin are using the Sandox Editor and Flow Graph Editor to build levels that utilize what’s known as the Feature Tester. These levels will be used to automate various ship and FPS related functionality testing.
Thanks to very informative feedback from Senior Technical Designer Rob Reininger, we have significantly improved our editor testing to include more tests related to tools and level design.
Social Module and Planetside testing continues thanks to the efforts of Todd Raffray. As soon as a system or tool is developed, Todd ensures it is added as a test case in our comprehensive Planetside testing. The latest addition is the Usable Editor. The Usable Editor is utilized to give NPC’s the ability to interact with objects. The Usable Editor is a big part of the overall Subsumtion (Peaceful NPC AI) System.
Jeffrey Pease is ensuring that the General Instance Manager is properly tested during its official implementation into Alpha 1.2.0. The General Instance Manager is our revamp of the back end lobby and matchmaking systems. Jeffrey is also leading an investigation into the prevention of potential hacks and exploits and has provided very valuable information to our engineering leads who now have a plan of action to address these issues.
Congratulations to Andrew Hesse who has transitioned into the role of QA Lead for the Austin Studio. Andrew has done an amazing job testing all aspects of the game and has been a huge help to our ship technical designers as our resident ship specialist. This month we welcome our newest addition to the QA team, Andrew Rexroth. Rex has extensive QA experience and is already a huge help with specialized Star Marine testing.
Next month, we will be continuing our testing of Alpha 1.2.0 while also looking towards testing multiplayer hangars, significantly larger play areas, the multi-crew system and much more.
Game Support
The month of June for Game Support was spent largely on designing, reviewing, and building infrastructure and processes that are going to help our backers on a service-wide level.
Particularly helpful will be our system-wide administrative broadcast tool which will allow us to provide a communication method to all players connected to a live service, which is essential to informing you with up-to-the-minute information while playing the game. We’re also working on replacing our current forum-based Live Service Notification page with its own webpage, which will ultimately include a Server Status page for all environments (Arena Commander, Star Marine, PTU, patching, etc.) and gives us an effective tool for communicating the health of the service to all players.
We’ve also continued to help triage the issues from May’s 1.1.3 release. We’ve identified and communicated the issues from the current release and actively worked with Production to get these issues highlighted and fixed, including some of the missile and ship damage state problems that we’ve been seeing.
Lastly, we’ve begun and flesh out ideas and designs for what we’re going to need to support our different environments, and particularly the Persistent Universe. Supporting gamers usually depends on the type of game, but Star Citizen will have all three (singleplayer, multiplayer, and PU)! We’ve begun to ask ourselves: What technical inefficiencies do we have in supporting our players today? What will be the expected behaviors inside the game, and what will they require from us as a service? How do we manage the raft of attempted account takeovers that occur in every PU, and what tools do we need so that players can protect themselves? How do we manage the players’ ability to go onto the secondary gray market without completely restricting it?
We don’t have the answers to all of this today, but we’re heavily invested them. These are important questions to ask in the formation of any online community, and especially the BDSSE!
IT/Operations
June has been an exciting month for the IT team. We’ve continued to make performance optimizations to our build systems and while each improvement brings great pride, we feel like we’re getting to the point where each new improvement, while important, bears smaller and smaller gains. Not all gains will come from hardware though so we’re again working closely with certain members of the DevOps team to reduce the size of data we’re moving and just as importantly reducing the number of times we need to move data. One of the remaining challenges is our asset build system. These are the graphical assets that must be rendered for each build and with the fidelity targets we’re working with, this is a very big portion of the build process. This month we’ve started the work to break that job in to many smaller jobs so we can run more of this work in parallel in order to get the overall build time down for this portion of the build. The DevOps team manages the build system logic and the IT team supplies the hardware for the jobs.
In addition to build system tuning, IT has been doing some extra travel this month. Paul from Austin and Hassan from Manchester have been traveling back and forth to our office in Frankfurt helping to plan the logistics of that studio’s office move. A good amount of planning and preparation goes in to a move like this and all is on schedule so far.
They’ve handled everything from electrical and cooling to IP addresses and VPN tunnels. Based on their hard work to get everything to fit in to a weekend, the dev team will not experience any down time.
Dennis from LA and Chris from Austin continue to build out custom configurations for testing based on feedback we’re receiving from the forums. We’re no longer just supplying reported gear to QA for one off testing. Dennis and Chris are now building and rebuilding custom systems in order to match reported systems in cases where we think hardware could be a contributing factor. They’ve also initiated early testing of Windows 10 in our test labs.
June has been an exciting and rewarding month for IT but we’ve got some even bigger things planned for July.
Dev Ops
June has been mainly consumed by 3 large projects for DevOps. The new Launcher, the new build server, and our “Phoenix” environment project.
The new launcher has already been broken into several code versions being worked on simultaneously. While the current public launcher is version 1.6, version 2.0 is in testing with the company and being used for the FPS playtests. Version 2.1 is being working on for roll out next week and will allow for faster downloads, smaller incremental patches, and some download speed improvements. Version 2.2 is coming right after that with a bunch more features, and version 3.0 is being worked on while all the rest of this process happens. Version 3.0 is a complete UI overhaul, and should be much closer to the final product.
The new build server is close to being done. We still are aiming for a mid-July release to the company with the first builds from that system going out to the public in September. For the players, they shouldn’t see any difference at all from this switch over. However for the company and the developers the improvements from this system should be huge. Not only should it allow us to run more builds at the same time, increasing the throughput of work, but reducing the amount of time developers wait for build, it will also lower overall build speeds. Currently, it takes 4hrs to make one build and we need to make around 6-8 builds a day for development to progress. As you can probably see, this is more time in the day than we have. So builds get backed up, skipped, and work slows down. The new build server will allow us to run 2-4 builds at the same time, and should reduce the 4hrs. We still need to do accurate measurements to figure out just how fast the builds will be.
As Chris Robert’s mentioned in his Letter from the Chairman, we have been working on the what we’re calling the “Phoenix” dynamic environments system. Each time the team kicks off a new build of Star Citizen all the data that the servers need is automatically copied out to hard disks in Google; this is a snapshot of our game data. These disks are broken into two to three conceptual parts: Base Image (the OS plus a few other things), Logs, and Server Data (Code and Assets). When we build an environment, we mount duplicates of these disks to each Virtual Machine (VM) that we bring up. Duplicates of the snapshot are created very rapidly, around 45 seconds for 200 gigs of data. We’ve written some automation code to automatically run commands on the VM to configure it appropriately for what type of server it will become (Game, Matchmaking, Party, etc.) During this process, a new DNS entry is assigned to the server based off the version of the data uploaded. When a new build is created, and we need to push it to an environment, we trigger a command that automatically shuts down all VM’s, unmounts the duplicated disks of the Base Image and Server Data disk (Log disks are always kept for troubleshooting), and then restarts the server with the new duplicates based of the new snapshot and the environment is running and ready on the new version.
This entire process takes about 8 minutes. When we want to take a QA environment that is built this way, and extend it to become a PTU environment, we send a command to our Provisioning layer and it goes out to Google, requests more VMs, builds more disk duplicates, mounts those snapshots, runs Chef commands to configure it, adds their DNS entries, and connects them to the existing infrastructure to be used. At that point we have a PTU environment. We repeat this process to build Production. Each time we expand an environment it takes about 8 to 10 minutes depending on the type of environment and the configurations we need.
The benefit of this dynamic creation and the environment expansion is threefold. First, any changed configs, misplaced settings, or broken processes are completely removed when the VMs are rebuilt using the new disk duplicates. Any configuration changes that need to persist should be made at the Chef level. Second, we can make absolutely sure that PTU and Production are the exact same environments that QA tested on, so there will be no strange differences we failed to catch in QA when we go live. The third benefit is simply speed. It is much faster to dynamically recreate environments on the fly than to recopy data each time. Those last two points are a pretty big deal. If our experience has taught us anything it is that having a consistent test environment that can be rolled out quickly is critically important, and this new system is pretty quick. It’s a huge force multiplier for our ability to rapidly iterate our test versions, which means QA and ultimately our backers will be able to do more varied testing more quickly. The more accurate we can get versions to our QA and to our backers the better we can ultimately make the game. July should be a very exciting month, with some of these major projects moving out of development and into production.
Greetings Citizens,
Foundry 42 is energized and ready to keep working hard! Between supporting the p-cap shoot in London, working on Squadron 42 in its own right and continuing engineering tasks for multicrew Arena Commander, we’ve been busy! Here’s the details from our department heads:
Animation
We’ve started work on breaking up some of the systemic Ai animations for enemy actions. These include things like stepping and running in to cover from various angles. Reacting to grenades and moving out of the way. As well as that the team has been working on refining some of the mechanics that are currently implemented in game to try and achieve a more responsive feel while keeping the realistic motion captured data. As always we’re on hand to provide any block out mechanics and environmental animations for the art and design teams here at Foundry 42.
Engineering
Two areas I’d like to talk about this month, which we’re getting more heavily involved with here in the UK, are the UI and AI.
On the AI front we’re taking a more active role in its development and have been doing a lot of the ground work getting our new CIGAI system up and running, alongside our colleagues in Frankfurt and Moon Collider. We have been looking at a new communication system, and how we can use it in conjunction with our current dialogue logic, to expand on the ground-work laid by the DFM survival mode’s Warlord and Vixen AI characters, as well as using it to make the cockpit audio system (a.k.a. Bitching Betty) smarter.
We’ve also been moving over some of the functionality from CryAI into our system and then amending it so it works better for our requirements on Star Citizen. So recently that has included the Tactical Point System, which includes things like cover, and the Group AI system, which allows better and easier handling of multiple AI objects, especially in the visual gameplay scripts (or the flow graph, which ever you prefer!)
On the UI we’ve been doing work here for quite some time now, but have recently started taking a bigger responsibility and taking on more of the work. We’ve been expanding the team with a new artist and a new engineer. Having the new engineer means that we can now have someone concentrating solely with bringing the User Interface requirements of Squadron 42 to life. Some of the many features that we have thrown his way are to develop the interface for the Tactical Visor and Looting. These will require various augmented reality overlays and post process effects to highlight people and objects, giving the player additional information about the world around them. We have also been performing an iteration on the visor displays for Star Marine, as each of the helmet types will have their own unique look and feel which require their own their own individual UI setup.
Our new artist is currently working on look-dev’ of the ship manufacturers, in parallel with this the ship UI code is undergoing lots of planning work so it can deal with multi-crew ships and all the challenges that throws our way, such as a captain being able to delegate (or lock out) various controls to the co-pilot or turret gunner. Planning is also underway to allow players to be able to customize their display outputs in their cockpits, giving them the ability to transfer various output to different displays. All of this planning is because, to support the functionality we require, the underlying structure that the UI code sits upon is going to need a bit of a refactor. We’ve already taken a lot of the hard coded setup of the UI and made it much more data driven (using our DataForge tool), but also were changing it to make it much more flexible, so any part of the HUD can be attached to anything else in the game that can take UI. So all of a sudden moving the radar from your visor and onto one of your cockpit displays becomes easy. This is going to be awesome!
Graphics
This month the UK graphics team have been focussing on several areas in parallel. The work on the mesh-merging tech continues, and is being trialled in larger environments such as asteroid fields to ensure it can handle any number of objects. This is coming along well and will be ready for production very soon and will start being used in public releases soon to give you better performance on new levels.
We’ve got a new senior programmer who’s been working on volumetric gas cloud rendering, investigating rendering dense clouds and soft fog with anisotropic lighting (the bright rim you get on the edge of clouds). This will be a very long term task as it’s hugely complex but is something we really want to push in our game. We’ve also been looking into facial animation technology, profiling various setups to see how far we can push the technology while maintaining a decent frame-rate. This includes trying different polygon counts, number of joints/bones in the face and the number of poses/blend-shapes that each character can use. As part of this we’ve also been investigating what we could do to push the rendering of our faces, which is no easy task when you also have to support many characters on screen. We’ll hopefully be starting this face rendering R’n’D next month and look forward to sharing the result (good or bad!).”
Design
June has been a busy month for design here with GamesCom looming. We are still flat out on Squadron 42, supporting the performance capture shoot with last minute level tweaks at the studio site to make it look at as fantastic as possible. All of the levels are looking more and more polished with a steady stream of great looking building tiles coming from our environment team that are iterated on until they look fantastic, while still allowing the level designers to layout the environments in a believable way.
We had an internal “Show-and-Tell” this month as a lot of the new staff had not seen the full depth of the plan for Star Citizen and it’s safe to say that it went fantastically well, with lots of jaw dropping amazement at depth of the game. It was great to see just how much work has actually been done in such a short period.
The technical design team has grown and is now covering tasks from FPS weapon balancing all the way to getting the Vanduul fleet operational in the engine, capital ships to fighters.
The Arena Commander team have now got the “large-world” code from the engineering team and are starting to realize what can be achieved in terms of universe size, suffice to say you should be seeing the fruits of their labours soon.
The systems designers have been finalising the specification for the “multi-functional displays” in the cockpits so that the functionality can be extended across all ships and is totally scalable from single-man ships up to larger capital ships. This is another one of our urgent tasks needed for GamesCom and will hopefully be shown in more detail very soon.
We are also trying to get a first implementation of “Quantum Jumping” ready to allow a more speedy way of navigating around the new “large-world” technology, which is looking very promising.
All in all a big month for us, but I’ve got a feeling we will be getting a lot busier in the next few months. Might be time to string up a hammock in the office soon. Thanks to everyone as always.
Art
Concept Art
Biggies this month have been the Bengal Bridge update and the Mining Bot, additional work continues on the Behring Ballistic shotgun, Xi’an transport ship, Vanduul fleet and further prop concept definition to add to the Shubin mining base and a few pirate bases needed for the Sq42 storyline (no spoilers!)
Ships
The Retaliator has been worked on this month to continue getting it ready for Flight – exciting times! Argo RUV is reaching Final art (excluding the pod which needs revisions for the cinematics), the Idris is looking very good in places, can’t wait to reveal some of it. Cutlass started its new greybox taking in to account design revisions, mining bot going to texture and material stage, Starfarer – going slower than we’d like, it’s a matter of resources, and we need more talented folk to help build this ship as its more complex than expected. Bengal Bridge will start once concepts are signed off.
Environment Art
A short update this month as much of what we’ve been doing must be kept secret for now. Progress is continuing with our VS environment which has hangars, control rooms, corridors, airlocks, and exterior landing pads – all of which can be traversed seamlessly. Hopefully we’ll be able to show you some of the really cool things we’ve been working on in the not too distant future, so stay tuned!
Props
We are getting clear documentation ready for outsource, dialling in with the techniques needed for materials which causes us most problems and then next month, we should be rolling.
VFX
The VFX team have been hard at work getting more ships “flight-ready” – this includes effects for thrusters, weapons and damage. In particular, the Scythe’s effects are looking pretty badass! We’ve also been continuing to iterate on environment effects – interior as well as exterior – for the Vertical Slice. We also began to focus on Star Marine’s weapon VFX, to make sure they’re matching the overall quality of the levels, characters and of course weapons. Truly exciting times to be a VFX artist at Foundry 42!
Audio
Hey everyone! This CIG Audio community report might meander a little, there’s a lot going on but think this should cover most of the interesting parts.
Firstly, Wwise. We’re nearly there as far as our mass of asset conversion/re-engineering is concerned; at least, the end is in sight. So Stefan, Darren and I have spent some time thinking more about how to set things up so we can mix the game well. Our game is on-going, constantly being revised of course, so the strategy we need to take is not typical to that we’d pursue for a one-shot release title. We think we have the basis of what should serve us well, and we’re changing the project structure to reflect this.
On the audio engineering side, much of it is still making sure things that used to work, work again; and ironing out any more emergent bugs/foibles that are still present. A certain ironic twist to what we’re doing is that the more we get individual sounds working, across all sorts of systems, the more we’re contributing to the problem of too many sounds playing, or being processed at some level, at once. Wwise has some ways of handling this situation, but the ideal is to make sure Wwise doesn’t get bogged down processing elements that are outside the player’s sphere of interest. At the core of it, if something is too far away to be heard, then we put it into a suspended-animation state where audio is concerned, but only to the extent that we need to so that when it comes back to life, it works as expected. There are all sorts of things to consider with this but that’s where we are right now in terms of core audio engineering. It’s not glamorous I know but it will keep things running smoothly if we get this right sooner rather than later.
We have a couple of new ships coming, one of which Darren’s been working on a lot. This had to have new dialogue recorded for its ship computer too and he’s been looking at the UI aspect, designing sounds and seeing how best to get them in. So much game UI these days is based somehow in Flash and that can be problematic for implementing sound in a way that we can iterate upon easily. So while we’re doing that we’re thinking of ways to improve this pipeline.
Incidentally, regarding the Origin ship computer, I’m holding my hands up on this one and admitting I failed to capture the previous essence of what made the ship computer so great for the Origin models. Basically, we’ve listened to you and absorbed the feedback you provided regarding the new one – and I’m absolutely determined that we’re going to win this one back. I’m not happy with it and this will be fixed!
Persistent Universe. We can’t say too much about this as yet but been ongoing support for the environmental audio for this.
FPS. So much of this is tied up in Wwise, there’s been plenty of new content required for FPS in terms of weapons, character Foley and dialogue and that’s coming along nicely. We’re getting a bunch of new music content down for FPS too. Thus we tested out a workflow where our composer, Pedro Macedo Camacho, works from his studio within Wwise, and we import what he sets up of his music into Wwise at our end. It’s not practical in terms of logistics to provide access to our own Wwise project (which is growing all the time), so testing out this workflow where he passes us a project file, has proved really valuable.
It was actually surprisingly easy to import his work-units into our Wwise project, and made me think that this might be an avenue for those of our modding community who wish to import their mods/material into Star Citizen. New assets could feasibly be produced by modders within Wwise, then passed to us for integration in the Wwise project, thus we export to sound banks etc. and pass the event triggers back to you for use. It might be a little unwieldy on the face of it, but I think ultimately working together with the modding community is the way to go to ensure a quality experience, and I’d love to try this out.
Arena Commander (or dog fighting module); a whole host of material has been converted, or some cases entirely re-created to work better than before. As Audio Director I don’t often get to do much sound design at the moment, which is obviously something of a shame as it’s what I am, at my core. So it’s been so good to be able to fit in some time for working on some ship thruster stuff and contribute in a material way to some thruster design! Luke’s taken what I’ve done and fixed it up a bit too, he’s very into the spaceship audio aspect of our game so that’s been reassuring for him to fix up my implementation. Generally a lot of this material is taking up time for all our sound designers, as it’s the lion’s share of Star Citizen right now there’s simply a lot to do but we’re whittling through it nicely.
Re: dialogue support for the Squadron 42. Our Dialogue Superman (not an official title) Bob Rissolo has still been hard at it down in London. It’s wrapping up soon, at least for now, which means he’ll be moving in-house permanently here to Foundry 42. A big move for him, we’re still hugely grateful he’s swapping sunny San Diego for the more, well, variable climate of Manchester!
Regarding our sound studios. By the time you read this we’ll have actually had our new doors installed for these. I know, doors seem like such an obvious thing to have, and of course, they are when you’re trying not to assail the rest of the studio with FPS gun sound effects, explosions and the like. But we’ve been waiting a while for a particular set of doors to be manufactured, simply we’ve been on the wrong end of some manufacturer-side production issues with them they’re each a different colour. I know that seems frivolous but when you have a number of isolated rooms and coming from another discipline, it saves time to be able to direct someone to the ‘orange sound studio’ rather than specify a room by who may or may not be there. Also means we can swap rooms to some extent. My own room is going to be a reference room for the rest of CIG Audio to test our surround mix, for instance.
Right now, tools improvements is something we’re considering. The better our tools, the easier it is for us to keep improving things. Wwise is an event-based system, and is reliant on external events of some form to trigger sounds in certain ways. For instance we want to trigger certain one shot-sounds when a thruster is transitioning from zero thrust to full thrust, on top of what we trigger for thrusters generally. And then trigger different one-shot events when the very same thruster transitions from full thrust back down to zero thrust. This is actually something that’s tricky to do ‘in the box’, the box being Wwise in this instance, so we want to be able to set-up these events more easily as sound designers rather than as programmers, so there’s a whole tool-set that we’re considering for defining logic to cater for this. This is just one tool out of many we can see a real need for.
We’re arranging to go back down to Pinewood, to record a whole bunch of duress elements for the ships. You might recall that they’ve worked with us on character Foley for FPS. There’s a new library of this sort of rattling, bone-shaking material that we’re also looking at (you can never have enough source) but we also want to make sure our stuff is that bit more individually tailored to our requirements. We’ll be taking down the Butt-kickers for this, for sure.
I’m sure there’s more stuff I’ve missed from this update, do feel free to ask us more on the Ask A Dev part of the community forums and we’ll continue to do our best to respond. Thanks for listening!
QA
UK QA have had to split our efforts this month to deal with the upcoming major events and releases. Star Marine (the FPS module) plus preparing for Gamescom, are on the cards for the near future, and Squadron 42 testing continues as normal.
Star Marine has had a lot of focus in order to root out major multiplayer bugs and try to find any general polish issues. Glenn Kneale from the UK and Tyler Witkin from ATX QA have been collaborating to make sure this game mode gets thoroughly tested. There’s been a lot of cross studio stress testing to help ensure that it should be stable once it gets released.
We’re focusing quite heavily on testing the sections of the game that will be shown at GamesCom. Unfortunately not too much can be mentioned there, but we’re all very excited about how what’s currently planned to be shown will be received.
Finally Squadron 42 is getting more testing time dedicated to it, as the game progresses we need to ensure the new mechanics are and alpha level run throughs can be completed. We also spent some time creating some more documentation to address our current plans to expand testing on S42.
Steven Brennon has continued to compile feedback from you guys and making sure it gets appropriately compiled and sent to the relevant people.
Sadly we’ll also be losing Chris “Chill” Hill at the end of the month. We wish him all the best as he’s been simply fantastic since he joined us last year, but looking forward we’re training up Steve Brennon to be a replacement lead.
June has been a busy month across all disciplines, and the team is building up in momentum. A large amount of strong applications have come in this month and we’re slowly getting through them 1 by 1. We continued to plan out our new office space, all things are set to get the keys to our new permanent office July 1st. We’ll make sure to share the new location with everyone in case anyone wants to stop by and say hi, with advanced notice of course.
Engineering
In June, Frankfurt Engineering deployed to the main codebase some major items that were planned for this month. As mentioned in the last monthly report, the Large World (moving the codebase to 64 bit coordinates), Camera Relative (rendering coordinates relative to the camera thus allowing galaxy size rendering without loss of precision), Zone system (the new Star Citizen spatial partitioning scheme, replacing Cryengine Octree) were close to hit the Star Citizen code mainline and have now been deployed, and will find their way into the various Star Citizen game modules soon.
The integration of relevant CryEngine 3.7 SDK parts, combined with our new changes, is being deployed into our codebase as we are writing this. Additionally a large effort this month was spent on supporting multi-crew vehicle ships: local physics grid, physics debugger, entities and prefabs, support for new 3D VisArea shapes, all this combined with the Zone System, are being worked on in the context of operating moveable ships. Amongst the other things, the multi-crew development process exposed a few bugs and incorrect functionalities that have been living in the CryEngine codebase for years …
We continued to work on optimizations, improved storage formats, bug fixing, clean up and general engine support to other CIG studios.
AI
During June, the AI development team has been focused mostly on the basic systems required for the human character to navigate through the full game world.
We completed the first pass on integrating the CryEngine MNM Navigation System and the multithreaded MNM Pathfinder. We also have completed the first pass on interfacing CryEngine Movement System with the current behaviour tree system. The Movement System takes care of analysing a path returned by the MNM Pathfollower and creates a plan on how to execute the movement.
Let’s imagine a character that needs to move into a cover position, the NPC will have to follow a path until the cover spot and then enter the right stance to actually position himself behind cover. The movement system allows us to have the proper context from the request to the execution of the movement, so that we can predict the necessary step the NPC has to take to correctly end up in a “behind cover” position.
We are in the middle of integrating the CryEngine Tactical Point System with our new behaviours. The Tactical Point System (or TPS) is a query system that allows us to query special position with specific properties.
In addition to the development of the systems we are taking care of creating all the glue code between the systems to allow the NPCs to have the best looking quality.
And we are also continuing coordinating the improvements on the Kythera Behavior Tree and its integration with Dataforge.
Design
This month the DE Design team has spent much of their time working on four initiatives: building a level for Squadron 42, assisting with the FPS module release, building AI behaviour trees for FPS, Squadron 42 and the Persistent Universe and then working with the UK team on Squadron 42 level feedback. We’re reviewing the missions and encounters they build for pacing, use of mechanics throughout the level, level flow and moment to moment gameplay ideas.
Animation
Currently the DE office only has 1 animator, fully focused on supporting cinematics. This month they worked on starting to set up scenes for scripted events and in-game cut scenes, getting pipeline tools identified and documented and a review of the Squadron 42 script (with the Cinematic director) to sort out which scenes will be owned by cinematics.
Cinematics
Hannes is back from the long cinematic shoot. He’ll be able to contribute to the monthly report starting next month. They had some truly talented actors on stage that gave amazing performances. We all internally look forward to pulling these together, as I’m sure the backers do as well.
Audio
Not much new for audio this month, still working on Wwise conversion that started last month. Hooked up the EVA thrusters and Ship Shield impacts to use the Wwise audio system, fixed several audio-related bugs. Started work on improving the distance-based culling of active sound emitters to let the sound designers create more detailed soundscapes without overloading the sound engine.
Build System
In June our Senior Build engineer visited our Austin studio (ATX) for 3 weeks and worked close to the Dev-Ops /IT teams on many aspects of our builds process, optimization and cross studio delivery. Among many things, the main goal was to reduce the amount of time it takes to put together a build, make patches, deploy servers and so forth.
We’ve decided to move away from the current build system in favor of something that we are confident will give us much more customization capabilities to better tailor it around our game’s needs. This is still work in progress, a lot of work has been done, and even more will be done in the next upcoming weeks.
VFX
For the past month we have been working hard on various squadron 42 effects. One of these effects has been a giant plasma drill. It is used to break up asteroids into smaller pieces for resource extraction.
Greetings Citizens!
Another whole month has gone by and we have been busy!
Engineering
As usual, a portion of the team has been focused on development for short term deliveries such as support for FPS Lobby & Flow. We’re also slowly moving away from that, now that it supports most of what we need for the first version, and have been starting to add support of multi-crew ships in the Lobby UI.
The month of June has brought us a few great features from other studios which has allowed us to work in tandem in order to add a bit more functionality to online hangars. We’ve been working hard on the current Holotable implementation in order to reduce the need for ships to be spawned in the game for them to be used in Arena Commander. This will allow us to reduce loading times as well as to facilitate management of server hosted Hangars. We have also been reworking part of the flairs implementation and Hangar spawning to work properly in such a context.
The planetside experience hasn’t been left to itself either as we’re still working on adding some features and a level of polish to the Augmented Reality (AR) experience with mobiGlas as well as the shopping experience as a whole.
Design
The design team has been setting up elevators and doors for Nyx, as well as setting up various functions (such as dynamic spawning, mobiGlas AR tags, and text string localization) for the items that will appear in Casaba outlet. We have also been doing follow-ups on the shopping experience, flair objects, and Level Design blueprints for Hurston, Crusader, and Microtech.
Art
This month we did a lot of work polishing for the Nyx asteroid map, improving materials/textures and dressing the environment to ensure that each room has a story to tell. We’ve also worked on improving one of our previous maps, modifying its layout to optimize navigation and improve performance.
Additional efforts were done on our shop system. We’ve added details on how clothing will be placed on the shelves to allow for good visibility from the player’s perspective.
Finally, as always, we’ve completed next month’s Flair object. Enjoy!
UI
The UI team has been doing quite a bit of spring cleaning (never too late!). We have been working on a thorough pass of the new holotable design flow to smooth out the whole user experience and to unify the various screens. Same goes for the simpod interface (also known as Electronic Access). We have also been cleaning up a lot of low priority tasks that have slowly and steadily been piling up.
Till next time, Citizens!
Hello Citizens!
Another month, another update. Quite a bit has happened over the last month. At the moment we have three guests from CiG (Sean Tracy, Steve Bender and Jason Hutchins) visiting us in Denver and helping out any way they can. We are currently focused on getting core locomotion as solid as we can, while still having the animations look great in both 1st and 3rd person. This isn’t easy by any means, which is why we have the extra reinforcements! You can find additional updates on the FPS module push in the weekly Star Marine update.
Engineering
Over the last month, engineering has been primarily focused on core locomotion and the start/stop/juke system. This has been close work with animators and designers, working out all the edge cases, and trying to find the absolute best balance between control response and animation quality. Everything then needs to work and be polished for both 1st and 3rd person modes. In addition to core locomotion, they have also created rules for Star Marine so that it reports stats in the same way that Arena Commander does for leaderboards and the accruement of REC. Lastly 5 different movement speeds were implemented. This makes moving with a controller very fluid and variable, depending on how much tilt is being applied to the stick.
Animation
The animators have all been laser focused on getting everything looking as good as possible with starts/stops/jukes. This has mostly involved a very quick feedback loop with Steve Bender. Getting his feedback, making tweaks and sending back the results until everybody is happy. It is a lot of work to be sure, but the team here is doing some really good work and the velocity of that work increases almost daily, now that the processes have been figured out.
Art
The art team has been working on optimizing all of the asset pieces for the Gold Horizon Station set, along with tweaking assets to match up with the metrics that are being used over at Foundry 42. This isn’t exactly the most interesting work, but it is something that needs to be done in the long run for persistent universe and Squadron 42.
Design
The design team is making numerous tweaks to the Gold Horizon level at the request of CiG. This includes some tweaks to ammo & energy placement locations, removing some doors and changing the behavior of others through the level. In addition, they are also tweaking the lines of sight throughout the level, and doing a polish pass on cover placement.
That’s all I have for you Guys and Gals this month. Until next time!
Here’s what we’ve been up to in this last month up here in Montreal:
Jump Point interview
First of all, this month our team had the opportunity to participate in an interview for an issue of Jump Point. This gave us the avenue to discuss some of the projects that we have been working for Star Citizen and shed some light on what is coming next. Thanks to David Ladyman for allowing us to go into a bit more details (and in a slightly more informal way) about our process for redesigning the site’s global look.
Starmap
This month, we completed the main art for the Starmap viewer, including Galaxy and System views. In terms of the interface, we made some significant changes to the HUD as well as filtering options (sensors and heat grid).
On the data side, we made good progress on data modeling for the upcoming Galactapedia. We also worked on our own administration tools so that we can import data from the Star Citizen universe. This will allow for having all the data of the different celestial objects already in a Galactapedia format.
On the 3D front, we started production of the different assets that will be displayed in the WebGL viewer (planet, jump point, space station, etc). This is very work intensive and it’s what the user will see on their screen, and so we’ll be working on this for the next couple of months.
Issue Council
As reported last time, we have continually been evolving the Issue Council to ensure that it greatly reduces the amount of time/effort for everyone involved. We have also been working to make sure that it cannot be easily swayed by large groups of users (such as organizations). We have been adding new features, re-organizing layouts, moving things from one page to another, removing pages, and so on — so much so that when we took a step back and looked at it all we realized that the UI was no longer intuitive. So we gathered the team around a big whiteboard and worked on fixing this.
The core update we worked out was an updated flow for the users. Upon arrival at the Issue Council, users will be provided with three ways of approaching the system:
Contribute by attempting to replicate issues and flagging invalid tickets (duplicates, feature-requests, poorly written, etc).
Prioritize the confirmed tickets to help the developers know what is important to the community.
Search all tickets that have ever been created.
We will soon have some designs to share, but to give a bit of insight here’s a photo of one of Benoit’s whiteboard designs.
Community Hub
The Community hub has entered its final stretch, and our developers have been working on actually implementing it for the whole month. The main notable undertaking on this specific project was to set up the submission flows. These will allow you to upload pictures and galleries of your own creations, embed your youtube play sessions, or report interesting links you’ve found elsewhere, which requires a great deal of technical flexibility from the website itself. Even more interesting was that we took some time devising filters and sorting algorithms based on the amount and frequency of content posted and their popularity through upvotes and comments. It’s always an exciting challenge to devise the way a website will display its own content, to keep it as relevant and fresh as possible.
Moderation tools
Another project that we have been working on, which has recently launched, was the new Moderation Tools, for the site’s dedicated team of moderators. These tools now give them more insight into flagged contents, repeat offenders and infamous recidivists, as well as a quicker way to manage forum access. This allows them to keep the forums, comments and Orgs running even more smoothly and efficiently. With their help, we’ve devised a set of tools that will then be expandable to cover all user-generated contents, including all aspects of the upcoming Community Hub as well.
This month’s concept sale was a short story showcasing the Genesis Starliner as operated by Meridian Transit. This quick tear-jerker (go read the postcards) was written by Star Citizen’s own writers, and along with some pretty cool art and voiceovers from the Community team, it gave us a lot of room to have fun with the post. This is why it quickly became one of the site’s most script-heavy pages, with mini components like the Flight board or the flipping postcards. The flight board itself was based on a very early concept for the Events block on the website’s homepage, which we were really fond of but put too much stress on browsers. So we were really happy to be able to use it anyway as part of the short story.
What you didn’t see
Just like for any other month, our programmers were also tasked with improvements and fixes that have gone unnoticed, thankfully. Prominent this June were the payment processors that we use : Amazon migrated their whole payment system, which we had to adapt to, along with transitioning to an entirely new way of handling subscriptions. Another one that shall remain unnamed cough*paypal*cough also had some interesting surprises for us that we had to react to very quickly. We’ve also dedicated some time to providing new tools to the Customer Service team, to help them deal with problematic cases even more efficiently.
It’s been another busy month at Moon Collider, so let’s jump straight into it:
Engineering
It’s a well known saying that no plan survives contact with the enemy, and I think an equally valid saying would be no tool survives contact with the designers! No matter how well you design any new tool, the moment designers start playing with it you’ll find out very fast what needs improvement. Last month we gave designers the ability to write behavior trees using an editor built into DataForge, Star Citizen’s custom data management tool. We tried to get it into designer hands as quickly as we could, so we already had a decent sized todo list of improvements we knew were needed, but a few hours of real use of a tool by a designer always helps to clarify which issues are minor annoyances, and which ones frequently interrupt their workflow or straight up make them unable to do some task.
We spent some time this month getting feedback from designers and working through their prioritized list of issues with the new editor. This included things as simple as writing up more documentation on how certain features worked; renaming, recategorizing and recoloring BT nodes in ways that are more intuitive to a designer; and even moving certain advanced pieces of functionality out of the standard workflow so that it’s a little more laborious to use those rarely needed features but it makes the common features more streamlined. We expect to continue improving this tool next month as the feedback from designers keeps on coming through.
With the designers now working on behavior trees with DataForge, it was also perfect timing for adding a behavior tree live view to our Kythera Inspector web based debugging tool. This is a web page that designers can bring up that gives direct access to the state of the AI in their game, and we’ve been constantly added features to it in order to make debugging AI easier. Up to now we’ve been relying on some simple on screen text debugging to help us understand the current state of an AI’s behavior tree, and while this worked reasonably well for a small and simple tree, it was much less useful for larger trees, and also limited in the information provided.
The new live view in Inspector allows designers to see the state of the behavior tree of any AI while the game is running. We have some new features coming next month that will allow this view to help them track down configuration errors with their trees, which, when combined with the already existing ability to record and play back the behavior trees of the AI, should give designers a comprehensive suite of tools for debugging their behavior trees.
One issue we’ve been trying to sort out for a while is a technical feature we call a string hash. This is something that is built into Kythera and basically allows us to convert any text string in the code into a numerical identifier at compile time. This makes it cheap and efficient to pass strings around in the code and use them without worrying about it being expensive to do comparisons, which is usually the case with strings. And this means that you can have a lot more descriptive text being passed around in your code rather than simple numbers, which can make code that’s easier to work with and easier to debug.
Because this is such a useful feature, a similar version has been added to the rest of the Star Citizen codebase. What we’ve been trying to work out is how best to unify these two different versions of string hashes, so we can avoid the cost of converting between them. There are various details that make this trickier to solve in a satisfying way than it might initially seem, so we’ve been spending time working this out with coders in some of the other studios and are currently testing some possible solutions to try them out and see if they cause problems in practice.
Now, let’s talk ships!
Last month we added in the feature that allows ships to reliably join splines. This month we started making good use of that feature in the form of retreat stunt splines. Stunt splines are paths that are laid down by designers in a level and allow AI to fly through tight areas where their collision avoidance would otherwise stop them from going, such as through a tunnel in an asteroid or gaps between sections of a space station.
One of the main goals of these stunt splines is to set up opportunities for players to chase AI through interesting and exciting paths. We’ve added them to AI retreat behaviors so that when an AI ship wants to break away from a pursuer, if there is a stunt spline nearby it will try to make use of it. To keep things believable, the AI will only pick a spline if it can get onto it quickly, so they won’t use one if it requires a major change in speed or direction to get to it.
We can also use them to distinguish elite AI pilots from rookies by having a skill level attached to the spline. So a really hairy maneuver can be marked as only available to the best pilots. This also means that if you go to chase a fleeing elite ship, you may find yourself in a chase that you’re not good enough to pull off, and you’ll need to make a quick decision on just how crazy a pilot you’re willing to be!
Once designers have had a chance to work with this feature, we plan to make some refinements to the spline selection process to get a good balance so they’re not overused or underused. It’s important that the AI don’t become too predictable to a player who is familiar with a map, but on the other hand, seeing a ship break off and head towards that tunnel you know is great fun to fly through can be something to anticipate as well.
As is always the case with new features, we’re looking forward to seeing this one get into the hands of real players and hearing the cool stories that come from it!
Greetings Citizens,
We always say that it has been a busy month for the community team, but at this point… what month isn’t busy?
We were very happy this month to celebrate the first anniversary of Around the Verse! AtV has been an interesting project for us; last year, we went into the s how dreading the need to replace fan favorite Wingman’s Hangar… and we took time to find our feet and figure out what was important. Thanks to your feedback (and your support!) we’re proud of what the show has become… and we’re going to try and keep making it better. Episode 50, aired last week, had one especially standout segment in which designer Randy Vasquez showed his process for building Starliner interiors. Expect to see more segments like this in the future, as we felt it was our strongest piece yet.
We’ve also asked the community team to be more interactive on the forums. We’re just as eager to see Star Marine release as the rest of the community, and we’re going to do our best to get out there and not just show the flag but share our answers and thoughts with all of you. A Community Manager can’t always answer your questions… but we’re here to address what we can and also listen to your concerns and make sure developers are aware of them. Even better, we’re working on a relaunch of the ‘Ask a Dev’ process, which will hopefully result in a system for getting your questions answered by the experts.
The whole team also had a field day with the Genesis Starliner sale. We wanted to get across just how much depth there was to the ship, and the whole team worked together to add pieces to the presentation that we thought would interest the community. From Jared’s postcards to Ryan’s safety card, we wanted to show you more than just how big the guns were (and if we’re being honest, the guns are not that big in the first place.)
Finally, we’re very sad to lose one of our own: Chelsea Day, manager of the Customer Service team, has left CIG to relocate. Chelsea was a good friend and a great CS manager; we’re all going to miss her! Patrick Probst, who you may have seen on the forums, will be taking over the CS manager position in the UK. So congratulations – we know you’ll live up to the example Chelsea set!
Summer is here (in the northern hemisphere, anyway) but we aren’t on vacation: big things are happening at CIG! Watching from the inside, it’s gratifying to see the moving parts that will form Star Citizen starting to come together. Important pieces of long-talked-about technology, like large world maps, are coming online internally and there’s an air of excitement among the development teams as the reality that a lot of what we’ve been planning for and working towards is finally happening sets in. We’re eager to share our progress with you, which means a push to get not just the Star Marine FPS module out, but to start sharing more about multicrew and the persistent world. Watch this space! As always, we’ve asked our project leads to put together individual reports for the community to let you know exactly what every part of the company has been doing. Read on!
Hey everyone! It’s been an amazing month chalked full of exciting work here in sunny Santa Monica. We love sharing with you everything we’ve been working on so enjoy and always let us know if you have any questions or thoughts!
Engineering
Our engineering team has been really busy this month. Everything from datastore clean up to the new character material system creation to large world updates. So let’s dig in:
We did some early implementation of the vehicle parameters where we were off loading the vehicles from parsing an xml on every spawn to parsing a single xml once and using it from then on to build a vehicle. Also, the only way we knew how to build a ship is to spawn it then look at what it contains. Now, other systems can just look up the parameters to build out a ship. We no longer need to spawn every ship below the hangar which was a massive change. We also had lots of integration bug fixes for FPS & Arena Commander. We continued working on the Radar 2.0 system where we moved the system from entity-only-based to practically anything the designers need to show on the HUD. The back end work is built, now we need to change HUD and other vehicle components to handle those objects so the designers can go nuts! We also did a lot of vehicle code clean up by deleting unused code which sped up a lot of the slow bits but this is going to be an ongoing process.
UI has been working tremendously hard on upcoming ship designs and implementation. Specifically, the glitch effects and boot up for the Vanduul. We reviewed a proposal for improved cockpit interaction and began preparation for HUD to support different seat actions and roles.
We’ve been doing some datastore cleanup, removing duplicated code, unifying different spread out code into single pass, and began preparation for Multicrew spawning/MP hangars. We separated object spawning from player spawning to move Hangar loading into level loading phase.
We’ve also been working on multi-layer material system. The goal is to end up with a fixed library of base materials that are blended together (up to 4 layers) to create more complex materials with minimal draw calls. Texture library and core shader functionality are mostly done, now working on the base material library that would bridge the render resources with the blended materials.
On the AI side, we’ve been doing a lot of ship bug fixing, particularly in regards to the pilot an AI ship creates and maintains. We also did a bit of work on the “defend target” wingmen command, creating an AI ship aspect that keeps track of nearby threats so that escorting ships will know what to attack.
On the Large World side, we fixed various trigger area issues in LW maps such as removed the +/- 16km limit for all the trigger areas and additional boundary conditions fix-up. We did a bit of interface clean-up for Matrix34 / Quat and established the prerequisite to make the rotational part of all those primitives to float. We also fixed the position info bar and GOTO position dialog and increased camera move speed in Sandbox while authoring LW maps. Lastly, we finished thread-safe texture loading with thread-safe shader parsing and thread-safe shader resource creation almost done. Phew, we had a great month and are looking forward to more!
Design
The design team here are keeping incredibly busy with all the upcoming ships, modes, gameplay needs, and so on. One of the bigger focuses for us was on the Genesis Starliner. We wanted to make sure we thought everything through to be ready to bring this awesome ship to you. We had a lot of work to get through this month such as establishing the initial gameplay balance plan which includes potential updates to stats, features, game modes, hud, controls, missiles, etc. Here are some of the in-depth details of this month:
We fixed an issue with the RSI Constellation Andromeda where the old Hangar Ready version would crash the hangar. Oops! We also switched the main elevator entrance from being a door to a switch to allow for entering/exiting via different doors without resetting the animation states. We also fixed both upper and lower turret hand positions. Also, in an effort to make the Constellation flight ready we overhauled thrusters.
For the Scythe dogfighter we dove into an issue in which the multilight was not loading into the light port and the archetype was crashing the client. We also removed unnecessary AI Space Ships and updated the Scythe to utilize “Scythe_Swarm” modification block to adjust AI Scythe health.
On the Hornet F7CM, we fixed an issue in which one of the thruster hard points was misnamed, preventing the thruster from loading onto the ship. We also combined the bound geometry and Weight Transfer Tool while refactoring controls design quite a bit.
On the Mustang Delta, we removed inclusion of default animations, which were colliding and causing problems (such as misplaced hatch and open/close animations not playing). We also implemented the AEGS Retaliator enter and exit Pilot Seat and updated the Interiors to use latest from Production level. That’s quite a bit of how our month went and are ready to go for the month of July.
Art
Overall, it’s been a very busy month for our art team in Santa Monica. Specifically, the vehicle artists have been busy focusing on the Merlin that just went through its final art pass and delivered to design to get flight ready. In addition, our Senior Vehicle Artist, Paul Forgy kicked off the first stages of getting the Bengal Carrier exterior white boxed and in the game engine. Can’t wait for those capital ships! With the new damage tech coming online, LA artists have been working hard to make sure the flight ready ships support the revised system. The Scythe is one of the first and has been setup for full damage support. Be sure to look for that in the near future. Now that’s not the only update to the Scythe. The ship’s cockpit has been retrofitted for human flight. Be expecting that in AC soon!
Alongside our ATX comrades, the LA studio has been working on revamping characters for not only the FPS, but for characters across all modules. Omar Aweidah is nearing finalizing the first gold standard to fully utilize the new character shader tech powered by Multi-LayerBlend written by our very own, Okka Kyaw. Now, we are ready to step up the character’s visual fidelity and take the massive leap into the future of character development for the Star Citizen universe.
Speaking of characters, our Production Designer of character concepts, Rob McKinnon is really ramping up our concept development quite heavily. We’re making great strides in developing looks for the characters of Star Citizen. 3D sculpts provided by Rob McKinnon and his team have given us our first 3d look at marine uniforms. Whether it’s a bridge office or a BDU, the marines are looking top notch. The Navy has tons of roles and responsibilities and we now have an outfit for each of them. From Officers on deck, to medics on call, the Navy uniforms are sharp and ready to begin 3d production.
With all the excitement of getting to ride the Meridian Transit, we have made sure you weren’t without a drink. The Genesis Starliner now has the very first concept designs for flight attendants. Also, the Vanduul just got a lot tougher with new images created from the concept team showing off new armor sets. The Vanduul now look meaner than ever. Under the armor has gone through revisions to attempt at finalizing the skin of this Alien race.
And that does it for the Santa Monica studio update for this month. Thank you so much for taking the time to look over all of the team’s hard work and supporting the creation of the game. None of this would be possible without your continued support and we’re honored to be able to make this game with you. We value your feedback and thoughts so keep them coming.
Hi Everyone!
It has been an unusually rainy and cool June in Texas and we’ve been enjoying it. We have hosted a number of visitors from other studios this month and we’ve been very focused on a number of different production priorities. We’ve made good progress on a number of fronts, and have a lot more work to do on the hard push to the end of the summer. Here are some detailed reports from the head of each team.
Persistent Universe Team
Art
This month the PU Concept Art Team spent the majority of their time fleshing out details of major features of the game. Ted Beargeon and Ken Fairclough crafted pieces that defined hero props for the Nyx>Delamar>Levski landing zone. We sent concepts of statues and large machinery over to BHVR to take to modeling. Likewise, some time was spent on fleshing out the Levski market area to help define the shopping experience there, as it will be different than anything we’ve done so far. Megan Cheever spent her time this month doing detail passes on various concepts of military personnel. She helped define the badges, medals, and materials you’ll see in the final game. Megan also concepted the flight attendant characters you saw in the Starliner sale this month.
Our PU Environment Team has been wrapping up the final detail passes on Levski as well. Lee Amarakoon and Emre Switzer have been providing VFX and Lighting support, respectively. Levski is beginning to look properly dark and gritty as a result of these guys’ work. Lee also got to work on revising the Customs Scanner effect you saw shown off at CitizenCon last year. Our Environment Leads, Cort Soest and Patrick Thomas, have been working with BHVR to optimize the environment itself and bring it the last 10 percent to completion. Next month Levski should be wrapped up and ready to show off somewhere down the road.
The Stanton>ArcCorp>Area18 landing zone has also been a huge focus for us this month. The environment has undergone some layout revisions to aid in optimizing it for release with the Social Module. Mark Skelton has been working in tandem with Tony Zurovec to provide direction for the changes. This environment is going to look better than ever as result.
The Character Team here in Austin just recently wrapped up the SATABall character and helmet, and it looks amazing! This was one of the first characters we took from start to finish utilizing our new Next-Gen Character Pipeline, and the new techniques have proven effective in making stellar characters for Star Citizen. We look forward to showing off David Jennison and Billy Lord’s work very soon!
The Austin Animation Team has had their hands full in several different areas of the project this month, per usual. We’re wrapping up work on the new female skeleton this week, which will allow us to finally get some ladies into the game proper! We’re also supporting Illfonic in implementing and polishing FPS animations, as well as polishing animations for Social Module. In addition, we’re working on standardizing animation templates for ship cockpits and enter/exit sequences to cut down on ship modeling time going forward. One thing you should see fairly soon are the updated G-Force animations in the cockpit. Jay Brushwood, Sean Tracy, and Jeff Zhu did a fantastic job bringing those to the next level.
Design
This month the PU Design Team spent much of their time brainstorming and fleshing out designs for upcoming player occupations in the PU. With Tony’s guidance, we have revamped the initial designs for the Bounty Hunter, Mercenary, and Piracy occupations. We’ve also drafted up designs for Smuggler and Search&Rescue occupations. The big one this month though was the Passenger Transport occupation designed by Tony Zurovec. If you haven’t had a chance to read the post from the Starliner Sale, you should totally check it out HERE.
Another thing our designers have been doing this month is testing out the new Usable Editor. The Usable Editor is part of Tony’s “Subsumption” peaceful NPC AI system. It’s the first major step towards achieving Tony’s vision for how NPC’s will interact with objects in Star Citizen. It’s been an iterative process, with the designers playing around with the Usable Editor and giving feedback, gameplay programmer Tom Davies adjusting based on that feedback, and repeat. We’re excited to see the Usable Editor in action for the first time and testing out how far we can stretch its limits.
Lastly, we are starting to dive in to the initial layouts/designs of the next planetside landing zone we want BHVR to tackle after Levksi. We’re focusing on another planetside landing zone in Stanton, going back and forth between Hurston, MicroTech, and Crusader. Which landing zone do YOU want to see come online next?
Engineering
June was spent continuing progress on a lot of longer term tasks, as well as planning and support for our upcoming releases and Gamescom demo.
There was a lot of focus on investigating ways to optimize server performance and we made some great progress on that front for upcoming Arena Commander, FPS and Social Module releases. As reported last month, our Generic Instance Manager (GIM) is in the works and incoming. The GIM will be a huge revamp of our party and matchmaking systems and it will go through multiple iterations until we’re happy with it. This first iteration has been with our QA team and they haven’t been shy about sending us bugs. We’ve been handling them quickly and getting closer and closer to what will eventually be GIM v1.0. We’re excited to reach the point when we can share it with you all, and it’s a highly anticipated system here within CIG.
Over at Wyrmbyte, in addition to being an important contributor to our server optimization investigation, they’re been deep in their iPredictor code…working diligently on hammering out the remaining kinks. Meanwhile, our tools team has been super busy with bugs and tool feature requests to help our team make the game. They never get a free moment as there’s no shortage of tools requests…and they’re happy to deliver! We also have some game-play programmers continuing to work on some proof-of-concept functional prototypes for some ofour occupations. It’s exhilarating to start seeing the early formulations of what will end up as our occupations in the Persistent Universe.
So unfortunately it’s a bit shorter of a report this month. However, it’s not due to anyone sleeping on the job, the team is mostly on long term tasks and have been making great progress on them! Many of these hope to be rolling out to you in the coming months.
Stay tuned!
Live Operations
QA
This month Star Citizen QA successfully conducted three cross-studio FPS playtests with development. Tyler Witkin has done a great job coordinating the playtests and gathering subsequent feedback.
Automation development has ramped up. Melissa Estrada and Tyler Witkin are using the Sandox Editor and Flow Graph Editor to build levels that utilize what’s known as the Feature Tester. These levels will be used to automate various ship and FPS related functionality testing.
Thanks to very informative feedback from Senior Technical Designer Rob Reininger, we have significantly improved our editor testing to include more tests related to tools and level design.
Social Module and Planetside testing continues thanks to the efforts of Todd Raffray. As soon as a system or tool is developed, Todd ensures it is added as a test case in our comprehensive Planetside testing. The latest addition is the Usable Editor. The Usable Editor is utilized to give NPC’s the ability to interact with objects. The Usable Editor is a big part of the overall Subsumtion (Peaceful NPC AI) System.
Jeffrey Pease is ensuring that the General Instance Manager is properly tested during its official implementation into Alpha 1.2.0. The General Instance Manager is our revamp of the back end lobby and matchmaking systems. Jeffrey is also leading an investigation into the prevention of potential hacks and exploits and has provided very valuable information to our engineering leads who now have a plan of action to address these issues.
Congratulations to Andrew Hesse who has transitioned into the role of QA Lead for the Austin Studio. Andrew has done an amazing job testing all aspects of the game and has been a huge help to our ship technical designers as our resident ship specialist. This month we welcome our newest addition to the QA team, Andrew Rexroth. Rex has extensive QA experience and is already a huge help with specialized Star Marine testing.
Next month, we will be continuing our testing of Alpha 1.2.0 while also looking towards testing multiplayer hangars, significantly larger play areas, the multi-crew system and much more.
Game Support
The month of June for Game Support was spent largely on designing, reviewing, and building infrastructure and processes that are going to help our backers on a service-wide level.
Particularly helpful will be our system-wide administrative broadcast tool which will allow us to provide a communication method to all players connected to a live service, which is essential to informing you with up-to-the-minute information while playing the game. We’re also working on replacing our current forum-based Live Service Notification page with its own webpage, which will ultimately include a Server Status page for all environments (Arena Commander, Star Marine, PTU, patching, etc.) and gives us an effective tool for communicating the health of the service to all players.
We’ve also continued to help triage the issues from May’s 1.1.3 release. We’ve identified and communicated the issues from the current release and actively worked with Production to get these issues highlighted and fixed, including some of the missile and ship damage state problems that we’ve been seeing.
Lastly, we’ve begun and flesh out ideas and designs for what we’re going to need to support our different environments, and particularly the Persistent Universe. Supporting gamers usually depends on the type of game, but Star Citizen will have all three (singleplayer, multiplayer, and PU)! We’ve begun to ask ourselves: What technical inefficiencies do we have in supporting our players today? What will be the expected behaviors inside the game, and what will they require from us as a service? How do we manage the raft of attempted account takeovers that occur in every PU, and what tools do we need so that players can protect themselves? How do we manage the players’ ability to go onto the secondary gray market without completely restricting it?
We don’t have the answers to all of this today, but we’re heavily invested them. These are important questions to ask in the formation of any online community, and especially the BDSSE!
IT/Operations
June has been an exciting month for the IT team. We’ve continued to make performance optimizations to our build systems and while each improvement brings great pride, we feel like we’re getting to the point where each new improvement, while important, bears smaller and smaller gains. Not all gains will come from hardware though so we’re again working closely with certain members of the DevOps team to reduce the size of data we’re moving and just as importantly reducing the number of times we need to move data. One of the remaining challenges is our asset build system. These are the graphical assets that must be rendered for each build and with the fidelity targets we’re working with, this is a very big portion of the build process. This month we’ve started the work to break that job in to many smaller jobs so we can run more of this work in parallel in order to get the overall build time down for this portion of the build. The DevOps team manages the build system logic and the IT team supplies the hardware for the jobs.
In addition to build system tuning, IT has been doing some extra travel this month. Paul from Austin and Hassan from Manchester have been traveling back and forth to our office in Frankfurt helping to plan the logistics of that studio’s office move. A good amount of planning and preparation goes in to a move like this and all is on schedule so far.
They’ve handled everything from electrical and cooling to IP addresses and VPN tunnels. Based on their hard work to get everything to fit in to a weekend, the dev team will not experience any down time.
Dennis from LA and Chris from Austin continue to build out custom configurations for testing based on feedback we’re receiving from the forums. We’re no longer just supplying reported gear to QA for one off testing. Dennis and Chris are now building and rebuilding custom systems in order to match reported systems in cases where we think hardware could be a contributing factor. They’ve also initiated early testing of Windows 10 in our test labs.
June has been an exciting and rewarding month for IT but we’ve got some even bigger things planned for July.
Dev Ops
June has been mainly consumed by 3 large projects for DevOps. The new Launcher, the new build server, and our “Phoenix” environment project.
The new launcher has already been broken into several code versions being worked on simultaneously. While the current public launcher is version 1.6, version 2.0 is in testing with the company and being used for the FPS playtests. Version 2.1 is being working on for roll out next week and will allow for faster downloads, smaller incremental patches, and some download speed improvements. Version 2.2 is coming right after that with a bunch more features, and version 3.0 is being worked on while all the rest of this process happens. Version 3.0 is a complete UI overhaul, and should be much closer to the final product.
The new build server is close to being done. We still are aiming for a mid-July release to the company with the first builds from that system going out to the public in September. For the players, they shouldn’t see any difference at all from this switch over. However for the company and the developers the improvements from this system should be huge. Not only should it allow us to run more builds at the same time, increasing the throughput of work, but reducing the amount of time developers wait for build, it will also lower overall build speeds. Currently, it takes 4hrs to make one build and we need to make around 6-8 builds a day for development to progress. As you can probably see, this is more time in the day than we have. So builds get backed up, skipped, and work slows down. The new build server will allow us to run 2-4 builds at the same time, and should reduce the 4hrs. We still need to do accurate measurements to figure out just how fast the builds will be.
As Chris Robert’s mentioned in his Letter from the Chairman, we have been working on the what we’re calling the “Phoenix” dynamic environments system. Each time the team kicks off a new build of Star Citizen all the data that the servers need is automatically copied out to hard disks in Google; this is a snapshot of our game data. These disks are broken into two to three conceptual parts: Base Image (the OS plus a few other things), Logs, and Server Data (Code and Assets). When we build an environment, we mount duplicates of these disks to each Virtual Machine (VM) that we bring up. Duplicates of the snapshot are created very rapidly, around 45 seconds for 200 gigs of data. We’ve written some automation code to automatically run commands on the VM to configure it appropriately for what type of server it will become (Game, Matchmaking, Party, etc.) During this process, a new DNS entry is assigned to the server based off the version of the data uploaded. When a new build is created, and we need to push it to an environment, we trigger a command that automatically shuts down all VM’s, unmounts the duplicated disks of the Base Image and Server Data disk (Log disks are always kept for troubleshooting), and then restarts the server with the new duplicates based of the new snapshot and the environment is running and ready on the new version.
This entire process takes about 8 minutes. When we want to take a QA environment that is built this way, and extend it to become a PTU environment, we send a command to our Provisioning layer and it goes out to Google, requests more VMs, builds more disk duplicates, mounts those snapshots, runs Chef commands to configure it, adds their DNS entries, and connects them to the existing infrastructure to be used. At that point we have a PTU environment. We repeat this process to build Production. Each time we expand an environment it takes about 8 to 10 minutes depending on the type of environment and the configurations we need.
The benefit of this dynamic creation and the environment expansion is threefold. First, any changed configs, misplaced settings, or broken processes are completely removed when the VMs are rebuilt using the new disk duplicates. Any configuration changes that need to persist should be made at the Chef level. Second, we can make absolutely sure that PTU and Production are the exact same environments that QA tested on, so there will be no strange differences we failed to catch in QA when we go live. The third benefit is simply speed. It is much faster to dynamically recreate environments on the fly than to recopy data each time. Those last two points are a pretty big deal. If our experience has taught us anything it is that having a consistent test environment that can be rolled out quickly is critically important, and this new system is pretty quick. It’s a huge force multiplier for our ability to rapidly iterate our test versions, which means QA and ultimately our backers will be able to do more varied testing more quickly. The more accurate we can get versions to our QA and to our backers the better we can ultimately make the game. July should be a very exciting month, with some of these major projects moving out of development and into production.
Greetings Citizens,
Foundry 42 is energized and ready to keep working hard! Between supporting the p-cap shoot in London, working on Squadron 42 in its own right and continuing engineering tasks for multicrew Arena Commander, we’ve been busy! Here’s the details from our department heads:
Animation
We’ve started work on breaking up some of the systemic Ai animations for enemy actions. These include things like stepping and running in to cover from various angles. Reacting to grenades and moving out of the way. As well as that the team has been working on refining some of the mechanics that are currently implemented in game to try and achieve a more responsive feel while keeping the realistic motion captured data. As always we’re on hand to provide any block out mechanics and environmental animations for the art and design teams here at Foundry 42.
Engineering
Two areas I’d like to talk about this month, which we’re getting more heavily involved with here in the UK, are the UI and AI.
On the AI front we’re taking a more active role in its development and have been doing a lot of the ground work getting our new CIGAI system up and running, alongside our colleagues in Frankfurt and Moon Collider. We have been looking at a new communication system, and how we can use it in conjunction with our current dialogue logic, to expand on the ground-work laid by the DFM survival mode’s Warlord and Vixen AI characters, as well as using it to make the cockpit audio system (a.k.a. Bitching Betty) smarter.
We’ve also been moving over some of the functionality from CryAI into our system and then amending it so it works better for our requirements on Star Citizen. So recently that has included the Tactical Point System, which includes things like cover, and the Group AI system, which allows better and easier handling of multiple AI objects, especially in the visual gameplay scripts (or the flow graph, which ever you prefer!)
On the UI we’ve been doing work here for quite some time now, but have recently started taking a bigger responsibility and taking on more of the work. We’ve been expanding the team with a new artist and a new engineer. Having the new engineer means that we can now have someone concentrating solely with bringing the User Interface requirements of Squadron 42 to life. Some of the many features that we have thrown his way are to develop the interface for the Tactical Visor and Looting. These will require various augmented reality overlays and post process effects to highlight people and objects, giving the player additional information about the world around them. We have also been performing an iteration on the visor displays for Star Marine, as each of the helmet types will have their own unique look and feel which require their own their own individual UI setup.
Our new artist is currently working on look-dev’ of the ship manufacturers, in parallel with this the ship UI code is undergoing lots of planning work so it can deal with multi-crew ships and all the challenges that throws our way, such as a captain being able to delegate (or lock out) various controls to the co-pilot or turret gunner. Planning is also underway to allow players to be able to customize their display outputs in their cockpits, giving them the ability to transfer various output to different displays. All of this planning is because, to support the functionality we require, the underlying structure that the UI code sits upon is going to need a bit of a refactor. We’ve already taken a lot of the hard coded setup of the UI and made it much more data driven (using our DataForge tool), but also were changing it to make it much more flexible, so any part of the HUD can be attached to anything else in the game that can take UI. So all of a sudden moving the radar from your visor and onto one of your cockpit displays becomes easy. This is going to be awesome!
Graphics
This month the UK graphics team have been focussing on several areas in parallel. The work on the mesh-merging tech continues, and is being trialled in larger environments such as asteroid fields to ensure it can handle any number of objects. This is coming along well and will be ready for production very soon and will start being used in public releases soon to give you better performance on new levels.
We’ve got a new senior programmer who’s been working on volumetric gas cloud rendering, investigating rendering dense clouds and soft fog with anisotropic lighting (the bright rim you get on the edge of clouds). This will be a very long term task as it’s hugely complex but is something we really want to push in our game. We’ve also been looking into facial animation technology, profiling various setups to see how far we can push the technology while maintaining a decent frame-rate. This includes trying different polygon counts, number of joints/bones in the face and the number of poses/blend-shapes that each character can use. As part of this we’ve also been investigating what we could do to push the rendering of our faces, which is no easy task when you also have to support many characters on screen. We’ll hopefully be starting this face rendering R’n’D next month and look forward to sharing the result (good or bad!).”
Design
June has been a busy month for design here with GamesCom looming. We are still flat out on Squadron 42, supporting the performance capture shoot with last minute level tweaks at the studio site to make it look at as fantastic as possible. All of the levels are looking more and more polished with a steady stream of great looking building tiles coming from our environment team that are iterated on until they look fantastic, while still allowing the level designers to layout the environments in a believable way.
We had an internal “Show-and-Tell” this month as a lot of the new staff had not seen the full depth of the plan for Star Citizen and it’s safe to say that it went fantastically well, with lots of jaw dropping amazement at depth of the game. It was great to see just how much work has actually been done in such a short period.
The technical design team has grown and is now covering tasks from FPS weapon balancing all the way to getting the Vanduul fleet operational in the engine, capital ships to fighters.
The Arena Commander team have now got the “large-world” code from the engineering team and are starting to realize what can be achieved in terms of universe size, suffice to say you should be seeing the fruits of their labours soon.
The systems designers have been finalising the specification for the “multi-functional displays” in the cockpits so that the functionality can be extended across all ships and is totally scalable from single-man ships up to larger capital ships. This is another one of our urgent tasks needed for GamesCom and will hopefully be shown in more detail very soon.
We are also trying to get a first implementation of “Quantum Jumping” ready to allow a more speedy way of navigating around the new “large-world” technology, which is looking very promising.
All in all a big month for us, but I’ve got a feeling we will be getting a lot busier in the next few months. Might be time to string up a hammock in the office soon. Thanks to everyone as always.
Art
Concept Art
Biggies this month have been the Bengal Bridge update and the Mining Bot, additional work continues on the Behring Ballistic shotgun, Xi’an transport ship, Vanduul fleet and further prop concept definition to add to the Shubin mining base and a few pirate bases needed for the Sq42 storyline (no spoilers!)
Ships
The Retaliator has been worked on this month to continue getting it ready for Flight – exciting times! Argo RUV is reaching Final art (excluding the pod which needs revisions for the cinematics), the Idris is looking very good in places, can’t wait to reveal some of it. Cutlass started its new greybox taking in to account design revisions, mining bot going to texture and material stage, Starfarer – going slower than we’d like, it’s a matter of resources, and we need more talented folk to help build this ship as its more complex than expected. Bengal Bridge will start once concepts are signed off.
Environment Art
A short update this month as much of what we’ve been doing must be kept secret for now. Progress is continuing with our VS environment which has hangars, control rooms, corridors, airlocks, and exterior landing pads – all of which can be traversed seamlessly. Hopefully we’ll be able to show you some of the really cool things we’ve been working on in the not too distant future, so stay tuned!
Props
We are getting clear documentation ready for outsource, dialling in with the techniques needed for materials which causes us most problems and then next month, we should be rolling.
VFX
The VFX team have been hard at work getting more ships “flight-ready” – this includes effects for thrusters, weapons and damage. In particular, the Scythe’s effects are looking pretty badass! We’ve also been continuing to iterate on environment effects – interior as well as exterior – for the Vertical Slice. We also began to focus on Star Marine’s weapon VFX, to make sure they’re matching the overall quality of the levels, characters and of course weapons. Truly exciting times to be a VFX artist at Foundry 42!
Audio
Hey everyone! This CIG Audio community report might meander a little, there’s a lot going on but think this should cover most of the interesting parts.
Firstly, Wwise. We’re nearly there as far as our mass of asset conversion/re-engineering is concerned; at least, the end is in sight. So Stefan, Darren and I have spent some time thinking more about how to set things up so we can mix the game well. Our game is on-going, constantly being revised of course, so the strategy we need to take is not typical to that we’d pursue for a one-shot release title. We think we have the basis of what should serve us well, and we’re changing the project structure to reflect this.
On the audio engineering side, much of it is still making sure things that used to work, work again; and ironing out any more emergent bugs/foibles that are still present. A certain ironic twist to what we’re doing is that the more we get individual sounds working, across all sorts of systems, the more we’re contributing to the problem of too many sounds playing, or being processed at some level, at once. Wwise has some ways of handling this situation, but the ideal is to make sure Wwise doesn’t get bogged down processing elements that are outside the player’s sphere of interest. At the core of it, if something is too far away to be heard, then we put it into a suspended-animation state where audio is concerned, but only to the extent that we need to so that when it comes back to life, it works as expected. There are all sorts of things to consider with this but that’s where we are right now in terms of core audio engineering. It’s not glamorous I know but it will keep things running smoothly if we get this right sooner rather than later.
We have a couple of new ships coming, one of which Darren’s been working on a lot. This had to have new dialogue recorded for its ship computer too and he’s been looking at the UI aspect, designing sounds and seeing how best to get them in. So much game UI these days is based somehow in Flash and that can be problematic for implementing sound in a way that we can iterate upon easily. So while we’re doing that we’re thinking of ways to improve this pipeline.
Incidentally, regarding the Origin ship computer, I’m holding my hands up on this one and admitting I failed to capture the previous essence of what made the ship computer so great for the Origin models. Basically, we’ve listened to you and absorbed the feedback you provided regarding the new one – and I’m absolutely determined that we’re going to win this one back. I’m not happy with it and this will be fixed!
Persistent Universe. We can’t say too much about this as yet but been ongoing support for the environmental audio for this.
FPS. So much of this is tied up in Wwise, there’s been plenty of new content required for FPS in terms of weapons, character Foley and dialogue and that’s coming along nicely. We’re getting a bunch of new music content down for FPS too. Thus we tested out a workflow where our composer, Pedro Macedo Camacho, works from his studio within Wwise, and we import what he sets up of his music into Wwise at our end. It’s not practical in terms of logistics to provide access to our own Wwise project (which is growing all the time), so testing out this workflow where he passes us a project file, has proved really valuable.
It was actually surprisingly easy to import his work-units into our Wwise project, and made me think that this might be an avenue for those of our modding community who wish to import their mods/material into Star Citizen. New assets could feasibly be produced by modders within Wwise, then passed to us for integration in the Wwise project, thus we export to sound banks etc. and pass the event triggers back to you for use. It might be a little unwieldy on the face of it, but I think ultimately working together with the modding community is the way to go to ensure a quality experience, and I’d love to try this out.
Arena Commander (or dog fighting module); a whole host of material has been converted, or some cases entirely re-created to work better than before. As Audio Director I don’t often get to do much sound design at the moment, which is obviously something of a shame as it’s what I am, at my core. So it’s been so good to be able to fit in some time for working on some ship thruster stuff and contribute in a material way to some thruster design! Luke’s taken what I’ve done and fixed it up a bit too, he’s very into the spaceship audio aspect of our game so that’s been reassuring for him to fix up my implementation. Generally a lot of this material is taking up time for all our sound designers, as it’s the lion’s share of Star Citizen right now there’s simply a lot to do but we’re whittling through it nicely.
Re: dialogue support for the Squadron 42. Our Dialogue Superman (not an official title) Bob Rissolo has still been hard at it down in London. It’s wrapping up soon, at least for now, which means he’ll be moving in-house permanently here to Foundry 42. A big move for him, we’re still hugely grateful he’s swapping sunny San Diego for the more, well, variable climate of Manchester!
Regarding our sound studios. By the time you read this we’ll have actually had our new doors installed for these. I know, doors seem like such an obvious thing to have, and of course, they are when you’re trying not to assail the rest of the studio with FPS gun sound effects, explosions and the like. But we’ve been waiting a while for a particular set of doors to be manufactured, simply we’ve been on the wrong end of some manufacturer-side production issues with them they’re each a different colour. I know that seems frivolous but when you have a number of isolated rooms and coming from another discipline, it saves time to be able to direct someone to the ‘orange sound studio’ rather than specify a room by who may or may not be there. Also means we can swap rooms to some extent. My own room is going to be a reference room for the rest of CIG Audio to test our surround mix, for instance.
Right now, tools improvements is something we’re considering. The better our tools, the easier it is for us to keep improving things. Wwise is an event-based system, and is reliant on external events of some form to trigger sounds in certain ways. For instance we want to trigger certain one shot-sounds when a thruster is transitioning from zero thrust to full thrust, on top of what we trigger for thrusters generally. And then trigger different one-shot events when the very same thruster transitions from full thrust back down to zero thrust. This is actually something that’s tricky to do ‘in the box’, the box being Wwise in this instance, so we want to be able to set-up these events more easily as sound designers rather than as programmers, so there’s a whole tool-set that we’re considering for defining logic to cater for this. This is just one tool out of many we can see a real need for.
We’re arranging to go back down to Pinewood, to record a whole bunch of duress elements for the ships. You might recall that they’ve worked with us on character Foley for FPS. There’s a new library of this sort of rattling, bone-shaking material that we’re also looking at (you can never have enough source) but we also want to make sure our stuff is that bit more individually tailored to our requirements. We’ll be taking down the Butt-kickers for this, for sure.
I’m sure there’s more stuff I’ve missed from this update, do feel free to ask us more on the Ask A Dev part of the community forums and we’ll continue to do our best to respond. Thanks for listening!
QA
UK QA have had to split our efforts this month to deal with the upcoming major events and releases. Star Marine (the FPS module) plus preparing for Gamescom, are on the cards for the near future, and Squadron 42 testing continues as normal.
Star Marine has had a lot of focus in order to root out major multiplayer bugs and try to find any general polish issues. Glenn Kneale from the UK and Tyler Witkin from ATX QA have been collaborating to make sure this game mode gets thoroughly tested. There’s been a lot of cross studio stress testing to help ensure that it should be stable once it gets released.
We’re focusing quite heavily on testing the sections of the game that will be shown at GamesCom. Unfortunately not too much can be mentioned there, but we’re all very excited about how what’s currently planned to be shown will be received.
Finally Squadron 42 is getting more testing time dedicated to it, as the game progresses we need to ensure the new mechanics are and alpha level run throughs can be completed. We also spent some time creating some more documentation to address our current plans to expand testing on S42.
Steven Brennon has continued to compile feedback from you guys and making sure it gets appropriately compiled and sent to the relevant people.
Sadly we’ll also be losing Chris “Chill” Hill at the end of the month. We wish him all the best as he’s been simply fantastic since he joined us last year, but looking forward we’re training up Steve Brennon to be a replacement lead.
June has been a busy month across all disciplines, and the team is building up in momentum. A large amount of strong applications have come in this month and we’re slowly getting through them 1 by 1. We continued to plan out our new office space, all things are set to get the keys to our new permanent office July 1st. We’ll make sure to share the new location with everyone in case anyone wants to stop by and say hi, with advanced notice of course.
Engineering
In June, Frankfurt Engineering deployed to the main codebase some major items that were planned for this month. As mentioned in the last monthly report, the Large World (moving the codebase to 64 bit coordinates), Camera Relative (rendering coordinates relative to the camera thus allowing galaxy size rendering without loss of precision), Zone system (the new Star Citizen spatial partitioning scheme, replacing Cryengine Octree) were close to hit the Star Citizen code mainline and have now been deployed, and will find their way into the various Star Citizen game modules soon.
The integration of relevant CryEngine 3.7 SDK parts, combined with our new changes, is being deployed into our codebase as we are writing this. Additionally a large effort this month was spent on supporting multi-crew vehicle ships: local physics grid, physics debugger, entities and prefabs, support for new 3D VisArea shapes, all this combined with the Zone System, are being worked on in the context of operating moveable ships. Amongst the other things, the multi-crew development process exposed a few bugs and incorrect functionalities that have been living in the CryEngine codebase for years …
We continued to work on optimizations, improved storage formats, bug fixing, clean up and general engine support to other CIG studios.
AI
During June, the AI development team has been focused mostly on the basic systems required for the human character to navigate through the full game world.
We completed the first pass on integrating the CryEngine MNM Navigation System and the multithreaded MNM Pathfinder. We also have completed the first pass on interfacing CryEngine Movement System with the current behaviour tree system. The Movement System takes care of analysing a path returned by the MNM Pathfollower and creates a plan on how to execute the movement.
Let’s imagine a character that needs to move into a cover position, the NPC will have to follow a path until the cover spot and then enter the right stance to actually position himself behind cover. The movement system allows us to have the proper context from the request to the execution of the movement, so that we can predict the necessary step the NPC has to take to correctly end up in a “behind cover” position.
We are in the middle of integrating the CryEngine Tactical Point System with our new behaviours. The Tactical Point System (or TPS) is a query system that allows us to query special position with specific properties.
In addition to the development of the systems we are taking care of creating all the glue code between the systems to allow the NPCs to have the best looking quality.
And we are also continuing coordinating the improvements on the Kythera Behavior Tree and its integration with Dataforge.
Design
This month the DE Design team has spent much of their time working on four initiatives: building a level for Squadron 42, assisting with the FPS module release, building AI behaviour trees for FPS, Squadron 42 and the Persistent Universe and then working with the UK team on Squadron 42 level feedback. We’re reviewing the missions and encounters they build for pacing, use of mechanics throughout the level, level flow and moment to moment gameplay ideas.
Animation
Currently the DE office only has 1 animator, fully focused on supporting cinematics. This month they worked on starting to set up scenes for scripted events and in-game cut scenes, getting pipeline tools identified and documented and a review of the Squadron 42 script (with the Cinematic director) to sort out which scenes will be owned by cinematics.
Cinematics
Hannes is back from the long cinematic shoot. He’ll be able to contribute to the monthly report starting next month. They had some truly talented actors on stage that gave amazing performances. We all internally look forward to pulling these together, as I’m sure the backers do as well.
Audio
Not much new for audio this month, still working on Wwise conversion that started last month. Hooked up the EVA thrusters and Ship Shield impacts to use the Wwise audio system, fixed several audio-related bugs. Started work on improving the distance-based culling of active sound emitters to let the sound designers create more detailed soundscapes without overloading the sound engine.
Build System
In June our Senior Build engineer visited our Austin studio (ATX) for 3 weeks and worked close to the Dev-Ops /IT teams on many aspects of our builds process, optimization and cross studio delivery. Among many things, the main goal was to reduce the amount of time it takes to put together a build, make patches, deploy servers and so forth.
We’ve decided to move away from the current build system in favor of something that we are confident will give us much more customization capabilities to better tailor it around our game’s needs. This is still work in progress, a lot of work has been done, and even more will be done in the next upcoming weeks.
VFX
For the past month we have been working hard on various squadron 42 effects. One of these effects has been a giant plasma drill. It is used to break up asteroids into smaller pieces for resource extraction.
Greetings Citizens!
Another whole month has gone by and we have been busy!
Engineering
As usual, a portion of the team has been focused on development for short term deliveries such as support for FPS Lobby & Flow. We’re also slowly moving away from that, now that it supports most of what we need for the first version, and have been starting to add support of multi-crew ships in the Lobby UI.
The month of June has brought us a few great features from other studios which has allowed us to work in tandem in order to add a bit more functionality to online hangars. We’ve been working hard on the current Holotable implementation in order to reduce the need for ships to be spawned in the game for them to be used in Arena Commander. This will allow us to reduce loading times as well as to facilitate management of server hosted Hangars. We have also been reworking part of the flairs implementation and Hangar spawning to work properly in such a context.
The planetside experience hasn’t been left to itself either as we’re still working on adding some features and a level of polish to the Augmented Reality (AR) experience with mobiGlas as well as the shopping experience as a whole.
Design
The design team has been setting up elevators and doors for Nyx, as well as setting up various functions (such as dynamic spawning, mobiGlas AR tags, and text string localization) for the items that will appear in Casaba outlet. We have also been doing follow-ups on the shopping experience, flair objects, and Level Design blueprints for Hurston, Crusader, and Microtech.
Art
This month we did a lot of work polishing for the Nyx asteroid map, improving materials/textures and dressing the environment to ensure that each room has a story to tell. We’ve also worked on improving one of our previous maps, modifying its layout to optimize navigation and improve performance.
Additional efforts were done on our shop system. We’ve added details on how clothing will be placed on the shelves to allow for good visibility from the player’s perspective.
Finally, as always, we’ve completed next month’s Flair object. Enjoy!
UI
The UI team has been doing quite a bit of spring cleaning (never too late!). We have been working on a thorough pass of the new holotable design flow to smooth out the whole user experience and to unify the various screens. Same goes for the simpod interface (also known as Electronic Access). We have also been cleaning up a lot of low priority tasks that have slowly and steadily been piling up.
Till next time, Citizens!
Hello Citizens!
Another month, another update. Quite a bit has happened over the last month. At the moment we have three guests from CiG (Sean Tracy, Steve Bender and Jason Hutchins) visiting us in Denver and helping out any way they can. We are currently focused on getting core locomotion as solid as we can, while still having the animations look great in both 1st and 3rd person. This isn’t easy by any means, which is why we have the extra reinforcements! You can find additional updates on the FPS module push in the weekly Star Marine update.
Engineering
Over the last month, engineering has been primarily focused on core locomotion and the start/stop/juke system. This has been close work with animators and designers, working out all the edge cases, and trying to find the absolute best balance between control response and animation quality. Everything then needs to work and be polished for both 1st and 3rd person modes. In addition to core locomotion, they have also created rules for Star Marine so that it reports stats in the same way that Arena Commander does for leaderboards and the accruement of REC. Lastly 5 different movement speeds were implemented. This makes moving with a controller very fluid and variable, depending on how much tilt is being applied to the stick.
Animation
The animators have all been laser focused on getting everything looking as good as possible with starts/stops/jukes. This has mostly involved a very quick feedback loop with Steve Bender. Getting his feedback, making tweaks and sending back the results until everybody is happy. It is a lot of work to be sure, but the team here is doing some really good work and the velocity of that work increases almost daily, now that the processes have been figured out.
Art
The art team has been working on optimizing all of the asset pieces for the Gold Horizon Station set, along with tweaking assets to match up with the metrics that are being used over at Foundry 42. This isn’t exactly the most interesting work, but it is something that needs to be done in the long run for persistent universe and Squadron 42.
Design
The design team is making numerous tweaks to the Gold Horizon level at the request of CiG. This includes some tweaks to ammo & energy placement locations, removing some doors and changing the behavior of others through the level. In addition, they are also tweaking the lines of sight throughout the level, and doing a polish pass on cover placement.
That’s all I have for you Guys and Gals this month. Until next time!
Here’s what we’ve been up to in this last month up here in Montreal:
Jump Point interview
First of all, this month our team had the opportunity to participate in an interview for an issue of Jump Point. This gave us the avenue to discuss some of the projects that we have been working for Star Citizen and shed some light on what is coming next. Thanks to David Ladyman for allowing us to go into a bit more details (and in a slightly more informal way) about our process for redesigning the site’s global look.
Starmap
This month, we completed the main art for the Starmap viewer, including Galaxy and System views. In terms of the interface, we made some significant changes to the HUD as well as filtering options (sensors and heat grid).
On the data side, we made good progress on data modeling for the upcoming Galactapedia. We also worked on our own administration tools so that we can import data from the Star Citizen universe. This will allow for having all the data of the different celestial objects already in a Galactapedia format.
On the 3D front, we started production of the different assets that will be displayed in the WebGL viewer (planet, jump point, space station, etc). This is very work intensive and it’s what the user will see on their screen, and so we’ll be working on this for the next couple of months.
Issue Council
As reported last time, we have continually been evolving the Issue Council to ensure that it greatly reduces the amount of time/effort for everyone involved. We have also been working to make sure that it cannot be easily swayed by large groups of users (such as organizations). We have been adding new features, re-organizing layouts, moving things from one page to another, removing pages, and so on — so much so that when we took a step back and looked at it all we realized that the UI was no longer intuitive. So we gathered the team around a big whiteboard and worked on fixing this.
The core update we worked out was an updated flow for the users. Upon arrival at the Issue Council, users will be provided with three ways of approaching the system:
Contribute by attempting to replicate issues and flagging invalid tickets (duplicates, feature-requests, poorly written, etc).
Prioritize the confirmed tickets to help the developers know what is important to the community.
Search all tickets that have ever been created.
We will soon have some designs to share, but to give a bit of insight here’s a photo of one of Benoit’s whiteboard designs.
Community Hub
The Community hub has entered its final stretch, and our developers have been working on actually implementing it for the whole month. The main notable undertaking on this specific project was to set up the submission flows. These will allow you to upload pictures and galleries of your own creations, embed your youtube play sessions, or report interesting links you’ve found elsewhere, which requires a great deal of technical flexibility from the website itself. Even more interesting was that we took some time devising filters and sorting algorithms based on the amount and frequency of content posted and their popularity through upvotes and comments. It’s always an exciting challenge to devise the way a website will display its own content, to keep it as relevant and fresh as possible.
Moderation tools
Another project that we have been working on, which has recently launched, was the new Moderation Tools, for the site’s dedicated team of moderators. These tools now give them more insight into flagged contents, repeat offenders and infamous recidivists, as well as a quicker way to manage forum access. This allows them to keep the forums, comments and Orgs running even more smoothly and efficiently. With their help, we’ve devised a set of tools that will then be expandable to cover all user-generated contents, including all aspects of the upcoming Community Hub as well.
This month’s concept sale was a short story showcasing the Genesis Starliner as operated by Meridian Transit. This quick tear-jerker (go read the postcards) was written by Star Citizen’s own writers, and along with some pretty cool art and voiceovers from the Community team, it gave us a lot of room to have fun with the post. This is why it quickly became one of the site’s most script-heavy pages, with mini components like the Flight board or the flipping postcards. The flight board itself was based on a very early concept for the Events block on the website’s homepage, which we were really fond of but put too much stress on browsers. So we were really happy to be able to use it anyway as part of the short story.
What you didn’t see
Just like for any other month, our programmers were also tasked with improvements and fixes that have gone unnoticed, thankfully. Prominent this June were the payment processors that we use : Amazon migrated their whole payment system, which we had to adapt to, along with transitioning to an entirely new way of handling subscriptions. Another one that shall remain unnamed cough*paypal*cough also had some interesting surprises for us that we had to react to very quickly. We’ve also dedicated some time to providing new tools to the Customer Service team, to help them deal with problematic cases even more efficiently.
It’s been another busy month at Moon Collider, so let’s jump straight into it:
Engineering
It’s a well known saying that no plan survives contact with the enemy, and I think an equally valid saying would be no tool survives contact with the designers! No matter how well you design any new tool, the moment designers start playing with it you’ll find out very fast what needs improvement. Last month we gave designers the ability to write behavior trees using an editor built into DataForge, Star Citizen’s custom data management tool. We tried to get it into designer hands as quickly as we could, so we already had a decent sized todo list of improvements we knew were needed, but a few hours of real use of a tool by a designer always helps to clarify which issues are minor annoyances, and which ones frequently interrupt their workflow or straight up make them unable to do some task.
We spent some time this month getting feedback from designers and working through their prioritized list of issues with the new editor. This included things as simple as writing up more documentation on how certain features worked; renaming, recategorizing and recoloring BT nodes in ways that are more intuitive to a designer; and even moving certain advanced pieces of functionality out of the standard workflow so that it’s a little more laborious to use those rarely needed features but it makes the common features more streamlined. We expect to continue improving this tool next month as the feedback from designers keeps on coming through.
With the designers now working on behavior trees with DataForge, it was also perfect timing for adding a behavior tree live view to our Kythera Inspector web based debugging tool. This is a web page that designers can bring up that gives direct access to the state of the AI in their game, and we’ve been constantly added features to it in order to make debugging AI easier. Up to now we’ve been relying on some simple on screen text debugging to help us understand the current state of an AI’s behavior tree, and while this worked reasonably well for a small and simple tree, it was much less useful for larger trees, and also limited in the information provided.
The new live view in Inspector allows designers to see the state of the behavior tree of any AI while the game is running. We have some new features coming next month that will allow this view to help them track down configuration errors with their trees, which, when combined with the already existing ability to record and play back the behavior trees of the AI, should give designers a comprehensive suite of tools for debugging their behavior trees.
One issue we’ve been trying to sort out for a while is a technical feature we call a string hash. This is something that is built into Kythera and basically allows us to convert any text string in the code into a numerical identifier at compile time. This makes it cheap and efficient to pass strings around in the code and use them without worrying about it being expensive to do comparisons, which is usually the case with strings. And this means that you can have a lot more descriptive text being passed around in your code rather than simple numbers, which can make code that’s easier to work with and easier to debug.
Because this is such a useful feature, a similar version has been added to the rest of the Star Citizen codebase. What we’ve been trying to work out is how best to unify these two different versions of string hashes, so we can avoid the cost of converting between them. There are various details that make this trickier to solve in a satisfying way than it might initially seem, so we’ve been spending time working this out with coders in some of the other studios and are currently testing some possible solutions to try them out and see if they cause problems in practice.
Now, let’s talk ships!
Last month we added in the feature that allows ships to reliably join splines. This month we started making good use of that feature in the form of retreat stunt splines. Stunt splines are paths that are laid down by designers in a level and allow AI to fly through tight areas where their collision avoidance would otherwise stop them from going, such as through a tunnel in an asteroid or gaps between sections of a space station.
One of the main goals of these stunt splines is to set up opportunities for players to chase AI through interesting and exciting paths. We’ve added them to AI retreat behaviors so that when an AI ship wants to break away from a pursuer, if there is a stunt spline nearby it will try to make use of it. To keep things believable, the AI will only pick a spline if it can get onto it quickly, so they won’t use one if it requires a major change in speed or direction to get to it.
We can also use them to distinguish elite AI pilots from rookies by having a skill level attached to the spline. So a really hairy maneuver can be marked as only available to the best pilots. This also means that if you go to chase a fleeing elite ship, you may find yourself in a chase that you’re not good enough to pull off, and you’ll need to make a quick decision on just how crazy a pilot you’re willing to be!
Once designers have had a chance to work with this feature, we plan to make some refinements to the spline selection process to get a good balance so they’re not overused or underused. It’s important that the AI don’t become too predictable to a player who is familiar with a map, but on the other hand, seeing a ship break off and head towards that tunnel you know is great fun to fly through can be something to anticipate as well.
As is always the case with new features, we’re looking forward to seeing this one get into the hands of real players and hearing the cool stories that come from it!
Greetings Citizens,
We always say that it has been a busy month for the community team, but at this point… what month isn’t busy?
We were very happy this month to celebrate the first anniversary of Around the Verse! AtV has been an interesting project for us; last year, we went into the s how dreading the need to replace fan favorite Wingman’s Hangar… and we took time to find our feet and figure out what was important. Thanks to your feedback (and your support!) we’re proud of what the show has become… and we’re going to try and keep making it better. Episode 50, aired last week, had one especially standout segment in which designer Randy Vasquez showed his process for building Starliner interiors. Expect to see more segments like this in the future, as we felt it was our strongest piece yet.
We’ve also asked the community team to be more interactive on the forums. We’re just as eager to see Star Marine release as the rest of the community, and we’re going to do our best to get out there and not just show the flag but share our answers and thoughts with all of you. A Community Manager can’t always answer your questions… but we’re here to address what we can and also listen to your concerns and make sure developers are aware of them. Even better, we’re working on a relaunch of the ‘Ask a Dev’ process, which will hopefully result in a system for getting your questions answered by the experts.
The whole team also had a field day with the Genesis Starliner sale. We wanted to get across just how much depth there was to the ship, and the whole team worked together to add pieces to the presentation that we thought would interest the community. From Jared’s postcards to Ryan’s safety card, we wanted to show you more than just how big the guns were (and if we’re being honest, the guns are not that big in the first place.)
Finally, we’re very sad to lose one of our own: Chelsea Day, manager of the Customer Service team, has left CIG to relocate. Chelsea was a good friend and a great CS manager; we’re all going to miss her! Patrick Probst, who you may have seen on the forums, will be taking over the CS manager position in the UK. So congratulations – we know you’ll live up to the example Chelsea set!
Links
| Text | URL |
|---|---|
| check it out HERE | https://robertsspaceindustries.com/comm-link/transmission/14804-Design-Civilian-Passenger-Transport |
Images
29
image/jpeg
image/jpeg
Metadata
- CIG ID
- 14814
- Channel
- Undefined
- Category
- Undefined
- Series
- Monthly Reports
- Comments
- 116
- Published
- 10 years ago (2015-07-03T00:00:00+00:00)