Um alle Funktionen des Forums nutzen zu können, sollten Sie sich registrieren. Wenn Sie schon regstriert sind, sollten Sie sich anmelden.
Datenschutzerklärung: Hier
Einstellungsmöglichkeiten zur Privatsphäre finden Sie in Ihren Einstellungen.
Einen maschinenlesbaren Export Ihrer Daten können Sie in Ihrem Profil anfordern. Hier
Happy birthday, everyone! Three years ago, Star Citizen’s initial crowd funding campaign wrapped up with an epic 24-hour livestream direct from Austin, Texas. Today, Star Citizen is being developed by four dedicated studios around the world… all thanks to the support provided by our backers! In honor of that support, we’re proud to kick our anniversary sale week off with a stream updating everyone on everything from Star Citizen Alpha 2.0 to progress on Squadron 42. Tune in today (or catch the replay) to find out what’s coming up for Star Citizen straight from Chris Roberts and the team. It has been a great year for the team at Cloud Imperium. Thank you to our incredible community for the support you’ve shown us. We’re very excited about the impending launch of Star Citizen Alpha 2.0 and sincerely hope you’ll be as proud of it as we are. This new update, complete with FPS, multi-crew and large world tech, will truly show the world how cool Star Citizen is going to be!
We’re also kicking off a week-long sale that brings back popular limited edition ships and offers a few new surprises! Thanks to the new CCU system, backers can use the schedule below to upgrade to exactly the ship they’ve always wanted. Finally, we’re very pleased to announce that several new ships are now available in all possible states! Two new concept ships are on sale today and with the launch of Star Citizen Alpha 2.0 there will be three flyable Avengers and a hangar-ready Vanguard! You can see below for further details. We will be holding Q&As on the Crucible, Avenger variants and Archimedes over the course of next week. Visit the forums to have your question included!
Remember: we are offering these pledge ships to help fund Star Citizen’s development. The funding generated by sales such as this go directly to the game’s ongoing production. Concept ships will be available for in-game credits in the final universe, and they are not required to start the game.
New Ships
Crucible
A so-called “flying toolbox,” the Crucible is Anvil Aerospace’s first dedicated repair ship. Featuring a rotating control bridge and a detachable pressurized workspace, the Crucible is a versatile mobile garage equipped with repair arms, a drone operation center and all the equipment needed to overhaul a damaged craft back into fighting shape.
The Crucible, our penultimate Wave Four concept ship, is now available! Designed by the legendary Ryan Church, this repair ship is just the thing for keeping your fleet up and running. When closed, the detachable workshop allows crews to repair single seat fighters internally. When open, the Crucible can use its remote arms to attach and repair larger craft! You can learn more about the Crucible here, and Star Citizen’s overall repair mechanic here.
Avenger Variants
Star Citizen Alpha 2.0 will see the addition of flyable variants for the Aegis Dynamics Avenger! The base Avenger available today is now the Stalker, designed with the needs of bounty hunters in mind. A basic Titan cargo ship and an advanced e-warfare Warlock are also available… and all three will be available for combat in Star Citizen’s next patch!
The Titan and Stalker are permanent additions to the pledge store, the Warlock will be on sale through the end of the anniversary sale (Sunday, November 29th.) Please note that these variants will be available as separate modules in the future. The initial release of Star Citizen Alpha 2.0 does not allow changing modules, so we are offering them as distinct, playable ships first. We would encourage you to CCU to the Avenger you’re most interested in trying rather than picking up all three!
Avenger Titan
Lacking the Prisoner Cells of the Stalker or the EMP Generator of the Warlock, the Titan’s hold is free to carry cargo. Couple that available space with the Avenger’s tried and true combat abilities and you’ve got a light cargo hauler that’s more than capable of handling itself in a fight.
Avenger Stalker
Initially designed as Aegis’ frontline carrier ship for the military, the Avenger Stalker took a different path, ultimately having a long and storied career as the standard patrol craft of the UEE Advocacy. Utilizing its cargo hold for prisoner transport, the Avenger features a sturdy, reliable hull and the capacity for larger-than-expected engine mounts.
Avenger Warlock
The Avenger Warlock was built towards a single design philosophy: stop ships, don’t destroy them. Probably the closest to a non-lethal fighter, the Warlock is outfitted with a Behring REP-8 EMP Generator, capable of emitting a powerful electromagnetic wave to disable any electronics unfortunate enough to be within the blast radius.
P-72 Archimedes
If you’re looking for something a little more agile, blaze among the stars with Kruger Intergalactic’s P-72 Archimedes. Whether for added security, exploring a system or simply the joy of flying, the Archimedes is the perfect companion snub craft. Featuring an extra intake and a lighter hull than its sister ship, the Archimedes delivers exceptional handling and boost capabilities in a sleek package you’ll want along for the ride.
The Archimedes is here! Concepted by Gurmukh Bhasin, the Archimedes is the speedy, luxury alternative to the P-52 Merlin. Initially included with the Constellation Phoenix, the P-72 is interchangeable with Kruger’s other snub fighter and can be attached to any snub-capable Constellation. The Archimedes is available this week as a concept sale.
Vanguard
The A3G Vanguard is the United Empire of Earth’s dedicated deep space fighter. Initially developed as a bomber-destroyer, the Vanguard is a hard-charging bulldog of a ship which features extensive forward-mounted weaponry designed to tear through the shields and armor of other spacecraft. Four high-caliber forward laser cannons and a massive central Gatling gun give the Vanguard an unprecedented amount of sheer striking power. So-named because their multiple-jump range allows them to form the forefront of any military expedition, Vanguard have seen extensive service against the Vanduul.
We’re proud to announce that the Aegis Vanguard will be available as hangar-ready in Star Citizen Alpha 2.0! Going forward, we intend to make ships hangar ready earlier in the process than previously allowed, starting during their advanced greybox phase. The Vanguard will be the first of these ships! In its honor, we’re making all three variants and their BUK options available again this week.
Bring a Friend!
We don’t just want existing players to enjoy the anniversary, we want to introduce Star Citizen to new players! As a result, we’re offering a limited number of discounted $30 packages each day, first come first serve (1,000 per day.) These packages offer the full Star Citizen experience, including an Aurora starter ship and a copy of the Squadron 42 single player adventure. You won’t find a better deal anywhere in the ‘Verse, so pick up a copy for a friend today!
Physical Merchandise
Star Citizen physical merchandise is also on sale! For the next week, Constellation models are now $80, Arena Commander t-shirts are on deep discount and all other in-stock merchandise is 20% off.
Anniversary Sale Schedule
We’re making a large number of our older ships available for those who missed out, want to upgrade an existing package or simply want to expand their fleets. We will be presenting these ships over the course of the next week in a series of role-based theme days, listed below. From armored explorers to lumbering transports to alien traders, there’s something for everyone! All existing ships will be offered with three year insurance in honor of our third birthday. Each day will also include a discounted ‘fleet pack’ in the style of the Armada Pack available during CitizenCon. Don’t want to wait around to switch to your favorite ship? All ships will be available at once during the end of the sale, from Friday, November 27th to Sunday, November 29th.
Friday, November 20th: Exploration
Endeavor and Modules
Carrack
Saturday, November 21st: Piracy
Caterpillar
Herald
Redeemer
Cutlass Blue
Sunday, November 22nd: Military
Retaliator and Modules
Starfarer Gemini
Sabre
Super Hornet
Monday, November 23rd: Racing
M50
Mustang Delta
350R
Tuesday, November 24th: Aliens
Khartu-al
Banu Merchantman
Reliant
Wednesday, November 25th: Working Starships
Reclaimer
Genesis Starliner
Orion
Aurora LX
Starfarer
Thursday, November 26th: Mercantile
Freelancer MIS
Hull Series
Constellation Phoenix
Friday, November 27th – Sunday, November 29th: All Previously Offered Ships!
From Friday through Sunday, all ships previously available during this sale will return. Pick up your favorite as soon as it appears, or wait until the finale to make your choice!
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Space is a hostile place and even the most skilled pilots will need to have their craft patched up from time to time. Fortunately, there are a number of options available to Citizens to get themselves back up and running.
Star Citizen’s repair system works in conjunction with the engine’s detailed damage model to create intuitive and engaging gameplay for players wishing to pursue a career in ship repair or for pilots to execute quick field repairs.
The basis for repair technology in Star Citizen are tools equipped with multipurpose lasers that can trim away damaged material or sinter construction material injected onto a component’s frame, rebuilding its structure
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Any ship with repair capabilities has two roles that must be filled to ensure a successful repair job: the Repair Arm Operator and the Repair Task Manager.
The Repair Arm Operator is responsible for the control of the robotic repair arm. Mounted with a multi-purpose laser and material injector system, the repair arm is capable of carrying out all manner of repair tasks. The repair arm is the only player controlled method of fully restoring a ship to 100% health but requires skill, knowledge and coordination with the Repair Task Manager to do so effectively.
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
The Repair Task Manager relays detailed damage information to the Repair Arm Operator, designates repair tasks to be undertaken and is responsible for the allocation of materials to satisfy part reconstruction requirements.
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
To initiate workshop repairs, the Repair Task Manager must first use their damage assessment interface to gather damage information and prepare for the repair tasks required.
Damage Assessment
Whilst using their terminal, the Repair Task Manager can access the target ship’s damage diagnostics. This displays the status of ship parts, the hull, systems, weapons and their various connections. The player can toggle and filter between various layers, isolating and displaying their respective elements.
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Damage that has been dealt to a ship’s hull is represented on an AR overlay as a heatmap: no damage displays as green, full damage and holes as red, and partial damage on a gradient in-between. The edges of hull breaches are also highlighted for clarity.
Highlighting the various parts will display its current health as well as the materials required to repair it. When ready to start a repair job, the Repair Task Manager selects the desired part, opening the Material Panel.
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Repairs taking place in a workshop require the consumption of the raw construction materials gathered through Mining, Scavenging and Trade. The Repair Task Manager can assign different materials according to the repair task at hand via their console’s Material Panel.
Depending on the repair job, certain types and quantities of material are required. When a component is selected, these requirements are displayed in the Repair Compound section of the Material Panel as slots that need to be filled from the repair ship’s Material Stock.
Each material is graded to reflect how effective it is when assigned to a slot and how it will affect the repair procedure (discussed later in the Repair Arm Operator’s section). To get optimum results the Task Manager must balance the Arm Operators requirements, versus the value of the materials used.
Once all materials have been assigned, the Repair Arm Operator can then initiate the reconstruction process.
In the event that a ship part or component has been entirely detached or destroyed, it must be reconstructed. To do this the Task Manager selects the missing part from their Damage Assessment panel and assigns the materials as normal.
Once the composition is confirmed, the missing part’s frame is automatically constructed by the Repair Arm; the process is entirely automatic, using patterns from the repair terminal’s database for reconstruction. After the framework has been constructed, the player can then use patching to build the surface up as normal.
Before a reconstruction can be started, the attachment point must be cleared of any obstructing debris by the Repair Arm Operator. Whilst an obstruction is present, the part appears as a red hologram on the damage assessment screen with the extraneous material highlighted for removal.
Once the Repair Task Manager has chosen the part and repair material composition, the Repair Arm Operator starts the reconstruction and repair process. By using their terminal, the operator controls the arm’s position and aim remotely via a mounted camera. To avoid overcomplicating controls, the head is translated and aimed directly with an IK solution orientating the rest of the arm to follow.
The Repair Arm’s laser can be switched between two modes to carry out the various necessary repair stages: Stripping and Patching.
Stripping
Hull stripping is vital for improving the integrity of a ship’s hull that has only sustained light damage, as only missing segments can be patched.
In stripping mode, the repair arm’s high powered laser is used to cleanly remove parts of a component’s surface without causing structural damage to the surrounding area. Stripped surfaces are converted and collected as a percentage of its raw materials.
Stripping is also necessary when a component or part has been completely detached. Full component reconstruction requires a clean attachment point requiring the operator to cut away any debris that compromises the area.
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Patching is the act of rebuilding a ship or component’s surface and restoring its integrity. When in patching mode, the Repair Arm’s laser is repurposed to directly ‘print’ material onto a ship or component’s frame. As the Repair Arm is aimed, a wireframe hologram is projected showing the edge of the damaged area that can be printed onto. This grid is a high resolution tractor mesh that matches the undamaged surface, supporting the material printed onto the ship.
The Repair Arm sprays a powdered compound whilst simultaneously firing a laser to heat and bind the compound, creating the new surface. As the repair surface is built up, the mesh gradually contracts to form a new working edge until the area is completely restored.
The strength of the new surface is dependent on the amount of exposure it is subjected to from the laser. As a surface is being built, it gradually increases in strength until it reaches 100%. If the laser remains focused on that area for much longer however, the integrity decreases as the surface overheats. This creates a sweet spot that the operator must reach before moving on to achieve optimum integrity.
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
The player can choose to toggle the AR damage heatmap overlay on and off whilst patching to receive real time feedback as they approach this threshold: the surface turning green as it nears 100% and transitioning back into the red as the surface is overexposed. If a surface becomes overexposed, the Arm Operator will have to restrip that section of the surface before reattempting to patch it.
The composition of the repair material, as defined by the Repair Task Manager, determines the behaviour of the patch surface as it is being printed: the max integrity level, the size of the peak integrity sweet spot and the rate at which the exposure affects integrity. This presents a player-defined risk-reward loop where the use of cheap materials can achieve the same results as expensive ones, but requires far more skill to accomplish with the crew of the repair ship needing to take their operators abilities into consideration when pricing jobs and assigning materials.
The Multitool is a personal item that is equipped with the capabilities of a small-scale version of a workshop’s Repair Arm. It is capable of stripping and patching, allowing it to achieve a wide variety of ship repairs short of full part reconstruction.
Although the Multitool’s repair abilities are the same as that of the Repair Arm, the size of the laser and low quantity of repair material it can store means that it is only suitable for quick fixes and patch jobs to get a ship back to a proper repair facility.
Component Damage
When your ship takes damage, some of that damage will be transferred from the point of impact on the hull to the nearest system and weapon components. Those components then distribute that damage between itself and whatever Subcomponents are attached inside.
Subcomponents are the various consumables that are used to run or improve a component or system’s behaviour.
In general, component field repairs consist of turning off whichever component is having problems, replacing the broken subcomponents, and turning the component back on. In very large components, like those found on capital ships, there may be multiple actions involved in turning a component on or off, including rerouting power or coolant to other parts of the ship. These actions may also involve the use of on-board ship computers.
Subcomponents
Subcomponents provide additional benefits to the component they are attached to, allowing for further customization of a player’s ship. They are divided into three categories, each providing specific areas of improvement.
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Module Racks are panels that house the various components used to keep their associative subcomponents running. These can be found on the hull under maintenance hatches in closed-cockpit ships, or internally in the engineering section of larger multi-crew ships.
Depending on the component installed, different types and numbers of subcomponents are required. Each subcomponent is built for quick removal and replacement allowing for field repairs to be carried out as quickly as possible. If a player attempts to remove a subcomponent from a powered component they risk being electrocuted and receiving damage.
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Replacing a damaged subcomponent is a simple case of interacting with the item in question. The player will then remove it, freeing up the slot. If the player has a replacement in their possession, they can then interact with the empty slot to place it.
Subcomponent types are universal across ships and components of the same size class, a coolant rod from a Gladius’ laser cannon can replace a Hornet’s coolant rod housed in the shield generator. This provides a great deal of flexibility, allowing players to juggle elements between various systems as needed, as well as opening up opportunities to patch their ship using scavenged parts.
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Components on larger ships, such as the Idris or Retaliator can require a large number of subcomponents to function and/or larger sizes of subcomponents. When damaged, these more complicated systems can take significantly longer to diagnose and physically swap out any compromised subcomponents. To maintain full operation, these ships can contain alternative backup systems. In the case of an emergency, engineers can use their ship terminal to redirect power to the backup, allowing for full ship functionality whilst the engineer repairs the primary system. This can also be achieved manually, should an engineering terminal become inoperable, by physically swapping the whole module rack out, placing the backup system in the primary’s slot.
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Star Citizen Alpha 2.0. development update. Week Four… let’s go!
Well it’s been a fun week working on the game. As much as it can be stressful at times, it’s easy to forget what an amazing project we’re all working on thanks to you guys with your incredible support. Everything else aside, we are all really happy to be part of the team building the dreams in to a reality! The First-Person Universe will be something that has not been done before in the history of video games so any project this ambitious is always going to be a challenge – and who doesn’t love a challenge! Nothing worthwhile comes easy.
Star Citizen is a game we’re building to be enjoyed for many, many years to come and we’re now reaching at a turning point on a very special journey together with the 2.0 release. We hope we don’t leave you waiting much longer for this first real taste of what Star Citizen can become. It was a tough decision to make in putting our efforts behind this one huge release because it always had the potential for added risk for delays in production but we know it was the right decision to make for good of the project because it will give us the right foundations to build upon for the long term. A Publisher might not have been so brave because they don’t have the BDCE (Best Damn Community Ever!).
Get out your lucky pants and three-leaf clovers out because Murphy’s Law was in full force this week! No, it’s not a new game feature – we suffered some unfortunate news in our Lead FPS Programmer falling off his bicycle and breaking his wrist! This certainly wasn’t in the schedule so with him out of action for a few weeks we’ve had to pool some resources from other areas to help pitch in with getting 2.0 out of the door. It’s certainly not what we needed at such a critical time in the project but these things do happen.
In better news, we’re very nearly finished with our Excludibir process, with just one more QA report thus far of missing assets from the Release build with the Gladius causing a black screen hang on the Tutorial of the game. So that’s been addressed and should hopefully be the end of it for 2.0.
The new ship UI screens we posted footage were very warmly received last week which is exactly the kind of feedback that really gets a buzz around the office and makes our community such a great group of people to work for. We are never totally sure on how something will be received until it’s out there so that was certainly a good way to dip our toe in the water with this one to check the temperature with you guys. We have now finished up the last of the gameplay code hooks so that is in full test now to make sure that clicking all of those buttons will actually do something! Please note that the sections that are labelled as “System Offline” in the video will not be functional in this release but will be coming in subsequent patches as we iterate on it.
The item component for EMP is being hooked up and in put in to full test this week so we’re eagerly anticipating the results of that and Design have been busily reviewing the new IFCS Flight Modes – SCM (Space Combat Maneuvering), Precision and Cruise. These are coming all along nicely but it’s always weird to begin with when first testing out a new control system. It often takes time to get familiar with them and we want to ensure that you guys get a solid base so that we it feels comfortable and fun and can then iterate from there.
The worst bug of all bugs that’s been a thorn in our side over the past week has been server degradation. It took the whole QA two days to track this very nasty issue down but one of our programmers has just at the time of writing this report committed a fix which we hope will be verified as fixed in the next QA build. The issue was gradually preventing players getting in to a game server after an extended play period so we came to suspect a leak and had to go about back-tracking the sequence of events leading to the issue to look for what might have caused it. It was an awkward one to repro because it needed a large amount of players testing for hours on end. We eventually managed to trace it back to an issue with the ship selector and the player accounts so we really hope that this fix will alleviate a number of related issues that we were experiencing on the server-side. It’s been a perfect example of how one small discrepancy in the build can have huge knock-ons!
Speaking of knock-ons, we’ve also unearthed some new Blockers on our Release builds with the as listed below in the bullets but fortunately we have workarounds for them all in our Profile Builds so have been able to continue our work – however, this sadly means that the build is not ready for public consumption yet!
Production, QA and Dev are doing some serious triage work on the remaining unresolved issues and looking for any creative problem solving to get a solid release candidate together. We’re making some tough decisions to agree upon what is classed as a “must-fix” for Release. The triage will help us minimize the chance of any further unnecessary knock-ons and get you something to play sooner rather than later!
Below we have a list of high level items that you might like to scan over to see what the various teams have been focused on this past week…
Gameplay and Engineering
Fixed a major issue where the server performance would degrade over time
Fixing memory leaks in the new zone system when destroying vehicles
Working on fixes for Quantum Travel
Working on a fix where multiple ships going to the same destination don’t end up inside each other
Working on a fix for being teleported back to the start point when emerging from Quantum Travel
Implementation and balancing of a new fuel type – Quantum Fuel
This depletes in Quantum Travel and requires players to refuel or risk being stranded in deep space
Network optimizations
Performance optimizations
General bug fixing
UI
Bug fixing and polish
Removed the tool tip to heal other players when you are near an injured player, since we have temporarily removed the ability to do so until we fix the animation for the medpen.
Art
Bug fixing and polish
Animation
Bug fixing and polish. ADS is much improved, and I’m looking forward to doing more FPS combat playtests around the stations outside of the Armistice zone.
Audio
Mastering and implementation of recorded dialogue
Designed custom convolution reverbs, mainly for interior spaces
Polishing of audio across the whole of the crusader map
Working on improving the sound design for EVA
Continued improvements for ship fly-bys
General bug fixing
Blocking Issues
Server degradation preventing causing spawning issues (fix committed)
Quantum Travel causing a crash on Release
Player not able to pick up a weapon for FPS at Security Post Kareah on Release – BREAKING: This is fixed!
Climbing in to small and medium ships causing the player to spawn at point origin (0,0,0) on Release
Low repro cases of Quantum Travel failing to deliver the player to the intended mark on Release
“The only constant in game development is change.”
We all have ideas. Good ideas. Bad ideas. If you’re lucky, possibly even great ideas, but the best ideas rarely come without a fair share of time and effort and perhaps most importantly: trial and error. Game development is that process of not only bringing those ideas to reality, but of testing and refining those concepts in the crucible formed from combining hundreds and thousands of disparate designs into one.
It’s here in the game development phase when you discover the true virtue of those intentions, and discover what works and what does not, and what can be made to work and sometimes more importantly, what should not be made to work. It is the thing you do your best to anticipate, and the place where you either discover the elation of a theory fully realized, or the struggle to iterate that initial plan into something better than it was before.
THE SHIPYARD is a new series of articles we’ll be publishing from time to time as things come together. Created with help from the developers in the trenches creating this game, we’ll explore the history of these ships, the current realities they’re faced with, and the prospects of their continuing evolution going forward. We’ve decided to start with the Cutlass because it’s had a storied development history, and it gave us a great chance to take a candid look at the trials and tribulations it’s faced in the last three years. This isn’t the answer to all Cutlass-related questions, but we feel it’s a great effort at pulling the curtain back on game development, and documenting a little of how this process actually works.
The Drake Interplanetary Cutlass was born on October 3, 2012 at 5:44 AM Eastern, part of a designer’s guide to Star Citizen’s ship manufacturers that continues to inform many aspects of the project today. The primordial Cutlass was cited as an example of names that Drake Interplanetary, our pirate-focused company, might use.
Drake Interplanetary is ostensibly a legitimate company, but it’s an open secret that they manufacture cheap, well armed craft favored by pirates, to the point that they’re named in that vein: “Cutlass,” “Buccaneer,” “Privateer,” “Bandit,” “Marauder,” etc.
The intent here was to solve a very specific problem of immersion: while we knew that many players would want to engage in piracy, it was not believable that there would be a high-tech, public spacecraft manufacturnig company that simply produces hardware explicitly for criminals. Toyota, for instance, doesn’t manufacture a specific model of pickup truck for paramilitary terrorists… their existing trucks simply fall into the hands of such groups, which adopt them for their nefarious purposes. So, the idea of Drake Interplanetary was born: a sketchier company, for sure, but one that builds ships for a specific, legal purpose (note also that we would later build the Cutlass variants around the reference to it’s search and recsue role.)
At this point, however, the Cutlass was simply a distant concept. We opted not to include a Drake ship with the initial lineup, thinking that selling something as being (in-world) ‘cheaper’ than the others would be counter-intuitive as part of a campaign aimed at selling the thrill of owning your own spacecraft. Then… pirates happened! From day one, it became clear that a LOT of Star Citizen’s backers wanted to someday engage in a life of crime. Backers formed their own syndicates and cartels and clans, buoyed by the promise that Drake Interplanetary would someday be supplying them ships. Within a day of our initial wave of ship specifications being published, the theorycrafting as to which the best option for starter pirates began.
With the campaign in full swing and with plans being made for the end of the Kickstarter, I made the following suggestion in an e-mail to Chris Roberts:
Pirate Pack – I’ve had this in my mind a while; basically, just a copy of the game with a pirate fighter (Drake Industries Cutlass,) which will be appealing to a particular subset of our audience.
Chris immediately replied that he loved the idea and that he wanted to see a pitch for the Cutlass’ design and specifications that could be sent to concept artist Jim Martin in the hopes that we could show off a sketch during the last days of the Kickstarter.
So: how did the Cutlass concept come about? As with many of our ships, we started by looking for two types of analogues: ships (and more importantly gameplay roles) from Chris Roberts’ classic games and historical aircraft to lend verisimilitude to our growing universe.
For the first part, we naturally looked to 1993’s Privateer where piracy was a semi-viable career option, although one that made life particularly difficult in most of inhabited space (other aspects of Star Citizen’s design were planned alongside, intending to give pirates more to do overall!) For those unfamiliar, Privateer had four player ships: a starter, a gunship, a transport and an elite bounty hunter fighter. In a great example of emergent gameplay, pirates of yore tended to forgo the statistically superior Centurion fighter and instead purchase the cheaper Galaxy light transport. Why? Because the Galaxy had the largest cargo hold and a pair of turrets that meant you could attach tractor beams without using a precious forward-facing missile/torpedo slot (turrets, which had no AI, were otherwise largely unnecessary in Privateer.) While a Centurion could best take out a lumbering transport, it’s small cargo hold meant that the profit made from stolen loot was limited. For the Cutlass we decided: why not codify this mechanic and offer pirates a fighting ship that trades some dogfighting ability for the larger cargo hold they’ll want in the ‘verse?
For the historical reference, we fixated on the idea that Drake built ‘cheaper’ ships intended to be available in large numbers to a larger group of captains. While not wanting to sell the Cutlass as ‘disposable,’ we wanted to get across the idea that it was treated as something of a lower tier ship than the Freelancer, Hornet or Constellation. For that history, we looked to World War II and the Heinkel He 162 “Volksjäger.” Developed by Germany in the last days of the war, this ‘people’s fighter’ was a fascinating mix of then-high technology jet engines with cheap, wooden construction that could theoretically continue in small shops as Germany’s major aircraft factories were targeted by the Allies’ strategic bombing campaign. The Cutlass borrowed liberally from this idea, combining high tech role-specific gear (like the tractor beam and rotating engines) with a lower quality hull. To further reinforce this idea, marketing decided to price the Cutlass $15 below the Hornet or Freelancer. Later, I would get to integrate this backstory into the Drake Interplanetary profile in a Jump Point!
The result of this thinking was published in a Comm-Link update as the Cutlass and the ‘Pirate Pack’ went up for pledge. This is the same material provided to Chris and to Jim Martin upon which to base his concept artwork.
Drake Interplanetary claims that the Cutlass is a low-cost, easy-to-maintain solution for local in-system militia units. The larger-than-average cargo hold, RIO seat and dedicated tractor mount are, the company literature insists, for facilitating search and rescue operations. While it’s true that Cutlasses are used throughout known space for such missions, their prime task and immediate association is with high space piracy. Cutlasses, often operating in groups, menace distant transit lanes to prey on hapless merchants. A single Cutlass can ravage a mid-sized transport and a pack operating as a clan can easily take down larger prey. STOL adaptations allow these interceptors to operate off of modified transports or pocket destroyers; the most common warships that make up pirate caravans.
Designer note: the idea is that Drake Interplanetary builds ships which are ostensibly for legal purposes (local militias, etc.) but are ‘obviously’ for pirates: so it has the appearance of a military fighter, but mated to an awkwardly larger hull for collecting loot; it should have visible forward-facing tractor beams and a seat for a second crewman even though there’s no turret (as you’ll need a second man to board an enemy ship.) It also has a cheaper build quality: if Anvil is building Jeeps and Origin is building BMWs, this is a Honda.
To further appreciate the intent behind the Cutlass, it might be valuable to look at the original specifications compared to the other ships in the same tier, the Freelancer and the Hornet. Note that these specifications are long out-of-date… but they speak well to the intended role of each ship.
From these numbers, you can see the early attempt to balance the Cutlass as a sort of fighting transport midway between the Hornet and the Freelancer. Over twice the cargo of the former, half that of the latter… but with better weapon slots, more maneuvering thrusters and a lower mass to avoid being a lumbering transport. With regards to the oft-debated maneuverability, the biggest inspiration for this idea was the initial concept art that came back from Jim Martin, which reminded me of the Vampire from Wing Commander Prophecy. We discussed quite a bit the idea that the Cutlass might be especially maneuverable, but unreliably so: engines on an axis that would offer, for instance, exceedingly great yaw but limited pitch or roll. The sort of ship that might require an expert pilot to truly handle well.
With that, the Cutlass began the development process… with several stops along the way! As with any creative process, what is listed above was the starting point. Over the past two years, the team has experimented with everything from a maneuverable Cutlass that spins rapidly on the axis of the twin-boom engines to a Cutlass that’s a pure transport. Knowing that there were a significant number of Cutlass pilots, we wanted to give players access to the ship as quickly as possible despite the fact that multi-crew ships and any piracy-related mechanics were much further off. In fact, both of our first two major module releases had ‘partial Cutlasses’ released for them: the large external concept model in the Hangar to tide captains over until their ships were modeled and then the ‘dogfight oriented’ single-pilot Cutlass added to Arena Commander 1.0. Neither version expressed the true purpose of the ship as originally announced, but both were intended to tide players over until they could begin raiding shipping lanes in the finished universe. For more details on this process, we will turn this article over to our RIO, designer John Crewe, to walk you through where the flyable Cutlass has been and to talk about where it went and where it’s going!
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
WHERE WE WERE: The Cutlass Takes Flight!
by John Crewe
The Cutlass Black became flight ready with the release of Arena Commander v1.0 back in December 2014, but the road to getting it flight ready was an admittedly rocky one. After the initial block out by the ship team in Austin at that time, the Cutlass was worked on by a variety of people, including internal staff and several different outsource companies. The ship pipeline at the time was both young and extremely complex, and in review the resulting work had not been completed in a way that made it easy to implement in game. The unfortunate truth was that the asset that you’d had sitting in your hangars for some time had some serious design flaws in relation to its thruster placements; chief of which being the lack of any that could believably provide lateral thrust for strafing and yaw rotation. The only thrusters that could achieve this were the gimballed central ones, and because they were only centrally located, they unfortunately just couldn’t provide sufficient rotation as needed.
In addition to this, the Cutlass also required some new thruster setups that had never been created for any of the Star Citizen ships before, and as such this new ground was being tread right up unto the release. We had for the first time in our development main thrusters that could rotate and act as the thrusters that provided retro thrust. We also had those central thrusters which could not only pitch/yaw but also roll, and at certain angles would limit rotation in other axis! The final part of the thruster issues with the Cutlass is having child thrusters, which the main thrusters are supposed to have but have been absent since the flight ready release. Long story short: the original IFCS system was never written to account for thrusters with thrusters on them and the handling behavior would degrade completely, so we’d removed them until we had a chance to look at that system; work which will be included in the forthcoming model update.
John Pritchett and myself spent many evenings in the build up to release trying to solve these issues and whilst they solved a lot, a few persist to this day, which required some non-ideal solutions at that time, like the incredibly fast rotating thrusters and the fairly slippery handling that results from non-optimal thrusters.
The final bump in the road for the v1.0 release was the delivery for the damage states and LoD’s was massively behind schedule and came in very late, barely days before the v1.0 release date leaving very little time for implementation, evaluation and optimization. This is always an unfortunate occurrence in game development, but because we knew this was the beginning of things and not the end, we implemented the best interim solutions we could at that time.
It is safe to say the Cutlass has suffered from a lot of issues, but we’re intent on making amends (read on to find out how!) It became clear after its flight ready release that a lot of work had to be done to get it to the standard required and as such Foundry 42 was tasked with investigating a review and revamp of it.
The designers at Foundry 42 took a look at it and worked up a proposal to keep the unique exterior shape but allow as much interior modularization as possible. At that point the ship was split up into four sections. Here are some bullet point features we want to implement in each section:
Contains a pair of escape pod beds on one side and a utility area on the other side.
Small additional weapons locker, shower/toilet and turret access.
Storage built into space between current interior and exterior hull, especially for smuggling.
Turret access is retained in this area although the entry hole will be made to the new standardized 2m, to match Docking Collars and as such if destroyed makes the perfect extra docking point for enemies.
Similar to the current rear of the Cutlass but have the docking collar move to the ceiling rather than being on the floor of the cargo bay.
Sealed from modular room to allow it to open during flight without depressurizing the entire cargo bay.
The docking collar is also moving to the new standardized size of 2m wide which will allow 1SCU crates plenty of space to be transferred through and the ramp is wide enough to support larger items as well as being directly loaded onto the cargo lift.
In addition to this, there was a small selection of exterior adjustments decided to aid the overall handling such as bringing the rear engines more in line with the front canard wings and adding better placed/integrated thrusters to the front of the ship as well.
Once the initial design pass had been done it was passed over to the concept team who started doing paint overs using the existing white box designer geometry. Some of these concepts were released during the Cargo Design Doc and the rest are included throughout this post.
Shortly before work was due to commence on the “Cutlass rework” the priorities on the ship schedule changed, and as such the Foundry 42 Ship Team (at the time, only a few people) were moved on to finishing other ships such as the Gladius, Gladiator, Retaliator and Idris, which you have all now seen at CitizenCon as well as a few others you are yet to see.
Because of this, the task of creating the revamped Cutlass was given to an outsource studio with guidance from the team. In an effort to avoid the same mistakes that were made with prior outsource partners, they were actually embedded within the F42 studio for a fortnight so we would have the proper oversight and be able to provide the most immediate feedback.
Unfortunately, as happens in game development, the priorities changed again, as we realized that other needs at that time trumped the rework of an existing flyable ship, and as such around June the Cutlass Black rework was put on the back burner as other ships came through the pipeline. This is an unfortunate reality of development, as there are only a finite number of resources available, and getting more ships built allows other members of the team complete their work sooner, as opposed to slowing multiple departments as they wait on one team to rework the Cutlass.
WHERE WE ARE: The Cutlass in Alpha 2.0
For Alpha 2.0 the Cutlass Black is receiving an interim update for a variety of reasons, primarily performance. It was by far the single most expensive ship in the game in terms of memory usage, as everyone will have experienced playing AC with the severe hangs whenever one spawns or dies. We managed to improve that somewhat over subsequent patches from the programming side by pre-caching it, but at the end of the day the raw assets just weren’t optimized enough to be suitable going forward.
We decided a few months ago that rather than rushing to try and get the reworked Cutlass out for 2.0 we’d spend the time “upgrading” the old version to improve the experience for everyone when one is involved in combat. Not only have we totally redone the damage setup using the new damage shader system but we’ve also added in the basics of the new Multi Crew UI screens as seen in the Constellation and Retaliator. By doing this work the actual source .max file has shrunk from just under 2GB down to 550MB, the in game .cga assets have also been reduced from two assets totaling 405MB down to a single asset under 30MB. Not only is this better for the game but also massively better for us developers as it was taking nearly 40 minutes to commit the .max file to Perforce previously on our old office connection, now it’s under a minute.
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
The result for players is that it allows the Cutlass to be managed just like those larger ships and gives us valuable feedback on the usability of those screens on a much smaller scale ship, both in terms of size and crew count. The Pilot has a revised cockpit display with new multi-function displays and the co-pilot seat has an all new single 16:9 display allowing oversight to many features whilst controlling specific engineering style tasks. In addition to the UI screens we’ve also done a quick usability pass on the ship, tightening up the interaction prompts for all the buttons and adjusting the button locations to be not quite so jammed in and making the external buttons a bit more visible. There should be no more cases of trying to open the cockpit door, whilst accidentally lowering the turret or ending up in the jump seat!
On top of the multi-crew update the ship has also had a complete thruster balance pass to go with the new IFCS system which should help limit some of the more unexpected behavior you experience in AC today along with improved speeds and handling allow you to catch up with your prey easier.
Lastly and most importantly, we are bringing back the cockpit fans which have been missing in action since v1.0. We expect this was the only aspect of the rework anyone was interested in, so let’s consider the Cutlass “finished.”
Just seeing if anyone is actually reading this. We’re kidding, of course. But not about the fans. Those are really back. =)
WHERE WE’RE GOING: Plans for the Cutlass Going Forward
With the split of ship manufacturers between studios, the Cutlass (being a Drake ship) has moved over to LA for them to implement the above design rework alongside their work on the Herald and Caterpillar. The current ship schedule is very full, with all the ships required for S42 taking priority and most being done at Foundry 42, as such the interim update to the Cutlass for 2.0 fills the need we have for it in the short term.
As the concept and designs for the rework have been finished, this reduces the amount of time needed for the eventual Cutlass rework to be completed. It’s just a case of finding time in the schedule to complete that work, especially when it has to compete against other ships which are not flight ready in any form, yet.
In addition to the rework the Cutlass will benefit from all the ongoing updates to ships such as the new component system rollout which will allow players to customize their ships much more than is currently possible, and we hope to have a more thorough design post on this exciting system soon. Other updates that will be coming online will be updated turrets and mounts to allow a variety of weapons, the first recently released was the S4 fixed mount allowing Cutlass users to wield the hefty Behring cannon. The plan has always been to allow players the choice of setting their ship up how they want, but in v1.0 the turret was slaved to the pilot simulating a remote control turret. For 2.0 it is now a dedicated manned turret which in future will allow it to be slaved to either seat, manned directly or controlled by AI.
The Cutlass is designed to be operated by two people (MAX Crew is NOT the same as REQUIRED or OPTIMAL Crew,) with a pilot and another who can choose between sitting in the RIO seat and managing ship systems or taking direct control of the turret to provide offensive capabilities. That doesn’t mean you have to roll with just two people, you can always recruit a bunch of your buddies to ride in the back to take on any jobs you see fit although there are only two escape pods…
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
One of the most popular questions/complaints is about the variation in stats for the components in the Red and Blue versions and as always our answer is “All stats are subject to change” and the Red & Blue are no exception.
The current stats for the variants will be reviewed when the Black revamp takes place as that will dictate the base level for the variants, expect the Blue to still have some edges as you’d imagine from a Law Enforcement variant.
The Red version will still maintain its search and rescue capabilities with an integral escape pod recovery mechanism in the central modular room along with medical pods and hospital equipment. The turret will also be swapped for the scanner array and of course its exterior paint job.
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
The Blue version still retains its additional missiles and prisoner cells although their arrangement is still to be decided. They currently sit around the edge of the hull but may move onto the central cargo lift to allow all of them to be lowered out of the ship together for easier prisoner loading/unloading.
In regards to the exterior styling there will be a push towards unification of the base meshes between all three versions so that one exterior can be used across them all with only small “bolt on” pieces like you find in the Vanguard series to differentiate them, along with their recognizable paint jobs of course. This means the cockpit geometry will most likely be different than to what is currently there whilst we find the best compromise between them all, but rest assured: no more bars through the viewline!
Questions from the Community
As demonstrated with CR comments in the WIP and the ship commercial it was lead to believe the Cutlass would be a nimble ship. However the current iterations have made the ship otherwise. Has CIG taken a new direction for this ship?
As we’ve covered in the post above the Cutlass has suffered at the hands of numerous setup and design issues which we’re dealing with. The direction is still the same, it is supposed to be nimble for its size and type especially considering the other roles it can do and with the IFCS changes coming with 2.0 it certainly performs significantly better than in 1.3.
Why would a Police, Bounty hunter, CSAR, and Pirate use the slowest fighter in the game? Shouldn’t speed and combat capabilities be more important than raw cargo capacity for those roles?
See above, it no longer handles like a slippery superfreighter with the IFCS changes in 2.0 and will get better when the reworked Cutlass is released. The Cutlass can easily catch up with other ships and mix it up with them.
Currently the loading bay & Docking collar are too small for SCU to pass through it, is this intentional or will it be fixed? Will the cutlass receive a way to load cargo pods and other bulky items?
The current docking collar on the Cutlass is 1.3./2.0 is 2.2m wide, larger than a regular 1SCU crate which is 1.25m * 1.25m * 1.25m. The rear ramp is also 1.8m wide and 2.8m tall, again more than enough to receive cargo in multiple sizes. The cargo lift for the rework of the Cutlass can accommodate larger items as well, but if you’re wanting to transport large/bulky amounts of cargo then the Cutlass is not the ship for this.
Is the Cutlass still intended to be a 3 to 4 crew ship instead of the 1.5 crew ship she has been initially sold as? What sized crew is the Cutlass rework designed around?
The Cutlass in 2.0 and the reworked version, is designed around supporting two crew. One pilot and one for either providing additional multicrew support via the second seat or providing offensive power via the turret. Down the line you’ll be able to slave the turret to one of those seats or add an AI module to allow it to be independent of the seats just like any other turret in the game would be capable of. Just because we say two crew does not mean that is the absolutely minimum or maximum, one person is able to fly and fight with it at a basic level. Adding that AI module I just mentioned would allow it to be on a par weapon wise with what is currently in 1.3. You could also man all three seats or have a couple of guys on the jump seats in the rear to provide extra support during landing/boarding “operations”.
The Cutlass seems to be in the awkward position of having the speed and handling of a multi-crew ship, while retaining the armament and defenses of smaller fighters. What benefits does the Cutlass have over a smaller/faster single person ship, or a bigger/more armed and armored multi-crew ship?
As discussed the speed and maneuverability have been increased significantly in 2.0 which will not only help with offensive options but also for defensive needs and evasion of missiles. All the ships are due for updates in the future regarding their health as the new component system comes online along with piercability of the hull which will change how ships behave when being damaged. The Cutlass benefits from having a second player being able to dedicate themselves to managing the ships systems (shield/power management for example) or turret versus a lone player having to manage it all.
It is not designed to go toe to toe with the regular multicrew ships like the Connie, Tali or Freelancer who dwarf the Cutlass not only in size but also weaponry and crew size. The Cutlass sits in a role that can bridge the single seater and low end multicrew ship roles and function in either camp or somewhere in the middle.
Cutlass Resources
For more information about the Drake Cutlass, consult the books in your local library… or check out some of these previous posts concerning our plans and objectives for the little pirate ship that could.
tl;dr – the Cutlass has had a complex development history, with multiple voices wanting different end goals. The Cutlass will become more maneuverable with Star Citizen Alpha 2.0, but it will not drop the focus on being a fighter WITH a cargo hold intended for piracy (or search and rescue, as a Drake salesman would say!)
We hope that everyone has found at least some of the answers they are looking for. On a personal note, a huge thank you to Lead Technical Designer John Crewe in the UK for taking the time to indulge us in this crazy endeavor. We will consider a supplemental edition of The Shipyard in the future to clean up any issues that arise from this and the launch of Star Citizen Alpha 2.0.
No one ship can be all things to all people, and it shouldn’t be even if it could. As with all these ships, the Cutlass may not be what everyone wants it to be and as such there may be other ships that are much more suited to your playstyle. One such option is a potential ship we’re calling the Drake Buccaneer, which would be a ‘pirate interceptor’ intended more for tricky maneuvering than cargo capacity. It would likely feature light armor, a shorter range ‘sucker punch’ style weapons loadout and a significantly more limited cargo bay. Buccaneers would need to operate alongside of Cutlasses or even as parasite fighters attached to a Caterpillar for more serious raiding missions. If we go ahead with the concept, it would be intended to fit the same price range as the Cutlass, allowing owners who prefer sheer maneuverability to switch designs with impunity.
We’d like to know what you think, both about the Buccaneer and this style of post. Two polls are embedded below to help us decide what to do next! Cast your vote to let the Star Citizen team know what you’re thinking, and be sure to post your comments below.
Remember there is no such thing as a perfect ship, just the perfect ship for you.
Alley Wrote:In the next patch, the shipcompat component of the technerf system will be removed.
For those who don't know the specifics of it, the technerf system works as the following:
- 1: It will check your ship for a control item (IDs in our case)
- 2: If so, it will apply nerf multipliers depending on what is defined in the techcompat configuration (ex: Order Guns on a Blood Dragon ID, or Order Ship on a Blood Dragon ID)
- 3: It will check another configuration, the shipcompat one, that oversees what this ship itself is compatible with (ex: A Battleship Scanner on a Percheron will work at 0.75x efficiency no matter what the pilot is flying as)
- 4: Prepare the soup and stack the nerfs.
Part 3 of this system will be removed. While it does make some sense, it's awfully complicated and simply ruins the game in many ways. It also cause the admins to lose an incredible amount of time trying to get things to work properly and usually cause faction tech requests to take an awfully long time because each ship belonging to the tech mix must be changed in the shipcompat configuration to account for the change if it's something really wild.
Now, the lowest tech element of your selection in the techchart will be the nerf you will fly with. They do not stack.
Example: Freelancer ID -> BHG Manta (75% on FL ID) + Bretonia Civilian Weapons (90%) = 75%. The lowest common nerf percentage is 75%. Your ship will fly with a 75% powercore.
Again, it's expectable some people will pull odd stunts of OORP mix techcombos. These guys will be dealt with by the rules for OORP. Ensure we don't have to smack you and all will be good. (IE: FL ID, GRN Lynx, Corsair Guns without any very very solid reasons = you get obliterated).
Needless to say nobody will miss this and technology perk requests should be processed much faster.
Hidamari Wrote:Long overdue.
SummerMcLovin Wrote:Good to hear, saves me having to ask for standardisation of Gallic/Sirian Engines to match cross-divide technerf values. Saving the work of the admins and devs is also good news.
TheFreelancer Wrote:hmm, i like!
jammi Wrote:Good stuff.
All I can say is "cleanup in Isle 3" when Karst sees this.
Alley Wrote:updated first post with precisions on how the system will behave.
Adam_Spire Wrote:How does this effect Special Roleplay Requests and their power nerf/setup?
Alley Wrote:Nothing will change for SRPs
Thyrzul Wrote:I see 5th paragraph and I wonder perhaps it'd be better to include that in rules as well, under the relevant one, to make sure there's definitely an official place not hidden under random archives over time where people just can't miss it. Just a thought.
JayDe Wrote:Finally. Many weeks passes since I asked to fix Farmer Alliance ship chart. Now it will be done in one large way to kill the entire problem for everyone.
For those of you who have followed the twitter updates, you probably know already this was quite a bumpy road.
For those who didn't follow these developments, essentially the server's raid controller died out of the blue. I'm not going to go into any details, but it was a very exhausting and unpleasant experience that even got me into trouble at work. Either way, we're finally back up and that's what matters.
Unfortunately due to -reasons-, while we have daily backups of the server accounts, it turns out there were no backup system in place for the forum and wiki data. I initially thought we had no backup at all (which means we'd have to restart from zero) I discovered a backup from August 21th back when I was running local tests on my personal dedicated servers. So yup, we've lost a fair bit of forum stuff, but at least we're there.
It's a really bad event for disco, but it could have been much worse. Together, we'll have to rebuild what was lost.
October was a busy month! The worldwide Star Citizen development team is hard at work getting Alpha 2.0 out the door, and we’re very excited about getting this one into your hands. In the past, our module releases have each shown a small part of the picture: ship configuration in the Hangar, social interaction in ArcCorp, single-seat dogfighting in Arena Commander… and now we’re leaping ahead and giving everyone a very early preview of Star Citizen’s beating heart. From multicrew ships to first person combat on the ground, Alpha 2.0 is our first serious look at how the puzzle pieces fit together.
We’re eager to share it, and to collect your feedback… because this isn’t the end of the road, it’s the start of a process that will culminate in the launch of the Persistent Universe. On top of the base that is Alpha 2.0, we’ll be building everything else necessary to creating a living, breathing ‘Verse… and we’re truly looking forward to sharing that process with the community. The following monthly report will update you on exactly what each of our teams has been doing to help reach this very important milestone!
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Hey everyone!
What a month October has been. So many accomplishments leading us through another strong month has gotten us excited about what’s coming your way. The amount of work being completed and released is motivating us to push through to our next major milestone. The in-depth Santa Monica update is below so please look it over and let us know what you think!
Engineering
This month the Engineering team has been working closely with our UK office and the Santa Monica Designers to continue pushing the boundaries of what is possible.
Lead Engineer Paul Reindell has strategized how our Item System is being revamped and made excellent progress towards its completion. The “ItemSystem 2.0” is designed to be more lightweight, and therefore less resource intensive. Rather than implementing all of the common functionalities into one CItem class, the Engineers have split the functionalities into standalone GameObjectExtensions (GOE’s), allowing them to remain self-contained. By accomplishing this, those systems can and will intercommunicate with one another. As an example, if a different character model is loaded, the effects can then be re-attached to the new model at the GOE level.
AI Programmer Chad Zamzow has made improvements to how the radar works by fine tuning the system to be much more effective at how it represents (or excludes) occluded or partially hidden objects. Further tuning has also been made to the rotational limits of turret hardpoints. He has created a smarter, more realistic system by allowing the Tech Designers to specify rotational ranges of each turret hardpoint. This will prevent turrets from unsightly/immersion breaking clipping through a ship’s hull mesh and any broken gameplay effects or exploits that might accompany such behavior.
Our Flight Engineer John Pritchett nd Designer Pete Mackay have been implementing the new flight modes to our IFCS. These new flight modes not only give players greater control over their velocities, but also provide a means to accelerate to the awesome looking Quantum Travel. Furthermore, John has also been working on integrating the IFCS system into player EVA movement, giving players fine-tuned control over how characters will move around in the near-zero gravity environment of space.
From the UI/HUD team, we have been busy at work completing the 16:9 diegetic screens for the multi-crew-capable ships. This format gives multi-crew screens improved real estate over which information can be passed on to other stations as well as broader details for each respective role, such as a ship’s engineer. We’re really excited about what we accomplished and hope you will be too.
Design
With the Multi-Crew/Large-World release targeted within our sights, the Santa Monica design team has been hard at work, meeting several important milestones that will make it the most epic one yet.
For the Multi-crew release, we’ve prioritized recent design efforts around how the redesigned Constellation will handle during flight. As the Constellation is one of the most anticipated ships in the game, Lead Technical Designer Kirk Tome has been overseeing the tech setup of the Constellation, tuning the flight characteristics and center of mass. The lessons learned during this process will provide the pathfinding R&D needed to manage flight and control over ships in the Constellation’s size group generally.
Beyond the Star Citizen Alpha 2.0 release, the Design team has been making sure plenty of upcoming content will keep everyone excited and happy with their personal favorite ships. Designer Randy Vazquez has written the technical documentation on how the Salvage mechanic will work in-game hand-in-hand with designing the Crucible salvage-capable craft. Other ships that have met progress milestones this month are the Reliant and Xi’An Scout.
Investigations into new combat mechanics have been spearheaded by designers Matt Sherman and Calix Reneau, not least of which is the EMP weapon system and how ship systems can be affected by other types of attacks such as disruption to heat dispersion or disrupting the flow of energy to various ship components. This Distortion Damage is specifically designed to disrupt and drain power from nearby components. We know that the disruption cannons haven’t been very popular in Arena Commander so far because the disruption effect was still being designed – but that’s going to change for the better! As you can see, we achieve many of our larger milestones this month and are ready for another excellent month!
Art
This month has been an incredibly productive month for our art team. We’ve put the finishing touches on the baseline Constellation asset, finalized ship and character concepts, completed rigged and animated character models, and more!
We achieved some major accomplishments and even large tasks for major ships like the Constellation and the Reliant. We finished the functional animations for the maneuvering thrusters, landing gear, missile launcher, escape pods, docking collar, turret doors, to mention a few – all needed to prepare this amazing ship for its first large world release.
Delivering Admiral Bishop was a major milestone for our character pipeline. We took him through all the steps needed to populate Star Citizen full of rich and animated characters. Everything detailed in our character pipeline video revealed this month shows off just one of the several steps to bringing our characters to life.
We delivered several needed concepts that are fueling production of Squadron 42 which we’re really excited to show you as soon as possible.
That does it for our art team this month and looking forward to sharing more next month.
Writing
Well, now we can talk about what the writing team has been up to the past few months.
Starmap!
So much Starmap.
As you can now see, we had over ninety systems and over three hundred planets to work out. While Dave has been chipping away at the systems since the project began, there were still a lot to figure out. Will, Cherie, Adam and Dave would set aside time each day to discuss the unexplored systems to figure out the basic information (star type, number and type of planets, other points of interest, etc.) but more importantly try to get a sense of what the character of the system would be. They’d ask questions like, what was the system adding to the Star Citizen universe? What kind of narrative potential could exist there? They also worked closely with Benoit and Turbulent to input the systems into the map itself. As we got closer and closer to release, they shifted onto double-checking the data, doing final sweeps for any typos and basking in the Galactus-like power of manipulating a universe.
After its release, they’ve been continuing to tweak the descriptions and working with the science consultants to generate the more detailed astronomical data for the systems and planets, but mostly we’ve been working on PU needs which have been coming in hard and fast.
At the same time, Dave has been over in the UK to sit in with Chris for editing selects for Squadron 42, while the team continues the push to help provide narrative and dialogue for the Crusader map. Specifically… dammit… can’t talk about that either.
And that’s it. The end of October brings another month of immense progress from Santa Monica and ever closer to the final product of Star Citizen. Thank you for working alongside us as we bring this expansive world to life and see you in the verse!
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Greetings Citizens,
During the month of October the Austin studio has been hard at work and there have been a number of accomplishments. The team worked very hard to support many parts of the game that were demonstrated at Citizen Con, and we are very excited to be in the later stages of testing Star Citizen Alpha 2.0 and the Crusader System for upcoming release to the PTU. We’ve had a number of team members visit other studios for collaboration, and we’ve been focused on some internal reorganization to adapt to CIG’s evolving global footprint. Here are detailed reports from each team.
Persistent Universe Team
This month our PU team has been looking ahead towards upcoming releases, working on brand new features that will add to the Social Module experience. Mark Skelton and the PU Art Team have been putting the finishing touches on the Million Mile High Club. Complete with a dance floor, fish tanks, and Bartender and Doorman NPC’s, this luxury lounge will go out to a select group of backers and we expect it will be the envy of all who come to visit.
We’ve also shifted the Environment Team’s focus from Stanton to Nyx for a time, and we’ve got BHVR working to complete the Levski landing zone to get it in your hands soon. We’ve been going back and forth on the blueprint for certain areas of Levski, particularly the bazaar marketplace area, to make sure it is laid out exactly the way Tony wants. Levski is going to be completely different from Area18, and being the first Frontier world we will have released we hope it will scratch a mischievous itch amongst the community.
Additionally, we’ve been working on an additional shop in preparation for our Shopping Milestone. Casaba Outlet, once released, will introduce the first iteration of the in-game store and purchasing experiences. Tony, Zane, and Karl Jones have been working together on creating the brand new Shopping UI and it is looking really fantastic. The environment itself has had a design/layout pass by Rob Reininger and is now undergoing art polish right now by the team at BHVR. Casaba Outlet is a clothing shop so naturally it requires the creation of several new civilian clothing assets. We’ve partnered up with CGBot for this purpose to bust out some clothing assets from the Terra>Fashion Casual line.
We’re also recommencing discussion on how Character Customization will work in Star Citizen. We’ve had several ideas tossed about, and we expect to have an initial iteration ready for you guys to go along with Shopping. Sean Tracy has been working on a prototype to pass off to BHVR to take to fruition. We’ve also been generating more content to go along with this first iteration, including Billy Lord creating more hairstyles, and the clothing assets mentioned above.
We’re also in the process of adding new animations to the game for use by NPC’s in preparation for when we get Subsumption (our Peaceful NPC AI system) up and running for our NPC’s. David Peng and Vanessa Landeros have been working on Nightclub and Medical Unit animations, respectively. Bryan Brewer has also been polishing our Male Locomotion Sets and will be moving onto Female Locomotion Sets soon.
As always, it’s been a busy month for the PU Engineering team. A lot of work went into getting our recent SC Alpha 1.3.0 release out live, including a few pushes to PTU leading up to that release. With that release we introduced some new features into ArcCorp….namely the buggies and the respawn functionality needed to handle the multitude of insane deaths caused by buggies. A lot of work dealing with physics and collision issues went into this release (we knew you’d be putting those to the test!). We also increased the player count for ArcCorp up to 40 from 25, which was accompanied by some significant performance optimizations to ArcCorp. But that’s not all! We got in some new chat functionality, such as the private chat channels, so players can chat privately with their cohorts. These improvements were the result of a great cross-studio effort between our various CIG studios and friends at Behaviour and Wyrmbyte.
We’ve also maintained a heavy focus on upcoming releases that are planned for the coming months. Working closely with Behaviour, we have been putting together our party system and additional functionality for the hangar elevator interface. A ton of work has been put into optimizing performance throughout various area of the game, as well as strengthening our existing backend services and adding new services. We’ve been working hard on character networking optimizations…and all sorts of under-the-hood work that will greatly improve the player experience.
A series of networking meetings over the past several weeks have wrapped up, allowing us to begin getting together technical documentation needed for some of our longer term planning and road-mapping for essential networking systems.
Last but not least, in addition to tackling the many bugs that came with launching the recent live release, we’ve has been busy knocking out tools and editor bugs to help support a variety of developers in creating new content for Star Citizen!
Until next time, we hope you survive the post-Halloween candy comas! We can’t wait to get our next release out to you.
Live Operations
QA
QA charged into the month of October at full speed. The first part of the month was devoted to testing our live demo for CitizenCon. We were very happy to see the presentation go as smoothly as it did and are extremely excited to get Alpha 2.0 in everyone’s hands.
Immediately following CitizenCon, we shifted our testing to the live deployment of Star Citizen Alpha 1.3.0. After five deployments to the Public Test Universe, we had a potential candidate to release to the live environment. There was some discussion to potentially release an additional patch to address some remaining outstanding issues. But the decision was made to focus on Star Citizen Alpha 2.0 and roll any potential 1.3.0 fixes into that release.
The remainder of the month has primarily been focused on testing Alpha 2.0 and the Crusader system. Our counterpart QA team in Foundry 42 has been conducting in depth performance testing and providing the information to our engineers in their efforts to optimize Crusader as much as possible.
Our ship expert Andrew Hesse has been working very closely with Designer Pete Mackey and Physics programmer John Pritchett testing the newly implemented IFCS modes for each flyable ship. Additionally the team has been working with Technical Designer Calix Reneau in his efforts to balance ship flight. Each ship’s flight characteristics were tested in 1.3.0 and then again in our SC Alpha 2.0 code branches. Calix is now able to compare ship flight in both environments which will help him to more effectively tune each ships’ flight characteristics in the progressing SC Alpha 2.0 branch to his intended specifications.
This month we have a new addition to the US QA team, Vincent Sinatra! Vincent will be filling the role of QA Lead in our LA studio. Vincent has a wealth of experience as project lead on multiple titles. Some of which include Doom3, Quake4, Enemy Territory: Quake Wars, Call of Duty Black Ops and Call of Duty Elite 2.0. Vincent will be focusing on testing each ship for proper flight characteristics and system functionality as well as any special projects requested by development in the LA Studio.
This month we also had our engine and editor expert Melissa Estrada travel to our Frankfurt office. Melissa spent a week training Senior QA Christopher Speak on our various Star Citizen specific processes and procedures. They also spent time discussing our automated testing development in detail. It was a very productive trip!
Right now we are continuing to focus our testing on Star Citizen Alpha 2.0’s internal test builds and the Crusader system. We are having a lot of fun with it and very much look forward to getting it out to everyone as soon as possible.
Game Support
The Game Support team continues its work serving players, and yes, we’ve been just as excited as you about CitizenCon and everything that was shown there!
We’ve been continuing to assist players with technical support issues, and we’ve turned out attention to incoming reports of hacked accounts. A note to those reading: We’ve started to see a rise in unauthorized access to accounts, so make sure you are keeping your information secure and don’t share with anyone!
On a side note, we’re just as thrilled with the rollout and usage of the Issue Council as everyone else! While largely maintained by our QA team, we’ve been making sure the most pressing issues get attention, and with the 1.3.0 release, we saw our first bug reports entered in by players and fixed by the dev team. We’re excited to continue this process as getting player feedback is absolutely essential to building the BDSSE. Over the next few updates, we’ll start publishing those results for you so that you can see how this has affected the dev cycle.
As we have pushed out 1.3.0 to players, we’re extremely excited for what’s on the horizon for 2.0. As the needs of the game and community grow, so does the demand on the team. We’re very close to bringing on our first team members in Manchester which will expand our hours of operation and help lower the response time for when you send in a ticket to us.
Speaking of 2.0, we’ll be holding controlled PTU play sessions with players as we did for the Social Module. We’ll slowly ramp that up over time, and we will have a special place for those players to provide feedback and bugs. This will be an essential process to collecting information on the 2.0 release, and we’re very excited to help make this good as it can be before going to Live.
IT/Operations
The month of October flew by for the IT team and as usual we got a chance to roll out some new services and a number of upgrades. As the pace of builds continues to increase we still need to keep up with the data delivery between all studios. Fortunately we keep finding new ways to improve our long haul transfer times to levels we couldn’t have expected the month before.
Moritz joined the IT team as our new Systems Engineer in the Frankfurt studio. Moritz has deep roots in Germany and brings many valuable vendor and service provider connections along with him. He had to hit the ground running because we were all too busy supporting CitizenCon to show him the ropes when he arrived. After the show we worked closely with Moritz to lay in some substantial improvements to the Frankfurt studio. Paul came over from the Austin studio and with the help of other members of the IT team throughout the company we implemented a new phone system as well as a sizable storage upgrade. Most importantly, we finally got the fiber internet upgrade installed which will make a major difference for the team in Germany as well as the rest of the company.
Last month our friends from Intel brought us a prototype server for performance testing of their latest SSD drives. This server is incredibly fast in every test we’ve thrown at it so far this month. We’re super excited to have the opportunity to performance test their new drives in various RAID configurations and can’t wait to put this server to the torture test of our game build and publishing environment.
Dev Ops
For the month of October, DevOps supported the new and improved Build system, added more analytics to the Launcher and supported CitizenCon!
Since changing to the new build system, we’ve been able to push more builds out than ever before (and you can see how this has enhanced the feedback and deployment cycle for Alpha patch 1.3. We couldn’t have done that before)! We’ve also added a feature that grants QA and Production the ability to deploy game servers for specific builds. This allows any member of our team around the world to now kick and deploy builds “On demand”. They no longer have to wait on someone else to deploy a server to a build that they’re working on. We are continuing to improve the state of the new build system with “nice-to-have’s” as the core functionality of the build system has been fully implemented.
We also made improvements to our internal builds page that allows devs to check the status of all builds, monitor builds, and copy builds without the need of opening additional tools. One central location for all of your build needs! DevOps improving the way we upload our game data to Amazon for a faster and smoother distribution to all of you wonderful people. We updated our launcher with some bug fixes and added some analytics to help improve our services.
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Greetings Citizens,
It was wonderful to see so many of you at CitizenCon earlier this month, and gratifying to hear that so many people around the world tuned in for the show! We hope you had a good time seeing first-hand some of our work, and there’s plenty more to come. Here’s the breakdown of what we did in October:
Design
October is done and CitizenCon is out of the way, now all the focus here is on getting the first phase Crusader build into your hands. We are working flat out to get it in a stable enough state to give you an impression of the scope of this incredible game. There are still issues we are closing out that need to be in a better state for release, such as EVA which is going to be an integral part of Star Citizen.
Quantum Fuel is also going to be a factor for players to manage and consider, adding a layer of realism and strategy to travelling around the universe. Service stations, run by Cry-Astro have begun to pop up around the Crusader map allowing players to refuel, rearm and repair; for simplicity and convenience in testing the Alpha 2.0 build, these will initially be free, but when REC comes online in future builds it will give players more to think about.
We have implemented several starter missions for Players to tackle that are dotted around the map, and as we continue to fixup the FPS gameplay we now have a specific location that will host FPS combat for those brave enough to dive in. All in all we hope to deliver enough content to keep you busy for a while.
Another happy side effect from all the focus on the Star Citizen 2.0 build is that we have been able to move design resources back on to Squadron 42 now that a number of critical blockers have been removed. We have been making great progress on the AI system with the team looking at getting something into future Star Citizen – Live releases in the form of an asteroid base for you to tackle.
All in all, another exciting month on Star Citizen where we are really starting to feel things coming together after all the time consuming, but essential technology work that the engineers have been doing to allow us to deliver the experience that you demand. As always thank you so much for allowing us to do what we do to make this fantastic game happen.
Audio
This last month has been somewhat split into two as far as our main focuses (foci?!) of attention in audio have been concerned.
Firstly, we had CitizenCon, which was massive of course, and to varying degrees occupied the whole CIG Audio team right up until the event itself. Apart from the solid work that was done, i.e. the material that’s all going forward into the game, we put in an awful lot of work to try to make sure it was the best sounding event as far as the live streaming aspect was concerned. From our perspective, we weren’t altogether satisfied with Gamescom and there was a lot more we could do about CitizenCon’s audio quality and prep; making sure it all went smoothly was so important to us. Stefan Rutherford has to take a lot of credit for that, he was there throughout assisting the audio engineers and I feel that it really paid off.
It was awesome finally to show parts of Squadron 42 which has been something we’ve been working hard on for some time, our Dialogue Specialist Bob Rissolo put in some serious work to make sure that the Bishop’s Speech and Morrow Tour came across as well as they did on the vocal side of things. Talking of the Morrow Tour (also another facet of Squadron 42) – that featured sound design from most of the team but honourable mention to Ross Tregenza who owned that and ensured it all came together. Geoff Zanelli’s music was great to hear for all the Squadron 42 sections too. I have to mention Darren Lambourne, Luke Hatton, Jason Cobb, and our audio code team Sam Hall, Mikhail Korotyaev and Graham Phillipson who all put in so much effort to get it all across the line.
Hopefully you all saw (and heard) the StarMap which Phil Smallwood and Matteo Cerquone owned and pushed forward with on the audio side. Some great music from Pedro Macedo Camacho there for that too.
After CitizenCon, our second big focus for this last month has been SC Alpha 2.0, which features a lot of what was shown off at CitizenCon and more besides. E.g. on the dialogue front, we’ve been carrying out sessions for updated ship computer material and a whole host of requirements for various points of interest. We’ve also been continuing work on the many points of interest that you will be able to explore.
As well as the Alpha 2.0 work, we’ve been continuing on the sound for the Social Module, with audio also now being started on for the Million Mile High Club. Somehow we’ll get some ‘luxury’ sound in there! Also the FPS work has continued, esp. on the Foley side, and we’re now really looking to improve the EVA sound-scheme to contrast with the in-ship audio direction.
Of course ships are a massive aspect of our game and we’ve been both improving how we approach these, as well as creating whole sets of new pass-bys for specific ships and manufacturers. So they won’t just sound cool as they thunder past you, they’ll hopefully be more readily identifiable. This concept of ensuring consistent characters to different ship types is fuelling much of our 2.0 ship audio approach.
We’ve also been continuing to evaluate 3D Audio tech with a view to choosing an ideal solution for VR and headphones. We get a lot of posts about binaural audio and that has some bearing here, clearly.
Thanks for listening!
Animation
After a big push on getting the pcap pipeline up and running in order to support the Squadron 42 “Morrow Tour” demo that was shown at Citizen Con, the UK animation team has now joined in with supporting the SC Alpha 2.0 release by getting any of the FPS animations in order – this has involved R+D work for some of the team here to get to know the ropes, and then polishing up existing assets and supporting the Design and Code team with what they need.
We’ve also been spending time getting the new animator, Oscar, settled in to the team in Frankfurt and getting him up to speed with the tech so that he can work fulltime with the FPS team in Germany for the duration of the project.
QA
The QA team in the UK have been doing the usual of juggling the requests from Dev and supporting the live releases such as 1.3.0. Earlier in the month we even had some of the CitizenCon limelight when our team demoed Crusader, the Morrow Tour and the ARK Starmap live on stage to the sell-out capacity crowd which was quite a bit of pressure!
We’re now testing the hell out of SC Alpha 2.0 to get that ship shape for its introduction!
Also we’ve grown in size, with a new addition to the team in Ben Hickton and have another tester on the way next month so we’re looking forward to having more hands on deck. In part this is to replace the void that Assistant QA Manager, Geoff Coffin and his lovely beard have left in the team after making a switch to Tech Design.
Graphics
This month the graphics team have been putting the finishing touches to a number of features such as distant shadows, multi-crew ship damage, the improved LOD system, advanced face wrinkle shader. We’ve covered many of these in previous reports but as we get closer to releasing the next version of Arena Commander we’ve had to stress test these systems and fix all the bugs to ensure the backers get a good user experience. We’ve also been looking at lots of performance issues because as we’ve been expanding our maps we’ve been stress-testing the engine in ways it hasn’t experienced before. These have mainly been CPU optimisations rather than GPU optimisations as larger maps don’t necessarily results in more objects on screen, but do mean we need to process a lot more objects to check whether they’re visible and also to update their gameplay/AI.
One of the next features we’ll be focussing on is more improvements to the face shader. We’re getting some great results from the advanced face rigs we have, but the memory cost is currently pretty high and so we’re trialling a new technique that will vastly reduce the memory cost to just a small fraction of what it is currently, with the bonus of actually achieving more detail, so we’re excited to get this tested and hopefully in-game soon. We’re also going to start a major re-work of both the UI rendering and shield shader. Both of these were written very early in the project and as the design of the game has become more finalised it’s become clear they need an upgrade in order to do everything we’ll need in the final PU. For the UI we’ll be integrating it more closely into the rest of the rendering pipeline which will allow it to fit better into the scene and also be slightly cheaper to render. For the shield shader the technique will get a major visual and performance improvement which we’re excited to get started on!
Engineering
Just a short update from the UK this month. After a really successful CitizenCon at the beginning of the month we’re now working hard to get the large world map out and released into the wild. A lot of this is polishing up what we already have, bug fixing and performance improvements, but cumulative small polish is critical for delivering a game that plays smoothly, even on a powerful computer.
This doesn’t mean we’re not doing any new features. We’re looking at improving the Retaliator’s damage so you can get it to split in two, which is a bigger task than might be expected. When a piece breaks off a ship like the Retaliator then what the game recognises as the interior also has to be broken in two and a new instance created. Also our debris system wasn’t network synced as the pieces from a fighter were small enough not to really be concerned about. This obviously changes when you have a piece of Retaliator debris bigger than the ships you’ve flown so far, then we have to start worrying about it being in the same position on all clients. We could have just hacked a fix in for this build, but we want to do things properly which has meant making that whole system more robust and future proof going forwards. Takes more time in the short term but you benefit in the long run.
There is a lot more going in which we hope to be able to show you shortly, but we’re now at the stage where it’s just a case of working hard fixing up all the current issues.
Art
A lot of time has been focussed into hiring again this month, artists across the board, from all over the world and we are still going – if only we could add another level to this building like the environment guys do! Concept team has grown by two and given us a good boost in being able to dial in concept work Xi’an Scout, MISC Freelancer and Starlancer. We have a welcome Senior Character artist added to the team and they has been a flurry of activity on characters for SQ42 and heads for promo pieces (giving nothing away here!)
VFX
It’s been full steam (and other ambient effects!) ahead for Alpha 2.0 release. Specifically this means we have continued to polish and optimise the ship damage effects as well as ironing out some functionality concerns we had regarding how the interior effects trigger in relation to receiving exterior damage. That’s all coming together very nicely.
Also we did a fully sanity check on ship thruster effects to make sure they were still behaving as expected post-IFCS update. Fingers crossed, all good!
Aside from the ships, there have been lots of ambient environment effects polish and optimisation for the new map – leaking coolant, steam, airlock effects, holomaps and general space dust/debris to name but a few. There’s been a real focus on making sure these effects are as efficient as possible due to the sheer quantity required to populate such a massive area. We place these on a per-location basis, but as there are several locations within a single map, the overall particle entity count can get pretty huge. Thankfully we have a plethora of optimisation settings to play with, so within reason the effects shouldn’t cause too big a performance hit.
We’ve also been working with the graphics engineer to ensure our particles are being correctly lit/shadowed based on location/placement within visareas.
We also began R&D on a new type of ship weapon – can’t say too much about this but its effects requirements present us with some unique challenges. Looking forward to seeing this one take shape in the near future!
Ship Team
Ship team has been growing, we have an influx of new starters, here we always start them on props to get used to the pipeline and then add them into the production process of the ships. So, to the meat of it – Starfarer Interior, it’s ongoing, pushing to establish hero areas of the interior of the ship which then serves as the kit foundation of all other areas within the ship.
For the exterior, we continuing to establish the MISC exterior shader set / style, working up thrusters and landing gear in tandem. Additionally, the AEGIS Vanguard is marching forward to Hangar ready, using existing shaders and mesh parts established during the Retaliator production.
The Freelancer interior and exterior: still early days but the ship is really taking shape and giving off the MISC vibes, cockpit fitting, UI and cockpit fitting have worked hard to come up with something new and interesting yet functional for this ship so watch out for further updates.
The Sabre, currently being Greyboxed to establish a solid mesh foundation to build from at this stage, we’ll give this to ship tech to take through its paces and identify any snags before going into final production.
The Prop Team
Now Citizencon is out in the public I can talk a bit more freely about what the Prop team have been focused on. Citizencon was used as a test bed for how we are approaching dressing the larger multicrew ships. The hangar dressing was a main focus, we concentrated on building all the engineering and diagnostic tools that the engineers need to keep their fleet in working order. A lot of work was also put into supporting the animations and performance captures, we have a good understanding of the technical set up required for getting the props working with the animation data. There is still a lot of work to be done on the smaller scale human props that we want to deliver, to really sell that lived-in feeling when you step on board these ships and environments, but the engineers are now geared up to fix any battle scars your fleet of fighters may receive!
The prop team is now focusing on 2 major areas, the ship components and the shopping experience. The ship components are super exciting for us, it’s going to pave the way in terms of ship customisation and performance. We are supporting the design team and making sure that all the options they want to give to the players from a game play point of view are viable from an art standpoint. So far its super exciting, the concepts are fantastic and we hope to have the first couple completed soon. Once we have the foundations in place we should be delivering new component artwork on a regular basis.
The shopping experience is part of the social module, it’s all about giving the players more options. I don’t want to give away just yet what shop is our focus but nailing that immersive shopping experience is our priority, making the shop feel alive and used when you walk and purchase your wares.
Summing this month up in two words, it would be dressing and customisation!
Environment Art
Optimise, test, polish, bug, repeat. This has been the mantra for the environment team since the demo you saw of SCA2.0 at Citizencon. It’s not the most fun part of game development but is an absolutely crucial step to ensure then end experience for the user is as good as possible.
The final level of dressing has been added to the scenes, everything from personal belongings left behind to half eaten boxes of Big Benny’s noodles – this process lets us tell small stories within the environment and hopefully adds the human element to the scene.
SCA2.0 has been the perfect proof of concept for large world environments and space stations for both the PU and SQ42, its shown how modular building sets can work and how amazing it can be to create space stations real time in the editor – simply amazing tech!
The environment team can’t wait to see you guys play 2.0, we want to see lots of videos of you guys exploring, and having fun within the sandbox
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Greetings Citizens,
Frankfurt is getting a bit colder this month, and the leaves are starting to fall off the trees. The team here is 30 strong now and we have numerous candidates across multiple disciplines that we’re in discussion with. We appreciate all the support we’ve been getting from the community. Here’s a breakdown of some of the stuff we’ve been up to this month.
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Weapons
The Weapon Art team has been working on a prototype for new scope attachments and experimenting with lens shaders.
The picture is the current result of this, showing the prototype geometry (not featured in the game, purely made for testing) from a couple of different angles as well as in ADS view.
We’ve also continued to develop the manufacturer style guides and the high level production pipeline for ship and personal weapons.
Design
On the level design side, Andreas and Clement have been looking into best practices of creating modular elements that can be used to build space-station-like-structures and experimenting with various ways of combining those into environments that, while allowing us to quickly build new areas, are still meeting our high standards of artistic & gameplay quality. This system also gives us the flexibility to quickly alter the flavour and content of an environment, changing it from something like a UEE to a pirate/smuggler space station.
On the system design side we have been focused on multiple things. Chris has been busy working with the Character Art, Tech Art & Animation departments ensuring our new character setup fits the new modular suit design. This needs to be done as soon as possible, as it affects all future FPS characters we will have from now on and doing it correctly now instead of waiting until later will pay off. He also worked closely with Francesco (AI) on finalizing the systems we need for our AI to function properly.
Another big task that is taking a lot of our time right now is re-visiting our Careers (both old and new ones), fleshing them out and trying to reorganize them each into component Player Activities and then split each Activity into its base Systems/Mechanics. There’s a lot of documentation work here but once done we will be able to have a clear picture of all the things the player can do in the Star Citizen Universe and what are the required systems are for it. This will also help production as we will be able to see what systems are needed for which career, allowing us to prioritise them.
Todd has been working with everyone involved in the FPS part of the 2.0 Baby Persistent Universe release, ensuring the quality of the FPS stays on par with what the backers are accustomed to seeing from Star Citizen.
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
FX
This past month, VFX has been working hard towards adding and polishing effects for the persistent universe and arena commander module updates that will be released soon. Some of the effects included are improvements to the quantum drive spool up and effects for the new repair drone. We have also been making libraries of various types of space dust to place around asteroid fields. Everything from thick fog, to various densities of dust and even some hot plasma gasses.
On the tech side we have recently had some improvements to the particle refraction. This removes the ghosting artifacts that were possible with the old technique. It also adds a new feature, the ability to blur the refraction. This is important to pull off certain effects such as heat haze.
The gif is a close up of the repair drones welding torch effect that was shown in the CitizenCon demo.
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Cinematics
Cinematics did some clean-up to the UEE senate scene so we can revisit it once Admiral Bishop’s dress uniform costume and other character details are finalized. (What you saw at CitizenCon was not fully final of course! We enjoyed sharing it but there’s more we want to do.) We also did some work on finishing the senate hall environment, including texture work and modelling the senate hall pieces with tables and so on.
We also reported and addressed issues like the lacking bone link dialogue in Sandbox and other cinematic related issues. Doing these highly polished bits once in a while is good for setting ourselves into “final” mindset and finding bugs or issues and address them early on.
After this we switched gears to another part of the SQ42 intro cinematics: A giant outdoor set involving an even bigger capital ship and our beloved Bishop. The scale of this set is seriously enormous.
We also started working on the first scene with Mark Hamill’s character and to say it is like a dream come true would be an understatement. We have a first version of the UEE pilot helmet on him that he & other pilots including the player will use and it just looks so cool!
We continued working on the McArthur Skydock, focusing on getting the textures where we’d like them, making normal maps and finishing up the diffuse and gloss textures, and built some new parts such as the huge columns and claws that hold the ship.
AI
During the first part of the month we have been focusing a lot on the Morrow Tour experience, improving and polishing the AISequences and how those are connected with the AI behaviors.
We introduced the possibility for level designers to requests activities in parallel like walking and talking, and we also made a pass on the Usables to properly utilize them as navigation links and started our iterations on Subsumption to create basic routines for AI NPCs.
After CitizenCon we moved our focus on mainly two areas: FPS AI and multicrew ships controlled by AI.
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
FPS AI – First of all we have extended the zone system to be able to register general AIZoneObject so that we can have multiple AI objects connected with the zone system without really polluting the zone system API.
We started with the cover information so that behaviors can query correctly cover spots in the ‘Verse.
At the moment are currently working on the first version of our systemic combat behavior creating basic tactics the AI can select during the combat behaviors.
Spoiler alert!! I can share with you guys a little snippet of the behavior tree where the AI selects a cover spot that has a shooting posture and it then sprints towards the cover location.
Audio
Focused mainly on bugfixes and small features for me this month. One thing the players might notice is the improved pass-by sound effect logic for the space flight. With the new and improved mathematical basis for the game logic, we were able to tighten the ship flyby sound effect timing, which in turn allowed us to make the sound much more detailed and focussed, especially for the really close ones.
Build
DevOps kept refining the build system, making it more stable and bullet proof. In particular a lot of effort has been put in the buildmonkey front end page. Instead of having someone from DevOps deploy servers, QA can now do that on their own just by clicking a button. We’re heading towards the point where there is less involvement from a DevOps Engineer to handle simple everyday tasks.
We’ve been experimenting a lot with docker and how that can help improve our tools’ stability. Our build system (which is on github now) is going to have its own continuous integration system. Even though it’s far from being done, right now whenever there’s a new pull request or commit on the master branch, we get that change and spin up a new build server within a docker container on a completely automated fashion.
We also got visited by Alex P from the ATX studio. Within CIG he’s one of the most knowledgeable individuals for server automation, chef and general live service management. That week’s been very productive in terms of getting deeper knowledge into certain systems.
Engineering – Chris Bolte
Hi Everyone, during the past month my main focus was on upping the quality of our two October releases: CitizenCon and SC 1.3.
During this time I worked on several optimizations, mostly around the ZoneSystem and CPU side object culling. Besides those, my second focus was on improving our thread backend to be more optimal for a PC only game.
CPU Performance has changed a lot over the recent years. In the old times, optimization was straight forward, there was only a single execution unit inside the CPU which did all the computations. In addition, there was an active GHz race, causing your code to automatically run faster by each new released CPU. Nowadays, the GHz of CPUs don’t change much anymore (single core performance still increases, but not on the level as it did before) and CPUs have gone “wide”, by providing more execution units.
This puts more burden on the programmer, as concurrent programming can be very complex. Since games have (by their nature) are very sequential execution; each frame first must update the state of the world, and then send this state to the GPU for rendering, It is hard to parallelize those in a way that actually gets you any performance gain. To do this, one of the most prominent models used for Games is a so called Main Thread. This Main Thread can be assumed to be like a regular game loop from the single core CPU times. The other cores are then used during a frame to help the Main Thread. If for example, we must update the state of 100 particle systems, we can distribute those over all CPU cores, to reduce the latency between beginning to update the state and being done with it. See the attached picture for a simplified example how this distribution helps.
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
To make all of this even more complex, the PC platform has to be more general than consoles. On consoles, the game normally has all the resources exclusively and on a known hardware set. On a PC, the game has to share the resources dynamically with an unknown number of processes running at the same time on an unknown hardware platform.
So to better utilize the PC platform, we switch the thread backend to batch oriented work stealing approach. By using this new model, we can massively reduce the cost to communicate with different threads as we only need to send a signal once per batch, and not once per entry. We also reduced the contention between the worker threads (important to scale to a higher number of CPUs), by utilizing work stealing so that threads communicate with each other instead of over a central queue.
This whole threading change was one of the major improvements for performance for 1.3, which also causes a higher CPU usage (which is good, as we now actually make use of the cores inside your CPU). Currently, nearly all legacy jobs are already ported over to this system, as well as all CPU side culling of the ZoneSystem. In the future this system will be used to parallelize parts of the game code, as well as a few additional things.
Engineering – Physics
On the physics side we encapsulated the physical parameters from the animation hierarchy and moved the entire code and all data structures into the physical hierarchy. We also invested some time into a radical cleanup of the synchronization-code between the animation- and the physics-module and added new debugging features to display the physical state of articulated entities.
On the animation side we helped the fps-team to build a new animation rig which makes full use of existing engine features like animation driven IK, which in turn makes it possible to have “runtime retargeting” and “procedural motion warping” on animated characters. In parallel we added several new debug features to visualize the primarily joints of the rig and to display the inner workings of animation driven IK. There’s a future design gain from getting this to work – more ship cockpits and crew stations could be able to have more of an individual feel and not seem artificially or excessively ‘templated’ on each other.
Engineering – Everyone Else
The rest of the core engine team have been busy on numerous fronts. It’s a bit premature to go into all the details, but rest assured you’ll hear more moving forward both in our monthly updates as well as our weekly ATV segment.
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
To all the reckless drivers on ArcCorp,
We were all quite impress with your driving skills and your unstoppable determination to drive a buggy inside G-Loc Bar. You created enough scrap metal from those damaged buggies to build an Idris. While you were driving around, here’s what the team in Montreal has been working on.
Design
The design team is hard at work with Austin to take the next step for the shopping experience. A new shop is coming up for ArcCorp, while we are working on the stores for upcoming new locations. We are also working on giving you more feature for the character customisation system.
Art
Digging into a massive asteroid, the art team is setting up amazing vistas for the next location you will be able to explore soon. We’ve also finished the final art pass on a very special club. Be kind with every citizen. You don’t know who might be owning one and you want to make sure you are on that VIP guest list. We are only waiting for the engineers to hook it up to an elevator so you can access it … No buggy allowed this time.
Code
This month we completed a lot of the development that was started last month. Most of these features were delivered to the user via the recent Alpha-1.3.0 Release.
We polished and completed our first iteration of the Loadout Selector Usable Item, please try it and give us your feedback! You’ll also see a lot of new features added to the Chat, most notably the possibility to create private conversations as well as filtered conversations. The Transport Elevator Console modifications have also been completed. The list of destinations is now populated directly by the Location Service (Backend). It’s now possible for players to have access to different instances of Area18 and player will be able to choose which one they want to go to based on how many of their contacts are in a specific instance. This information is now displayed in the console.
We’ve also put in a lot of work on features for future Releases. We’ve worked on the Ship Selector Usable Item that will enable players to spawn a selected vehicle on a landing pad. The list of ships available to a player will reflect the list of ships he currently has. We are also working on adding a Party-forming functionality through the Contact List as well as fixing various Scoreboard Issues for Star Marine. We’re also in the process of working on a framework that allows for some UI Elements (i.e. Chat, Contact List) to adapt when a player passes from First Person View to Third Person View.
We’ve also provided some support for the production of Flair Items that will be awarded to certain Backers as part of the Referral program that was launched at CitizenCon 2015.
Last but not least, we’ve continued working on a UI Development Toolset and are currently in the process of having it tested by different team members to catch any Issues before we roll it out to other studios.
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Greetings Citizens,
This was a super busy month for all teams, as we work towards the 2.0 release. On the Moon Collider side, we were mainly providing support and doing some bugfixes for a few interesting issues that cropped up with ships, such as some scripting issues in the tutorial, and some behavior tweaks for encounters on the Crusader map. However, for the most part, ship AI has been quite solid, so we were able to do a lot of cool feature work that won’t be in 2.0, but will appear in the following release.
So, what have we been working on?
We’ve made a couple of nice improvements to spline flying for ships. As you may know, ships mostly fly freely in combat, but we do sometimes have them use splines to achieve results that we can’t otherwise get easily. For example, if we want a ship to fly close to other objects or through small gaps, their obstacle avoidance usually won’t allow it, and so we can markup maps with splines to guide ships through these kinds of areas.
The benefits of splines here can also create a problem though: if we’re not using avoidance on splines, then what happens if an object ends up floating into the path of a spline? Up to now, the AI would just collide with the object. This is great if you’re thinking of playing a game of chicken with an AI on a spline, but it would be nice if the AI could be a bit smarter. Now, AIs have the ability to avoid obstacles on their splines, while still allowing for them to ignore the obstacles that the splines bring them close to (such as the big space station they are flying through). There is also an ability to provide extra markup in places where veering off the spline to avoid an obstacle will make the ship crash, so that it can be smart about when to avoid, and when to just plow through. Now you really might end up in a game of chicken and not know if the AI is going to blink first. Are you feeling lucky?
The other thing we’ve improved with splines is to make them work better when they’re attached to moving objects. Up to now, if you had a spline attached to a moving object, like a rotating space station, it would rotate with the object, but when an AI went to fly that spline, it would actually fly a stationary copy of the spline, fixed at the moment the ship started down it. This has been limiting some of the scenarios in which we can make use of splines. Now, we’ve made it so that if a spline is moving, its position will continue to be updated even as a ship is flying along it, and the ship will do its best to stay on it. If a spline is aggressive enough to be just within the capabilities of the ship flying it, then this might not work and the ship will struggle with the additional movement of the spline, but under most normal usage it works fine, so you should be seeing AI ships maneuvering expertly around large moving structures in the future.
Death spirals are a feature that we mentioned starting on last month and that we continued working on a lot this month. This has turned out to be quite an involved task, and we’ve expanded it to the more general concept of “death flourishes”. The idea is to have a generalized framework to sometimes delay the destruction of an AI ship when it has become fatally damaged, so that we can have it do something interesting, such as perform a death spiral, before it is destroyed. But it also needs to be smart, and not make the ship invulnerable to further damage while doing its death flourish. You don’t want it to fly a death spiral into an asteroid and NOT explode!
As part of this feature, we looked at three different ways of doing death spirals. The first one was to allow designers to place special splines in maps to help make ships fly into structures and explode on death. While we may look into this one further in the future, we realized that in practice, for it to look reasonable, the spline needs to be near enough to the ship that it can start flying on it within a couple of seconds, and that’s going to end up happening very rarely in games. So we might end up using it as a rare option when the situation is just right, but it’s never going to be a common case.
The second option we tried was using maneuver splines to fly death spirals. These are special splines that can be placed in front of a ship at any time and it can then follow. Originally created to prototype allowing AI to fly fancy combat maneuvers, they are an obvious candidate for death spirals. So far they are working fairly well, but we found an interesting problem with them that will require further work to resolve. AI controls ships via simulating the same control inputs as human players, so it can’t cheat by doing things that human players can’t do. But we’ve found that when trying to make a ship fly a really aggressive spiral spline to make it look like it has gone out of control, IFCS will kick in and limit how extreme the control inputs can be. This means that we can make the ships fly moderate spirals, but so far they have been unable to keep up with really cool looking ones. We will need to do more work looking into how we can get better results for this.
Finally, we tried a very simple but surprisingly effective option of just jamming one of the ship’s thrusters on! If you pick the right one, a ship will quickly go into an uncontrollable spin. It works well, though it’s a bit limited in variety, so we will use this along with the spline flying option, and have tunable probabilities for seeing these things happen before a ship is destroyed. Over time, we hope to expand the list of possible death flourishes with other ideas, which could even allow for unique deaths for certain types of enemies. There’s a lot of fun to be had here, and the end result should mean more satisfying kills during dogfights.
The last thing to mention this month is a refactoring we’ve been doing on the ship takeoff and landing system. We’ve been reworking several aspects of it to use Kythera behaviors for control during all but the final vertical descent/ascent to the landing pad. This has allowed us to integrate takeoff and landing splines into landing pads, and ships will automatically choose the best spline for their approach direction. Up to now designers have been needing to manually script a lot of this, which is time consuming. With these changes, landing areas will now be a lot easier to setup and will be more robust. This means designers can build maps faster, which means more content, and that makes us all happy!
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Greetings from Montreal!
Here’s what we’ve been up to in the last month:
October was a very exciting month, with CitizenCon taking place in Manchester this year. To coincide with this event, Turbulent delivered many new updates to the website.
The Referral Program was unveiled at CitizenCon. It allows Citizens to invite their friends to play Star Citizen. The new system not only gives rewards to the new recruits, but also implements unique rewards to be given to backers every time that someone used their referral code to create an account and purchase a game package. The more recruits that you invite, the more rewards that you can access. In the future, we will reveal higher-level rewards.
We were also thrilled to be part of the unveiling of Squadron 42. We added a new landing page on the website to introduce this exciting new single player module to Star Citizen. An amazing cast was announced, but we will have to wait and see where they fit in the Squadron 42 storyline. Stay tuned for future updates on the cast and the game.
CitizenCon also saw the introduction of a new ship, the Aegis Sabre: a lightweight fighter to be used as a “rapid responder”. With its sleek, performance-oriented design, the Sabre was a hot item, rivaling the sales and community excitement of much larger ships.
Finally, Turbulent was proud to unveil the long-anticipated Starmap and we were thrilled about how you the community have embraced it. We are continually collecting your feedback to help us plan future versions of the Starmap, as we work to make it as polished, realistic and comprehensive as possible. Not only did the Starmap catch the imagination of our community, as to what their game universe would look like, but it also caught the eye of the web design industry. The Starmap already has been the nominee and recipient of many awards for web design/development excellence, including being featured on Google’s Chrome Experiments, as well as winning the FWA (Favorite Website Awards) Site of the Day (October 30) and AWWWards Site of the Day (October 30), CSSDA (CSS Design Awards) Website of the Day (October 20).
With CitizenCon done and 2016 on the way, there is no rest for the wicked here at Turbulent as we are currently planning our next projects for Star Citizen and cannot wait to present to you what we will do next!
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
What has happened this past week in Star Citizen Alpha 2.0. development I hear you cry?
Well we’ve still been tweaking, polishing, and refining any remaining pieces of content whilst the rest of team go to battle with the list of Blocker and Critical bugs so this week’s report will read a little more like a QA report! We are battening down the hatches and getting on with some good old fashioned bug smashing!
The 2.0 release stream is in lockdown now and the Star Citizen Team are doing everything in their power to get this build ship-shape for you guys. Each developer has to be extra careful in testing their work and getting it peer reviewed with risk assessment for approval by Production before it’s allowed in to our precious stream. This is welcome news to Production because we’ve encountered some really frustrating bugs recently, that on top of our more persistent issues we could really have done without. Huge new technological systems like Large World, EVA and Multicrew Ships taking a little longer than expected is no big surprise, in fact it’s more or less expected! But what you don’t want (or at least do your best to reduce) is delays on the logistical side of managing the build process.
One issue we had recently was with our exclusion system – Exludibur! – a system that we use to configure what is and is not in any given build (without an exclusion system, we’d be releasing hundreds of gigabytes of un-optimized, partially-completed game elements with each release!) So when some of the environmental geometry had not been listed for inclusion in the QA build from the 2.0 release stream, it was no surprise that when it got tested that it simply wasn’t there in the game! And what makes it worse is that when that happens, the code still tries to call the geometry that isn’t there, gets very upset, and crashes! We still managed to test our main Game Dev stream to progress with our work but it’s things like this that still take time in our Production and we need to focus to get it right.
Another issue we might have been able to avoid was to do with a new Main Menu that we’re making for you. As you may or may not know, we have internal versions of the build called “Profile” that can sometimes produce slightly different test results when compared to a “Release” version of the game. Release is the best for the most authentic testing conditions but we sometimes need the Profile build for some debug options or to get around issues such as a black screen hang that was happing in one of our Release builds earlier in the week. The black screen was due to the introduction of a new main menu screen that wasn’t hooked up in that mode and therefore unable to test. The Profile build however was able to bypass the issue, so we could continue our work and test the rest of the content in the game. Again, it’s just another consideration in the Production that we have to make sure is checked off to get it ready for release.
I’m sure you’re all wanting to hear a little more about the Main Menu now – right? So the call for the Main Menu was a decision made to improve your user experience by helping players get in to the game more quickly with the initial boot up and also when coming back out of any standalone gameplay such as a gamemode in the Arena Commander simulation. We are now allowing the player choose whatever they want to load with this new menu, and avoid having to wait for content that they’re not looking to access. You guys have been speaking up about this on the forums, so we’ve listened and are doing something about it! We hope you approve of it once it’s all implemented in 2.0 and I’m sure you’ll let us know if you don’t! Just please note that it’s a first iteration.
In other UI related news, we have been putting the finishing touches on the ship screens which you will see in one of this week’s update videos which shows you the all new and improved Avenger, Cutlass, and Constellation. These are again a first iteration with lots more work left to do (ie. Adding the wireframe ship to the Avenger) and the “System Unavailable” messages should give you an indication of cool things still to come with this multi-layered system for managing your beloved spaceships.
So that’s just about it for this week’s report. We really hope that we won’t need to write another, or many, of these reports because we are certainly “close” to the 2.0 release, it’s just really, really hard to predict just how close we are. It’s a tough fight in the 2.0 trenches but we have an incredibly talented and dedicated team that no amount of bugs can keep down for too long! So thank you for your patience, we will keep you posted but please know that it IS coming!
Now here are the high level items broken down for you by the team…
Gameplay and Engineering
Looking at a Quantum Travel bug where two ships can come out of travel inside each other
Improved engineering screen FoV for multicrew ships
Continued work to improve the EVA experience
Improving weapon movement for FPS combat
Fixed up an issue where dying in FPS combat left the weapon floating in the air
Performance optimisation
General bug fixing
UI
Added support for notification of REC awards
Lots of bug fixing & polish:
Multicrew ship screens
mobiGlas Mission Manager
mobiGlas Journal
Added respawn countdown
Quantum Travel HUD
Visual skinning of transport elevator console panel
Mission Manager live updating, when you have it open
•* More polish and bug fixing
Art
Final environmental polish and LODs
Final lighting changes to Crusader map
Final VFX polish on Ship damage, Crusader map and EMP
Finalizing LODs for Avenger
Optimisation for Retaliator
Animation
Further refining base character locomotion
Additional work on finalising stocked and pistol locomotion
Audio
Dialogue session has been completed so the mastering of these assets is now progressing
Working on improving the sound design for EVA
Continued improvements for ship fly-bys (see video update for more details)
General bug fixing
Blocking Issues
Probe for Quantum Travel marker isn’t working properly so the player can’t travel to a mission location
Missing space station geometry due to Excludibur (now resolved and verified fixed)
Missing geometry for Arc Corp elevator due to Excludibur
Server crash when spawning Multicrew ships
General server stability issues with 17+ players in-game; but vastly improved from just 2 players when playing two weeks ago!
Black screen hang on boot in Release (now resolved and verified fixed)
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Welcome back to our third weekly update on Star Citizen Alpha 2.0. development!
We’re getting just as excited as you guys are to get this release out so the team are pushing hard every single day to make that happen! The patience and understanding of game development in the Star Citizen Community is often astounding and refreshing to hear so we wanted to let you know that it really drives the team on to hear such words of encouragement. We are really not that far from delivering this huge amount of new content to you all but game development is a complex process that takes time to pull everything together and stabilize it to be ready for a good user experience. We totally understand any frustrations you may have in waiting for such a tantalizing release so we will always do our best to give you visibility on the progress of it, warts and all, so you’re not left in the dark and we’ll keep addressing the main priorities and look to release it the very moment that it’s good and ready!
We’ve described much of the content that’s been implemented already, so you should have a good idea of all the cool new features you’re going to be getting your hands on, we’ve got the ships and environment ready and we are very much in to the polish phase of the release with the addition of things like energy Recharge Stations to various satellites. The vast majority of the gameplay experience is there to play and we’re really locking things down in terms of avoiding any major new additions to the code base in order to stabilize the build and avoid the risk of knock-ons.
Performance improvements are a typical part of any video game release. Despite making things as optimal as possible along the way, there’s always a big push towards the back-end of the development cycle in order to bring everything in to acceptable frame rate levels… and we’re not quite there, yet! If we released it to you now, it really wouldn’t do any of the content justice because it needs to play nice and smoothly and be relatively crash-free. Some crashes are inevitable with introduction of new codebase systems coming online so essentially just bugs that we just need to churn through as fast as we can.
One of the most exciting things about this release is the story element. Arena Commander was our testbed for implementing the ship systems that you see today but with Crusader we will be opening it right up to whole new level of gameplay. For one, the Audio team have implemented some new computer system voices for things like the airlocks and the Comms Array terminals and the vending machines which really brings things to life, and yet we still have even more dialogue to implement that will really hit home those levels of immersion. In this scenario you’re picking up a job on your mobiGlas as a Space Technician and we leave you exploring the beautiful environment, investigating the backstory of events, taking on pirates, working with the UEE security teams and doing things in whichever way you wish! It’s a real sandbox of random scenarios with traders, UEE and pirates quantum jumping around and making you feel a part of something… and yet this is all just be the tip of the iceberg!
In terms of FPS-specific work, the team has put together a mixed armor set for use in 2.0 this week, complete with the light marine armor, RSI helmet, 2 medPens, helmet, EVA jets and an ArcLight laser pistol as the default loadout for all players adventuring on the Crusader map. There will also be P4-AR Ballistic Rifles available for pick-up on Kareah station. This will be the first taste of Star Marine in the 2.0.0 release, with more to come down the line.
Work continues on Star Marine proper as well, although the priority is getting Alpha 2.0 (which jumps ahead and introduces FPS gameplay to the persistent universe) ready for launch. To that end, we’re focusing on Star Marine-related tasks that will impact both planned releases, and we are broadening our weekly update to focus more on the task at hand. Expect to hear more about Star Marine proper after 2.0 is released, but know that much of the FPS work happening right now will apply to both releases.
Let’s get on with the high level breakdown of items from the various teams…
Gameplay and Engineering
Added energy Recharge Stations to various satellites
Added feedback for when a EZ Hab pod is locked to you
Restored rotating rings to Port Olisar
Finalised the Research Satellite method of mission giving
Mark-up for all Asteroids added using the new, more automated method
Moving EVA to an improved physical control model
Implementing ragdoll animation whilst in EVA
Improved ragdoll animation – see WIP video
1st pass implementation of breaking apart of the Retaliator (on destruction)
Will be more visually impressive and realistic
Performance improvements/optimisations
Network optimisations
General bug fixing
* Fixed a bug with health pens not working
Weapons not physicalize properly, they remain floating in space, upon death.\
Fixing bugs on weapon select/deselect/holstering.
Reviewing look poses for Pistol firing with the animation team.
Procedural weapon animation work is still in progress. Work on positioning, weapon sway, weapon cant, will go into next week. Recoil is feeling good.
Ammo boxes are broken, investigating. Energy recharge stations are working! Lasers; pew pew!
UI
Multi Crew screens polish
Mission manager UI polish
Quantum Travel UI polish
Screens for Crusader station
General reticule polish
Multi Crew screens polish
Making a first pass and simplified Main Menu, so players don’t have to load into the Hangar every time they start the game or finish a match.
Base implementation of a reticule for the EVA HUD.
Bug fixing
Art
Constellation flight ready
Retaliator flight ready
Cutlass Black flight ready
Updated to support the new damage tech.
Updated to support multi-crew functionality
Final layout polish for the space station interiors with bug fixing galore, profiling, optimising, testing
Final lighting polish for the space station interiors
Layout and signposting changes to the Cry Astro Fuel facility
Exterior damage effects from minor damage through to 100% damage explosions
Interior damage effects, including cockpits – triggered when receiving damage and “state” switching when ship health is low
General ship damage effects polish
General ship thruster effects polish
Crusader map ambient effects – including:
Airlock pressurisation/depressurisation
Derelict space station ambience
Giant asteroid field ambience
Repair drone effects polish
Ship landing dust effects polish
Quantum Travel effects polish
Missile effects polish
General effects optimisation
Animation
Refining base character locomotion
Finalising stocked and pistol locomotion
* Pistol animation set was reviewed, still needs starts/stop, select/deselect, lowered set-up in mannequin, prone look pose, and crouch look poses. These should be started, and hopefully finished next week.
Rifle animation set reviewed, ADS is currently broken, still needs lowered look pose, better weapon pickup anim, and prone look pose need to be exported and hooked up.
Rifle look poses for fire are fixed, but firing has a problem with the weapon moving in the hands, investigating now.
Audio
Another dialogue recording session for some additional lines and some re-records
Made improvements to the ship flyby sounds
Continued implementation music
Finalising audio for map locations
General bug fixing
Blocking Issues
Frame rate is very sluggish at times
We have a few crashes which are currently blocking the comms array gameplay
Unable to spawn Multicrew ships in release mode
EVA needs to be more responsive and much less buggy! Player can spin out of control and also suffer latency issues – hopefully these are fixed in next build with some recent animation code fixes
Walking on to a ship can cause it to have no flight functionality but works fine if you debug spawn straight in to the cockpit; probably related to a recent IFCS code change
Server Crashes when AI units fire weapons. This blocks other testing, of course.
Pistol ADS animations are blocked until we finalize Stocked (rifle) ADS system.
Character Sprint animations needs a review once the [weapon] lowered pose is finalized. This is a potential blocker.
EVA needs to support personal weapon usage, this will require code support as well as adjustments to the base poses.
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
THE FUTURE OF FLIGHT
Since the initial release of Arena Commander, we’ve increased top speed, scaled down the availability of boost, and reduced the power of maneuvering thrusters. While these have all had drastic effects on the game, none have been a fundamental change in the way the game actually works – which goes to show how much stat balance can affect a system! However, behind the scenes, we have been working on some deeper changes to the flight model, and are nearing a point where some of that work can be put in front of players.
Flight Modes (aka IFCS 2.0)
The flashiest new feature is the additional flight modes: Precision, Space Combat Maneuvers (SCM), and Cruise. These are all IFCS profiles that focus ship behaviors toward the highly different goals of close tolerance adjustments, combat actions, and long distance flight respectively. Though you can only use one flight mode at a time, coupled/decoupled and the collection of flight assists can still be used to further customize handling.
Precision Mode
When you take off you’ll start out in Precision Mode. In Precision Mode, the maximum velocity is significantly reduced and the throttle and acceleration are rescaled to provide improved control when maneuvering in close proximity to other objects. This makes take off and landing much easier, but will also improve control around other objects such as asteroids, derelict craft or when approaching other live craft during In-Flight Refueling or Boarding maneuvers.
SCM Mode
Once you’ve cleared any nearby objects and have come up to speed you’ll want to switch into Space Combat Maneuvering mode. SCM is one of the biggest changes to the flight control system, but on the surface it closely mimics the current flight mechanics that you may already be used to in Arena Commander. The real power of SCM mode is that maximum velocity is a now dynamically calculated as a function of force and mass: F/m * T = SCM Max Velocity – this means anything that any changes to the acceleration of the ship (such as loadout changes, picking up cargo etc) will impact the maximum SCM speed. We’ve incorporated the SCM calculation in such a way that it is your ability to brake to 0 on any turning axis (x or z) that determines the top speed your ship is allowed to fly. This means that upgrading the ships maneuvering thrusters generally results in a higher max velocity being allowed by IFCS. Further, this speed is determined by the strongest turning axis of the ship, meaning the best drift control will be achieved by turning on the strong axis, rather than the weak axis. Each ship has a different configuration of strong and weak axes and its up to the pilot to learn them and fly to their strengths.
Afterburner
There is another exciting benefit to SCM: Afterburner. Where the current boost mechanic gives you better acceleration and drift control, Afterburner gives you more maximum velocity while maintaining the same relative control. Here’s how it works: In SCM mode the top speed is set according to your ability to accelerate to a given velocity in a set time. Since boost raises your acceleration your maximum speed also increases. Boost as it currently works is still sticking around, but now players will have the choice on how to spend their limited boost fuel: on max velocity to rapidly change distance, or better braking to improve handling.
Cruise Mode
For longer distance travel in the same local area Pilots now have the ability to utilize Cruise Mode. If the speed limit defined in SCM gives the pilot control at the expense of velocity, Cruise Mode gives the pilot velocity at the expense of control. And while the top speed is high, the available acceleration doesn’t change, meaning that reaching maximum Cruise velocity will take 15-20+ seconds, turning ability does not scale with velocity and coming to a stop can take much longer using the normal ship retro thrusters.
Since cruise velocities can easily reach 5x or more of the safely controllable velocities allowed by SCM, IFCS enforces controlled turning to ensure pilots do not get into uncontrollable slides. This means that the nose of the ship is locked to the velocity vector and maneuvers in Cruise mode become more about adjusting course than making turns. It goes without saying that Cruise is absolutely not intended to be used in combat, asteroid fields or high-traffic space lanes.
Of course, decoupled mode can always be used to rotate freely at cruise velocity. Savvy pilots will quickly learn to use decoupled mode and boost to brake with their mains as quickly as possible. Conversely, pilots will find that attempting to change course 90 degrees by using decoupled mode is an express ticket to sleepsville since the high sustained g-forces of such a maneuver lead to rapid black or red-out.
Quantum Leap
Beyond those flight modes will be Quantum Travel, the one place where all ships are limited to the same 0.2c max speed. Once the Quantum Drive is active, the ship will quickly ratchet up the velocity to the 0.2c limit – short jumps might never get going that fast – with the ship itself experiencing relatively little acceleration. At these speeds, tiny variations in angle will result in massively different flight paths, so this is where slower ships will have the chance to escape a faster ship accosting them. Of course, traveling at these incredible speeds is quite dangerous, so the ship computer will automatically pull you out of Quantum Travel if the possibility of collision is detected or the ship has any downed shields.
Flight Control Modules and Upgrades
One of the design goals that goes back to the dawn of the project is the concept that the flight control software should be physically represented as an item within the game world. But up until now the IFCS system has been completely behind the scenes and managed through (relatively) static ship definition XML files. Much work has been done over the last few months to prep the IFCS parameter blocks for migration into an avionics module that can be swapped out and upgraded. Each module is used with a specific ship and contains all of the settings and parameters that IFCS needs to know about the craft to make it fly within the established engineering spec. Behind the scenes this makes it vastly easier for designers to tune and balance ships and thruster upgrades and gives us more flexibility in giving unique characteristics to hull variant ships. But the most exciting part is that soon players will be able to upgrade their flight control software right along with their thruster hardware to build a ship that suits their style.
The biggest change to IFCS is the move to a 3rd order motion control system. Prior to this release, IFCS has used a feedback control system for spaceship motion control. The motion profile for this feedback control system (a PI controller) is an exponentially damped sinusoid. The graph in Fig. 1 shows both acceleration and velocity control as the velocity set-point changes from 0 to 100 m/s.
This is an iterative control system that makes no assumptions about the past or future state of a system, and merely acts to smooth out the error between the ship’s current state and its goal state. Because of this, it is well suited to our needs, where damage conditions and unexpected external forces can cause unpredictable motion.
To further complicate matters, because IFCS is limited by the actual thrust available from ship thrusters, the true in-game motion profile is capped. This profile is shown in Fig. 2, with the uncapped profile shown behind it for reference.
The graph in Fig. 2 is a fairly accurate depiction of the current velocity control for spaceships in Star Citizen, both for linear and rotational control. While there are many advantages to this motion profile, there are some significant downsides, including a) difficulty predicting the future state of a ship that is moving under this controller and b) an asymmetrical control response with an extended settling time. In particular, players have frequently noted that the extended settling time makes the ships in Star Citizen feel “sloppy”.
To address these issues, the new release of IFCS will begin using a bi-level control system. The first level, feed-forward control, will calculate the ideal motion of the ship, while the second level, feedback control, will provide error correction to keep the ship as close to the ideal motion as possible, even under damage conditions and unexpected external forces. So the current motion algorithm will still be part of the system, providing the same error tolerance, but it will no longer be the dominant motion profile (except under extreme system error).
The feed-forward control system will use ideal 3rd order motion, as the graph in Fig. 3 shows.
Unlike the feedback algorithm, this motion profile is completely predictable. At any moment, it is known how long it will take a ship to reach a new velocity or position from any set of initial conditions. Also, the acceleration ramp-up phase can be tuned so that ships have a natural, smooth motion, without the excessive settling behavior of the current control system.
In practice, this will result in a wide range of ship flight behaviors from highly responsive and jerky, like a high performance sports car, to less responsive but smooth control, like a luxury car.
The rate of change of acceleration is called “jerk,” and it is essentially the acceleration of your acceleration. An easy way to understand jerk is to think about how you drive a car. When decelerating your car to a stop if you apply constant and even pressure to the brake pedal your car will decelerate at a linear rate. But if you apply this same pressure to the pedal all the way to a stop the transition to 0 velocity is not smooth and feels abrupt. But if you progressively apply less pressure to the brake as you approach 0 velocity (or ‘feather’ the brake) you change the rate of the deceleration and the stop is much smoother and more comfortable. Feathering the brake is a low-jerk action, while suddenly depressing it is a high jerk action.
For reference, the graph in Fig. 4 shows the typical 2nd order motion (constant acceleration, linear velocity) used in many games.
While 2nd order motion is a much simpler control model, it provides a very stiff, mechanical ship movement. The 3rd order system will allow us to tune ships to be as stiff or as smooth as we need.
Balancing
Ship flight balancing is one of the most difficult and delicate tasks that we have on this project. The move to a 3rd order system and the addition of a dynamically determined velocity mode have necessitated a nearly complete from-the-ground-up re-balance of the ship handling characteristics. This means that each of the ships are likely going to feel quite different from what you’re used to in Arena Commander. Great care has been taken to ensure that each ship retains its own place relative to the other ships in the universe. We’re aware that any change of this magnitude will likely kick off lively and passionate debate about the old vs the new, but we’re confident that the changes will allow us to make the ships feel more real, and allow them to have more unique personality than has been previously possible and allow more precise control.
The switch to jerk also means that erratic actions for evasive maneuvers are nerfed naturally, since the system is now slightly slower to make contrary actions – dedicated inputs, like the kind used when attempting to pull out of a slide, are largely unaffected. Third order motion is also much more natural for the human brain to internalize, so control will be more intuitive, and overshoot will be less frequent.
With jerk available as a parameter, a new ‘stabilized flight’ behavior becomes available. Essentially. this means that by setting a low jerk value, an engine can be tuned to perform at a greater Load Rating relative to its size, allowing us to create ships – like the Hull or Aurora – capable of hauling plenty of cargo without also becoming the fastest ships in the universe when unladen. And, while all ships will be faster without cargo than they are fully loaded, we can set different ships to have different levels of performance loss when they take on cargo.
The first pass we release to the PTU is simply that: a first pass. It is intended to set the general tone of the direction for each ship, not the final destination. As always we will continue to playtest and tune, and will be watching your feedback to see where we may need to address rough edges or unintended consequences.
There are a few more neat little consequences of this change, but for now, let’s talk about thrust shunting.
Good Will Shunting
Thrust shunting is the process by which thrust is generated in the main engine and then pushed through the pipe system to the various nozzles (or ‘mavs’ as the community has dubbed them) where that force will actually be used. This means that the main engines will become far more important than we’ve seen so far in Arena Commander, and down the line, will mean we can have full engine rooms on our capital ships. Instead of having engines plastered all over the ship we now just have actuated nozzles, so if the main engine gets damaged then all the maneuvering thrusters go with it. When this happens, ships have internal gyros that can be used for emergency or ultra-low power maneuvers, but they are very weak and slow. The fantastic thing is how this opens up new opportunities for damaging ship flight behaviors.
A damaged thruster pipe would scale down the available thrust at the nozzle, and could even introduce unintended thrust at the point of damage.
The nozzles themselves have ratings for heat and power, limiting the total thrust available – a limit you may be able to exceed, though you do so at your own risk. The result is an equilibrium of flight behaviors that are enforced by the design of the ship and the state of the components, behaviors that a skilled pilot will be able to push to the absolute limit to ride the line between victory and catastrophe.
There are many ways that the actual state of a ship can deviate from the ideal state as requested by IFCS. Up to this point we’ve allowed the control system to have perfect control under ideal conditions, and this results in overly mechanical and often “dead” looking motion. With the new release, that will no longer be the case. There will always be some level of thruster and system error overlaid on flight control. This will manifest as minor turbulence in motion under optimal operational conditions, but will become more extreme because of thruster damage, overheating and various other factors.
The graph in Fig. 5 shows a sample ideal 3rd order velocity profile. IFCS would request thrust from the thruster system to achieve this motion.
However, because of thruster error, which can include a number of sources such as incorrect vector or thrust level, unstable vector or thrust level, etc., the actual motion of the ship can deviate from the ideal motion. The following graph shows an extreme example of random thruster error causing the velocity of the ship to deviate from the ideal velocity over the transition from 0 to 100 m/s. Because of errors in actual applied accelerations (all actions for a ship are ultimately applied as accelerations, never directly as positional or velocity corrections) over time, the final velocity achieved during a change in ship velocity can be significantly different from the intended velocity. IFCS requested the above velocity change and it got the one shown in Fig. 6.
This is where the original feedback system comes into play. It looks at the actual state of the ship compared to the intended state and generates additional corrective accelerations to keep the motion as close to the ideal as possible.
The example shown here in Fig. 7 is for velocity error and feedback correction, but a more obvious example in-game will be attitude control. IFCS has a reaction control system (RCS) that maintains the ship’s attitude as set by the pilot (the control frame). Because of thruster error, as well as other external factors, the actual attitude of the ship can deviate from the ideal attitude. The RCS uses the feedback control system to generate thrust and maintain the ship’s attitude at its intended state. In practice, thruster turbulence from imperfect thruster performance will generate a small amount of play in the nose of the ship, especially when firing thrusters at full capacity and when first settling in to a motionless state. But again, the goal is for this error level to be subtle except under extreme damage conditions. This is about the aesthetics of motion more than it is about flight behavior.
Ready to Fight
Ultimately, the experience of Star Citizen is the combination of all of its systems, so to really explain flight, we also need to talk about combat.
The goal of combat in Star Citizen is to provide frenetic, fast paced action while rewarding thoughtful tactics and planning. This means different things at different scales of ship – from the intense furballs of the single-seater dogfighters, to WWII style turning battles to bring full guns to bear in multi-crew, to outright wars of attrition and spacing on those giant capital ships – they each offer their own unique flavor of combat. However, the philosophy for all of them is largely the same: combat is most fun when juggling different levels of risk, reward, and commitment.
For most ships, the lowest common denominator of any input is rotation. Crew safety limits the really big ships from pulling aggressive flips, but for the smaller crafts, turning is much easier. Offensively, this empowers aim (again, with diminishing returns by scale), but defensively, skilled pilots will try to take unavoidable impacts where their shields and armor are strongest. Rotation inputs will also improve with the addition of an input stabilization mode, which clamps rotations to the lowest maximum rate available, removing a large amount of scalar error in the control frame. The ship properties remain unchanged by this, so maneuvers still realistically favor a particular axis according to their design, but the input itself is more predictable and intuitive.
Ships are generally built to favor main engines, although the strength ratios of this are very much a part of the personality of each vessel. This means drift, as we’ve seen already in recent patches, and that flight maneuvers require a bit of thinking ahead, even with use of boost. This again makes shooting easier, but taking damage is a big part of the experience of Star Citizen and is something we support at every level. The choice to include multiple components of each type allows for more meaningful capability degradation and for ships to remain operational at much greater levels of damage. After the fight, your hull will be scarred with reminders of your most recent adventure. Or, if things are looking dire, you’ll be able to repair ships in the field and triage incoming damage. It’ll probably be a good idea to take care of those failing coolant lines before they lead to an unchecked engine breach and a full power plant meltdown that blows up your ship (looking at you Connie).
With the ability to take more damage comes longer levels of commitment which also means increased management of things like fuel, heat, and g-forces. The more shortcuts that get taken, the more backed into a corner you will become. Captains will have to weigh the longer term risk of the short term reward if they want to emerge the victor.
Balance
Of course, all of these things ultimately rely on balance to support the systems, and balance is a long and deeply involved process. It’ll take some time to get this balance right, but the goal is to play into the strengths at each scale, and the gameplay opportunities that these afford. In the smallest ships, maneuverability is king, so the upper hand is earned by forcing your opponent to take more risks, overplay their hand, and become vulnerable to a killing blow. Rotation is easy in space, so you can be sure that any small ship you shoot at will be shooting back soon after. One of the reasons for this is simple physics, as the ships become more massive the thrust required to offer quick rotations scales drastically, and for reasons of control feedback and responsive handling, our ship’s rotations have smaller windows for error than translation does. Multi-crew ships can also afford larger periods of vulnerability, as the upcoming repair mechanics, shield manipulation, and pipe routing offers a ship under fire plenty of ways to improve the situation and swing the tide of battle.
As these ships get larger and larger, the gameplay pushes further into demanding tactical forethought, with positioning and the management of ship resources becoming increasing concerns during a fight. A key goal of this kind of combat is to keep success and failure from ever becoming too binary, or to allow the battle to be determined by ever-fewer, ever-smaller mistakes. At a fundamental level, Star Citizen is a game in which ship-to-ship combat should remain fun and fair even when a cargo ship’s ambushed by pirates, a capital ship’s taking on single-seaters, and the loss of property and life comes at a high price. You won’t always win, and when you do suffer a loss, we want it to feel like it mostly came down to a matter of skill. We want this to be skill based, but we also want to have a sense of progression in the PU. A Hornet F7C should be objectively a better ship than a Mustang Alpha, but the power differences should not be so extreme that the Mustang pilot will never beat a Hornet – it will just be a more challenging fight.
Star Citizen is a game about choices, so every time you leave the hangar you’ll have to decide which ship to fly, what equipment to install, who to have on as crew, what routes to take, even where and when to store cargo. Each ship has its personality, each weapon has its trade off – each path has its dangers. The goal is not to make all things to all people, but to create an ecosystem in which players can find the exact right mix for them. Some will prefer to monoboat, and in the narrow window of their specialty they will find success; others will prefer self-reliance, and will find a varied loadout to suit the varied obstacles that await. These choices affect everything, from the power draw to the heat burden, all the way down to how fast the ship flies, how much it drifts.
There’s no perfect ship – only the perfect ship for you.
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Two Jims
To tell the story of InterDimension Software is to tell the story of the ‘two Jims,’ level builder James Romanov and tech designer James Vandyke. They may have begun their game development careers in disparate ways, but once introduced, they became (and continue to be) an apparently unstoppable force for developing a string of massively successful releases, from the kid-friendly Admiral Cool to the highly realistic Star Marine.
Shy, quiet and difficult to approach, James Vandyke very much fits the classic stereotype of the spectrum game developer. Underneath his cold exterior, however, lies unquestionable brilliance: from his early childhood itwas apparent that he had a natural empathy with machines, and a level of understanding that allowed him to make them sing. Vandyke naturally gravitated towards game development not only because he was as a player himself, but because the game industry tended to push hardware and logical systems to their extremes. Fueled by a genuine desire to further technology on all levels, Vandyke skipped a formal education in favor of a job offer to develop his own game technologies through indie-publisher Perigree Press.
Oakhurst & Perigree
Seemingly Vandyke’s polar opposite, Romanov was an outgoing young game designer brimming with such confidence that he quickly inspired a cadre of fans eager to follow his career personally. He was inspired to begin building his own games at a young age, designing his own stylized versions of popular titles for release on the Spectrum. At age twenty, with a host of simple mobiGlas games under his belt, he took his first formal job at the industry powerhouse Oakhurst Online. His first project was an aborted port of 3400 AD, followed by six months making dungeons, quests and monsters for Henry Garrity’s ULTIMATE III. Unfortunately, he was clashing with his bosses over creative direction to such a degree that, shortly before the release of ULTIMATE III, when Perigree approached him with an offer to be their Lead Designer, he quickly accepted.
And with that, lightning struck. Vandyke and Romanov, the cardinal introvert and the shameless self-promoter, struck up an unlikely friendship that lead directly to their first co-authored game, Admiral Cool versus the Karate Dogs from Mars, released by Perigree under a ‘try before you buy’ license, that helped make the pair household names. Bright, colorful and fun, Admiral Cool’s kid-friendly outlook belied outstanding technical achievements under the hood. As he has done with all projects since, Vandyke viewed the project as a technical challenge: how could he recreate the experience found in arcade machines and dedicated gaming rigs on the common mobiGlas? Turning to an encyclopedic knowledge of assembly language and machine logic, he created a stunning interface unlike anything else available for wearable systems at the time.
Two additional Admiral Cool games followed, including a final title, Admiral Cool in Vegetable Panic, created solely to fulfill a publishing contract. Romanov built the levels foreach game, turning colorful blocks, cartoon dogs, hamburgers, Opi-Ola bottles and glittering candies into an immersive, fast-paced world.
Upon seeing a demo of Original’s ULTIMATE spinoff series, ULTIMATE: Downbelow, Vandyke sought an even greater technical challenge for their next project: replicate and then surpass the total immersion interface being developed by high-end publishers, but in a faster-paced, action-oriented world that better suited the design aesthetics of Romanov and his growing team. This time around, Romanov opted to forgo the kid-friendly graphics that defined Admiral Cool, and instead turned to the gritty details of history: an action title based on the internecine warfare of the Messer era. The result was named Tiger3D, and the response was immediate. Players everywhere hailed the impossibly realistic environments, the sheer speed of movement allowed by the engine … and countless others focused on what they saw as a tasteless appropriation of history. While the gaming industry is no stranger to unwarranted protests, there’s some truth to the claim that the team at Perigree intentionally hit a nerve. From levels covered in totalitarian banners to the final episode in which the player must battle a titan-suited parody of Ivar Messer, the game’s design seemed intended to offend more delicate sensibilities.
InterDimension
Despite the outrage, Tiger 3D was a hit and catapulted the pair to the next level. In 2941, Romanov and Vandyke quietly exited Perigree and set up their own shop, founded on the idea of building out innovative technology and flavoring it with great game design. InterDimension Software sought to be a different kind of game creator, with a small-scale ethos that appealed to hardcore players around the Empire. Their first title, announced well in advance via Romanov’s over-stuffed personal Comm-Link updates, was Star Marine. Building on the technology premiered in Tiger 3D, Star Marine was intended as the most ultra-realistic ground combat simulator ever attempted. Building around carefully constructed maps of a Gold Horizon station, Star Marine was crafted from Day One to immerse the player in the very heart of an epic life-or-death struggle.
After a series of unexpected and much publicized delays, Star Marine premiered recently to great acclaim. Based in the present-day and featuring incredibly realistic design, Star Marine has become the “it game” of the year, with the response ranging from the creation of massive communities of competitive players and other fanatics to headlines about companies bemoaning the productivity lost to employees playing it on extended lunch breaks. It seems that nearly everyone in the universe has become a Star Marine. Asked at their launch event why they thought their latest title would be successful, Romanov, speaking for the pair, responded simply, “because it’s pretty damn fun.”
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Greetings Citizens!
This last week has flown by! We’re pleased to present the second weekly update of what went down with both Star Citizen 2.0 and Star Marine.
The coolest news? SHIPS CAN NOW SPLIT IN TWO (or more!) Yes, the Tech Design and Code team have been working hard and getting this very exciting feature working in the engine and they’ve finally cracked it… so you will now be able to break ships up in to large chunks once you’ve dealt out some catastrophic damage! You can really go to town on your worst enemies and deliver irreparable damage to their ships, for instance, breaking up the Constellation in to four whole chunks. The system still needs more love to get it ready for release but in terms of the technical functionality we’ve definitely broken the back of it (excuse the pun!)
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Everyone has been polishing and bug fixing like crazy and we still have some content dropping in from various the departments including more fantastic sounding audio. Our dialogue specialist has been down at Pinewood Studios (of James Bond—and Privateer 2: The Darkening—fame) and SIDE UK to record more of the datalog audio pieces which are turning out to be a very fun piece of exploration gameplay in this release.
We’re still having a good tussle with the EVA system to get that feeling good and ready but at least we are getting more joy from the ship systems in the AI behaviours. These AI will account for those new encounters and scenarios that the player will now be faced with in Crusader. For example, the map construction is balanced so that if player strays too far from the security of the UEE zones they that might find that they run in to trouble, or they might just get lucky – who knows!? The beauty of it is that it’s all systemic-based gameplay where each encounter has its own unique potential.
What about the Star Marine-related portion of the release? With boots on the ground we’re seeing some noticeable improvements in the FPS reload animations, ADS and Stop-Start so we’re very pleased to that is all really taking shape, and not only are the characters feeling better, but the environments are too. The Environment team have been slogging away at various space stations in their final art stages, and the Covalex Shipping Hub has just had a full lighting pass so we’re sure it will really blow people away!
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Crusader as whole is feeling much more alive now with further iterations to the repair bots and the implementation of the background traffic simulation systems – this helps give a real buzz to the map with traders and UEE patrols zipping about all over the place! This is another of those first Star Citizen steps with this release, as the Universe starts to come alive piece-by-piece by building the systems that will organically produce the economies and communities for you to play in.
Lastly, there’s some vast improvements coming in with the in-ship UI screen revamp in order to factor in all of the new Multicrew gameplay. The UI the team are really excited with how it’s all coming together, and any of you techie-types will love getting your hands on the first implementation of the new engineering screen that allows greater control over your ships power and shield systems. In addition, the new screen focus functionality will allow you to quickly and easily turn your attention to individual screens situated around your station. These UI screens needed much careful consideration because they will be what underpins this core system feature for years to come, and will allow us to build up more and more functionality as the bigger and BIGGER ships come online!
Here’s a high level breakdown of action from the different departments…
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Gameplay and Engineering
Ships will more accurately arrive to the end of AI splines
Better handling of dynamic avoidance for ships that are following AI splines
Improve escape behaviours when a ship’s hull gets heavily damaged
Improvements for the missile usage of the ships
Ships will be more accurate on avoiding obstacles
Changed the relationship between character arms and the camera which improves ADS and shooting from hip
Fixed up problems with the player jumping
Cleaning up the pistol motion sets to be brought in line with the rifle
Improved the handling of rag-dolling
Quantum fuel now supported over a network game
Added a collision test before the start of quantum travel – informs you of objects between you and the intended destination
Support for discoverable quantum travel nav beacons
Improvements/polish to the repair drone functionality
Network optimisations
UI
Tweaks to Quantum Travel HUD
Circles around points of interest
Added Quantum Fuel consumption amount
Added “Out of range” message if you are trying to make a jump that you don’t have enough fuel for
Added Quantum Travel HUDs to most of the ships now
First Iteration of the Mission Manager has been submitted
5 Screens for the Crusader map
Basic implementation of the Engineering screens with Power, Shields, Overview, Minimised tabs submitted. (Requires testing)
Engineering Screen polish
Ship spawning implementation
Mission manager improvements
Listing completed missions
Art
Further iterations on the Cutlass, Retaliator and Constellation final steps of the pipeline.
Final improvements to the environment art and FX.
Animation
More iterations on environmental interactions, EVA, FPS movement and gunplay, Death and Hit Reactions, and “Fall and Play”.
Audio
Dialogue recording session for some additional lines and some re-records
Began work on improvements to the ship audio
Implementation of more music to improve the feel of the areas and ‘sell the scene’
Working on duress parameters to be applied to your ship under certain conditions
Audio design to go alongside this as well
Tweaking audio on FPS weapons and gadgets
Expanding the variety of footsteps heard on surfaces
Ongoing work to improve the atmospheric qualities of space stations
Blockers
Characters are missing interior sections of their helmets.
Ballistic weapons can cause a crash and we have various other stability issues to fix up.
The “Push and Pull” system seems to be conflicting with another control system because it’s currently catapulting the player in to deep spaaaaaaaaace!
Particles seem to stop rendering in some gravitational areas, but not all! Needs further investigation!
Looking Forward
Whew, what a week! As you can see, we’re making a great deal of progress on what promises to be Star Citizen’s most exciting release to date. With today’s live release of Star Citizen Alpha 1.3, the PTU release of Alpha 2.0 is now our next goal! We can’t wait to let you explore (and if we’re honest, break!) the Mini PTU. The entire team is working as hard as possible to get it ready for backer testing.
Please note that while our major focus this week was 2.0, next week’s update will include more details on Star Marine.
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Greetings Citizens,
Star Citizen Alpha 1.3 is now available on the live server! Alpha 1.3 represents our first ‘post merge’ patch, which means that a great deal of work has happened ‘under the hood’ combining several different development streams. The merge process conducted these past weeks has prepared the game for the next major update: the upcoming Alpha 2.0 “Mini Persistent Universe.” In addition to technical work, today’s patch includes updates to the flight model, a selection of new, larger guns for Voyager Direct and a variety of other changes. The patch is currently accessible via the Star Citizen Launcher and a complete list of release notes (including balance modifications, known issues and other changes) are available here.
This patch includes a large expansion to the ArcCorp’s Area 18. It adds the under-construction Galleria area, an overhaul of the social interface, new emotes and the addition of Greycat buggies around the zone that can be driven and crashed. We have also introduced some balance changes to both ship health and weapon damage, as well as a number of bug fixes. Finally, today’s patch also includes a significant update to the social module’s chat system. Want to learn how to socialize in the ‘Verse? We’ve put together a Chat FAQ available here for those interested.
We would also like to take a moment to thank the many backers who worked tirelessly to help the team locate and eliminate blockers on the PTU. The ability to issue more rapid PTU updates have been a goal for the project, and we’re happy to have been able to have launched six iterative test universe patches to get to this point! Thank you to our elite vanguard of volunteer testers who have made today’s release possible.
Star Citizen Alpha 1.3 adds a larger Size 4 Behring Combine Ballistic Cannon intended for use with the upcoming flyable Retaliator. Since the multicrew bomber is not available today and we know pilots would love some new toys to work towards, we’re making them available in the Voyager Direct site today along with a pair of specialized mounts that will let you attach them to either the Cutlass Black or the Hornet series of spacecraft. All three items are now available for rental with REC or purchase with UEC. A second gun, a size 2 Strife Mass Driver, is also available!
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
ADVOCACY ARCHIVE INTRA-AGENCY MESSAGES
2945-10-19_06:41 SET
TO: SC Eva Reimold
CC: ASC Jerome Janis FROM: SAC Eleanor Lemieux
RE: GLAIVE ATTACK
SC Reimold —
Last night an incident occurred near Cestulus that requires your attention. An official report is in the works, but I wanted to loop you in immediately.
Yesterday at 22:49 SET Jeff Klesko frantically commed local authorities in Jata about an impending Vanduul attack. Needless to say, they were skeptical as they’ve been continuously receiving false reports of Vanduul ever since the attack in Vega. So, while local authorities investigated the claim, they instructed Klesko to send specific coordinates, keep his distance from any enemies and, most importantly, to not engage. Unfortunately, he failed to follow that last directive.
Turns out that the “Vanduul attack” reported by Klesko consisted of a single Glaive-class ship. Not only that, it was one of those limited Human reproductions done by Esperia. This one was registered to Victor King, a Citizen from Ferron. By the time authorities had confirmed King’s reg-tags and had given it clearance to land, it was too late. Klesko engaged the Glaive just before it entered atmo above Jata and destroyed it.
After the incident, Klesko commed authorities to tell them the situation was resolved and even inquired about his reward for killing a Vanduul in UEE space. The local authorities told Klesko to land, so they could discuss the details. Only after they got him on the ground and into the office did they reveal what really happened. Reports are that he did not take the news well.
I just finished interviewing Klesko and got very little out of him. He’s young and in shock over the entire thing. Kid came here thinking he was a hero only to find out otherwise. I’d wager it’s the first time he used his ship’s weapons outside of Arena Commander.
We’re operating under the assumption that Victor King was piloting the ship, but are still working to recover the body. I have contacted the office in Ferron for help tracking down his family.
Considering the sensitive nature of the situation, I wanted to consult you on how to proceed regarding potential charges. Don’t want to go too hard or too soft at the kid, so I’d appreciate your guidance. There’s a chance for public backlash at either turn.
Eleanor Lemieux Special Agent-in-Charge Advocacy – Davien System
2945-10-19_15:19 SET
TO: SAC Eleanor Lemieux
CC: ASC Jerome Janis FROM: SC Eva Reimold
RE: GLAIVE ATTACK
Eleanor,
Keep Klesko detained without charges until we have more details. See if he’ll authorize you to access his comm log so we can determine if he received the message to not engage. If he refuses then prepare a warrant.
I’ll make sure one of our agents in Ferron visits the King family ASAP, so we can confirm who was piloting the ship.
Let’s keep the circle tight on this for the time being. Only essential personnel until we figure out how we want to handle this.
Eva Reimold Section Chief – Davien System Office of the Advocacy – Earth
2945-10-19_15:47 SET
TO: Asst Dir David Golovkin FROM: SC Eva Reimold
RE: GLAIVE ATTACK
Hi David —
Last night an unfortunate incident occurred in Davien. A young, overly-patriotic pilot (Jeff Klesko) shot down a Human reproduction of a Glaive-class ship after mistaking it for an actual Vanduul. Luckily, my SAC was conscious of how this story might play in the public and has held off on filing charges until we’ve had a chance to think it through.
The Glaive was registered to a Victor King from Asura, but we still need to confirm who was piloting the ship. Do you have a trusted team member in Ferron who could pay a visit to the family?
I don’t want this to turn into a PR nightmare for us so I’ve attached all the relevant information. Please give it a read and pass along your general impressions. We can only hold Klesko so long before we have to bring charges.
Thanks. Eva Reimold Section Chief – Davien System Office of the Advocacy – Earth
2945-10-19_18:37 SET
TO: SC Eva Reimold FROM: Asst Dir David Golovkin
RE: GLAIVE ATTACK
Eva –
The King family has been notified of the incident. Victor King, the legal owner of the ship, was at their residence in Asura and not piloting the ship when it was shot down. According to the family, their son Jasper King (PersonalFile# OH8_31877_416) took the Glaive on a business trip to Jata. The family has no shortage of ships registered to them, but that one was his favorite. Attempts to persuade him to take another spacecraft were obviously unsuccessful.
My agents kept details to a minimum but the family requested constant updates about our investigation. Please keep me informed on further developments so we can relay them to the family. My review of their file revealed that they’re old mining money that has long been involved in politics. Problems could arise if they feel stonewalled. It might even drive them to make noise in the press. The information is going to get to them no matter what, so it’s better they hear it from us.
Regards, David Golovkin Assistant Director – Office of Public Affairs Office of the Advocacy – Earth
2945-10-19_20:05 SET
TO: Asst Dir David Golovkin FROM: SC Eva Reimold
RE: GLAIVE ATTACK
David -
Unfortunately, there’s little doubt as to what occurred. Now it’s just a matter of how to handle it.
Just for sake of argument, let’s say we decide to soft-pedal charges on Klesko. Maybe manslaughter to ensure there’s no chance he’ll serve time on QuarterDeck. The kid obviously made a horrible mistake, but given the circumstances it’s easy to see why he acted the way he did.
If we go that route, do you think the family might use their connections to put up a fight?
Eva Reimold Section Chief – Davien System Office of the Advocacy – Earth
2945-10-19_22:17 SET
TO: SC Eva Reimold FROM: Asst Dir David Golovkin
RE: GLAIVE ATTACK
Eva –
Wish I could say, but it’s hard to predict how a family will react to such a tragic event.
In my opinion, what Jasper did was dumb and insensitive, but not illegal. Short of the Imperator himself passing a decree to temporarily ground all Human-compatible Glaives, people have the right to fly them anywhere in the Empire. It’s something I personally find distasteful, but it’s still worthy of our protection.
As much as I understand why Klesko did what he did, I worry about the message we’d be sending to trigger-happy Citizens and civilians if he got off too easy. Shoot first and ask questions later is not a good position for us. Treating this case as such might be easier in the short term but could cause more problems down the road.
My personal thoughts aside, I will fully support whatever position you take on the matter.
David Golovkin Assistant Director – Office of Public Affairs Office of the Advocacy – Earth
2945-10-20_01:49 SET
To: Asst Dir David Golovkin FROM: SC Eva Reimold
RE: GLAIVE ATTACK
David -
As always, I appreciate your candor on the issue. I’d prefer if we could avoid having this unfortunate incident completely destroy a second young life. Time spent on QuarterDeck won’t make things better for either Klesko or for Jasper King’s memory.
With that in mind, I will instruct my SAC to file manslaughter charges against Klesko. If my decision comes back to haunt us, I’m prepared to take the full brunt of the blame. Just another one of the many perks of being SC.
Will give you the heads up before we officially file the charges. That way your agents can be the ones to relay the information to the King family and monitor their reactions.
Eva Reimold Section Chief – Davien System Office of the Advocacy – Earth
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Welcome to the first Star Citizen Alpha 2.0.0 Status update! We want you to know that we haven’t taken our foot off the pedal, and so we are expanding the weekly Star Marine update to include what the team is doing to prepare for the Alpha 2.0.0 launch.
It feels like June 2014 again when the whole company pushed together to get the very first “Arena Commander – Dogfighting Module v0.8” release out to the fans. Every department has been working flat out to get all of the exciting new content and gameplay in there, whilst making our systems robust enough to build a whole universe upon!
It’s a really exciting time for the project and as always we have been pushing the fidelity, improving the performance, fixing up bugs and iterating on new and existing gameplay features around the clock to make this a really enjoyable and solid release… and what we think will be our best yet!
As you will have seen from our CitizenCon demo, the Planet Crusader map is huge! We placed several new points of interest for you to explore around in your ship and on foot, introducing several basic missions and AI encounters for you to experience a variety of encounters in this beautiful star system. All of these encounters will have a random element to keep you guessing and should give players a taste of what Star Citizen is becoming with unique experiences every time you play, and layers of immersion such as one mission that asks the player to seek out Audio Datalogs from the space stations. It’s moments like this that will help build a story behind the environment and add a rich social history to our Universe.
Brace yourselves for some brand new gameplay elements! We’ve now got our basic implementation of the refuel, repair and restock systems in-game so pay attention to your Quantum Fuel Tank reserves and choose your Jump Points wisely to make sure you don’t get stranded out there! Then when you’re not busy hurtling around at 0.2c, or fighting pirates in asteroid fields, you can also experience the first taste of “rules and regulations” in the Universe with the introduction of our first “Green Zone” that enforces a non-combat area on all players. This is an important step towards building the bigger picture.
As I’m sure you’re all aware, the FPS team are working hard at getting the basic movement and gunplay feeling good so that we have a solid foundation to build on from, just like we did with our IFCS system for ships. The new additions of IFCS systems have been in test for the past few days so we’re balancing all of that out with Design and QA. Super Cruise, SCM (Space Combat Manoeuvring) and Precision Mode will soon be ready for you to hone your space flight skills even further; and we’ve even given EVA the “IFCS makeover” to harness all the hard work that went in to that system which will give us a much more natural and precise version of EVA manoeuvring.
Meanwhile, work on Star Marine proper continues. Some of the deeper features are taking a back seat this week we roll out the basic movement and gunplay that will be available to all players on the Crusader map. This allows us to focus our attention on making the time players are outside their ships a good experience. What’s not included in Star Citizen Alpha 2.0? Game systems such as the score screen and Star Marine lobby UI, as well as some gameplay engineering and design work that is needed for Headquarters game mode. Have no fear, though, for Star Marine will return and your appetite for first person combat will be whetted by the action on Bravo station in the Crusader map. We will continue developing features and gameplay modes that are ultimately for use within Star Citizen, and we will continue to use Arena Commander and the Star Marine modes as a test bed for them. For now, and into the future, the FPS experience will be an integral part of Star Citizen Alpha, and we can’t be more happy about that!
We hope you like the sound of what is to come in this huge release for Star Citizen and the team will keep you posted every week of how it’s all coming along. Thanks for your amazing support as ever, we’re confident that this will be a release for everyone to remember!
Here’s a high level breakdown of action from the different departments…
Gameplay and Engineering
Added extra missions in to the Asteroid Fields.
Added Research Stations as well as Storage Stations.
Green Zone system now works to prevent combat fire around the main base.
EVA and animation system improvements including “Fall and Play” to make death and hit reactions look super realistic.
Added Quantum Fuel Tank functionality so now the player’s fuel reserves deplete and the player will need to refuel at the stations.
Improvements to procedural FPS camera sway.
Improved AI to avoid obstacles in space.
Repair respawns turrets.
Zero-G out of airlocks.
Added a toggle for identification signal; meaning the ship emissions that make you appear on radar can be switched on and off.
Journal improvements.
Added notifications for player entering a Green Zone.
Improved network syncing for crew members of a multicrew ship when entering/exiting Quantum Travel.
Smoothed out the exit sequence from Quantum Travel.
Optimised the radar for landing areas.
Ship selector now takes ship size into account when assigning it to a landing pad.
Vehicle destruction and how we handle the interior physics upon destruction is in progress.
Putting P-capped animations onto the FPS character rig.
Discussion about character loadouts in regard to weapons and armour for the Crusader map.
UI
mobiGlas mission manager initial implementation has been completed.
Quantum Travel HUD additions.
Quantum fuel gauges.
Quantum travel point of interest marker improvements.
New airlock screens are now being implemented.
Branding for vending machines are also being implemented.
16:9 Engineering Screens art and implementation.
A new reticule for repair landing pads has been implemented.
Art
Repair drone VFX improvements.
Constellation, Cutlass and Retaliator final art, set up and balance.
Crusader map environment final art and optimizations.
Animation
Iterations and new assets for EVA, Death and Hit Reactions, and Fall and Play.
The full no weapon animation set is being finalized, work will continue into next week.
Lots of FPS basic movement and gunplay iterations and tweaks
Gun sway, weapon canting, and recoil procedural animations were tweaked by a strike team of animators, engineers, and designers this week, and we’re on track to finish this next week.
Fixed up pistol reload animation.
Continued work with IK look poses and aim poses
Submitted ragdoll improvements for testing.
Ship, prop and environmental interactions for the player.
Audio
Reviewed audio from the CitizenCon demo and identified areas to improve.
Began work on dialogue editing.
Working to improve ship audio as a whole by changing our in-house process.
Implementation of more music to improve the immersion and emotion in the map.
Investigations on how to best improve the breathing manager for ships and FPS combat for the sounds and the code behind it.
Tweaking audio on FPS weapons and gadgets, with a focus on pistol and ballistic assault rifle audio, and the medpen.
Tweaking to laser recharge ammo audio.
Expanding the variety of footsteps heard on surfaces.
Addition of audio for HUD notifications when picking up/downloading datapad information.
Improvements to the breathing manager.
Blocking Issues
Mainly the network and multiplayer issues are holding us back on a functionality side.
Then it’s sum of the work that’s needed to get it ready for release because we have lots of bug fixing and polish to do including performance improvements.
AI do not spawn into encounters, as their triggers aren’t playing correctly! Players can fly to the locations to trigger events but no AI will spawn in. Thankfully they trigger in Missions.
The interior physics grid for single seater ships has a bug meaning that you can’t walk around them during flight and will fall to the back of the ship. Fun, but impractical!
The No Weapon animation set is not done yet, and not ready to ship. Should be in better shape next week as the team in Austin continues work on it.
EVA flight is difficult so needs fine tuning to be able to handle the character better, engineers will look into this next week.
EVA look and aim poses need to be created and implemented for the use of weapons.
Pistol motion sets need integration, this will be done next week.
The prone motion set is now a problem, as we have changed the way we do standing and alerted aim poses. This will change how players aim while prone, whether they be prone forward, or rolled on to the back. Needs some R&D love next week.
Issues with some ship and environment terminal UI not working properly
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Q&A: Ark Starmap
You’ve got questions, we’ve got answers! At CitizenCon we kicked off the first iteration of the Ark Starmap, a joint effort between our writing team in Santa Monica, our web developers Turbulent, and our strategic partner Gamerizon. We’re very happy with this first release, and wanted to give these teams a chance to answer some of the questions you posted in our forums.
Ken Hwang from Turbulent
David Haddock, Cherie Heiberg, Adam Wieser, and Will Weissbaum from CIG Santa Monica.
So without further ado, the questions… and the answers…
Questions & Answers
Hey! Why does the map say Pluto is a planet?
Currently, Pluto is listed correctly as a Dwarf Planet if you click on the planet and open up the information disk. However, the way the Starmap database works right now, in order to have an object look like a planet it needs to be labeled as planet type. This is not ideal.
We are in the process of looking at revamping the classification system, so that a celestial object’s actual type will be displayed first (such as Terrestrial Planet, Gas Giant, Dwarf Planet, etc), and its subtype will be displayed second (such as Rocky, Ice, Smog, etc). Under this new system, Pluto would be a Dwarf Planet type with a subtype of Ice. We are also working on an updated classification system for stars by further separating out the stellar and spectral types. Once the classification system is revamped, it will be more precise in its ability to describe what kind of celestial body that you’re seeing (like Pluto being a Dwarf Planet).
We are also still populating the Starmap. If you check it today, you will see that Pluto is now in the company of its moon, Charon. We’ve also added an Observation Base to the Kellog system and two more planets to the Kallis system. Populating the map will continue because we have so much to share with you. Stay tuned for more additions!
Which ships can fit in which size jump points?
This is something the designers are still looking at the specifics of, and we hope to release more information when it’s available.
Can you explain how the Ark Starmap relates to the Game Universe Map and the Digital Starmap package items?
The Game Universe Map that some backers pledged for is a physical poster that will feature a 2D representation of the Ark Starmap. The Digital Starmap is a digital copy of this poster.
The ‘Map Room’ is also still in the works and will be an additional area added on to hangars that will allow players to interact with the information in the Starmap in unique ways.
Can the map have an easter egg that glitches the Earth info tab to read “Mostly Harmless” every 25th May (Towel Day)?
The web Starmap is integrated with the RSI website platform, so technically it is possible to “glitch” the Earth info tab. But we categorically deny the existence of any Easter egg in the current Starmap.
The information on the map is great, but what about more information? Wouldn’t more information be even greater? What about Galactic Guides and the Galactapedia?
More information would be great, and we are eager to provide it as you explore the systems and worlds of Star Citizen. To put things a little more into context, the short blurbs we have in currently might not look like much, but with the number of systems, worlds and celestial objects we have there is around 60 pages worth of text in the map already. Just like the large game, we hope to release more information in steady waves. Our next step will be to begin to connect the Starmap to more detailed Galactapedia articles as they become ready to post. The information will be more high level to start, but as the game gets closer we will continue to add more and more details and continue to flesh out the world.
As far as linking to the existing Galactic Guides and Observist articles, we debated it, but decided in the end to keep them separate. Lore-wise, the Ark is a scholarly institute whereas the Galactic Guides and Observist articles are more akin to tourist and traveler resources. It’s the difference between reading an encyclopedia and a guidebook or studying a map in an atlas or a map printed in a brochure you find in a hotel lobby. The Galactapedia will be connected to the Starmap while the other posts will link into other various resources.
On a more meta level, because we have a better understanding today of how we want systems to be designed then we did when we first started writing the Galactic Guides, a lot of them have little details here and there that are out of date. We didn’t want to link the Starmap directly to incorrect information. Our hope is to eventually update them, but that is a large task and will take some time. As a first step, we have already updated the Stanton Galactic Guide to match the most current design.
How do undiscovered systems factor into the Starmap? Does the Starmap automatically update even if a system isn’t reported?
The Starmap only shows known systems and jump points. There’s a lot out there to discover, and it wouldn’t be fun for anyone if we added that to the Starmap. To answer the second question, the system would need to be reported in order to be added to the Starmap. This way, if a pirate faction discovers a jump point, or if an enterprising merchant discovers a new, resource-rich system, they can keep their discoveries to themselves.
Is there any chance we will get access to the Starmap code and API? We’d love to peek behind the curtain to see how this all came together and maybe even make a few tweaks or create our own apps.
We love the enthusiasm over the Starmap and everyone’s interest in how it came together. Currently there are no plans to release the API or code, though it may be something we look at again farther down the road.
With that in mind, if you have any future suggestion on how to make the Starmap better and more user friendly, please let us know! While we probably won’t be able to get around to every suggested tweak, we want this map to be fun, informative, and essential to the game. Your continued feedback will be vital to this process.
How are the distances of routes calculated? It seems odd that a route with more jump points would be less AU than a route with fewer jumps.
The AU distance that you see when planning a route is a calculation of the distance between jumps that you will have to fly at regular or quantum speeds. Jump travel is not included in this as it cuts through space and does not add much distance to your journey. However, it does take considerable fuel to jump. Players will have to balance the fuel cost of jumping with the extra time and risk of flying through normal space.
Will we be using the Starmap to track missions and trade information in the game?
Our current thinking in-lore is that the Ark Starmap will not have live data. The Ark will release regular updates, but information needs to be vetted, confirmed and double checked by researchers before making it on to the official map. To keep track of more up to the minute information, that is where the mobiGlas’ skyLine and other apps will come into to play. SkyLine is where players would store their personal information on top of the map. This could be stuff like secret data, information from NPC sources, and mission locations. They would also be able to switch on additional layers with the latest data from the TDD about trade or the Advocacy about crimes that are happening, etc.
Will we see further adjustments to the interface controls in the Starmap?
We hope to keep refining in future iterations both the interface and the visuals. While there are no definite plans to share yet, we are looking into the possibility of adding things like WASD movement, separate sound effect and music toggles, and manual zoom controls.
To get the interface to where it is now, we had to consider a wide range of users and even the possibility that the Starmap might be someone’s first experience with Star Citizen. For example, when it came to the L/R button we decided that the left mouse button should perform the most natural action in each view. In 3D view, the natural inclination is to rotate the camera. Meanwhile, in 2D view, panning becomes the first instinct.
Are there any plans to integrate tablet and mobile support with the Starmap?
Yes, this is something we’re considering for a future release of the Starmap. We all agree that being able to explore the ’verse from the bathroom would be pretty great.
What is this sorcery?
Astromancy.
And with that we wrap up our first Q&A about the Starmap. Like all aspects of Star Citizen, this will continue to grow and develop as time goes on. We’re going to leave the Q&A Thread in the forums open for a bit to collect more questions and we look to do a second part to this Q&A in the coming weeks.
If there was ever a milestone that deserved a letter to the community it was this. When I first started on this adventure I would have never dreamed that we would ever this many people and this much support in building Star Citizen. It’s amazing to have a community and team that believe so fervently in what is being built… Say it loud: PC games are back, space combat games are back… we are making Star Citizen possible!
We’ve put a great deal of thought into what would be an appropriate update to celebrate this milestone. But wait! Before we continue, it seems there’s an urgent comm-link coming through…
Thank you, Admiral!
It goes without saying that it was the thrill of a lifetime to work with Gary Oldman and the rest of our amazing cast. I have certainly had a hard time keeping quiet about that work these past few months; everyone on the team has wanted to shout it from the rooftops. The quality of Squadron 42’s principal cast is another testament to the community: you have supported us with such passion and given us the room to create a universe that has attracted top talent, eager to explore the cutting edge of story and games… that’s not something that happens every day!
As I was saying before I was interrupted: one million Citizens! The stars of this game aren’t all Hollywood actors or big name game developers… they’re those you who are making the game possible in the first place. Our one millionth Citizen is Edenstar. Appropriately, he, like so many of you, were introduced to Star Citizen by a friend who was passionate about the game… in fact, he says he joined because he was worried he wasn’t going to see his friends anymore after the game launches! I’ve said many times that backers are our best marketing, and here’s some pretty solid proof! Edenstar, Pikes-zen, we’re going to go ahead and give you each a brand new Sabre to explore the ‘Verse with. Enjoy!
In honor of our newest Citizen (really, our thousands of new Citizens!) we would like to give something back to the entire community for all your incredible support. Starting today, we are eliminating ‘Alpha Access’ and the $5 module passes. Anyone who has pledged for a Star Citizen Package can now play today without worrying they won’t have access to some portion of the ‘Verse in the future. No Star Marine pass, no Alpha 2.0 pass… no additional payment needed for any module in the works, pre-release. Going forward, should we need to put out some sort of limited release it will be done through the PTU test server. All backers will have access to any live release, the moment it publishes.
In addition, I’d like to reward our earliest supporters who made it possible to get to this point. Everyone with an ‘alpha access’ package will be awarded 10,000 UEC; everyone who purchased an Arena Commander pass individually will be given 5,000 UEC (with the cap raising appropriately to allow this.) You also have my most sincere thanks: you were our vanguard, the battalion that fought the good fight from the beginning. Your impact on Star Citizen will never be forgotten, for without your early faith we couldn’t be where we are today. (Please note that this credit payout is going to take a big script, so it may take Turbulent a few days to work out the logistics!)
It goes without saying that I’m proud of the incredible community that has come together to support Star Citizen to this point, and I’m so excited to watch and take part as you grow, evolve and change as we approach the finish line. Whether you were an Early Backer, a Veteran Backer, someone who joined yesterday or even one of the ‘Magnificent Seven’… we are all Star Citizens today, equal and with the same thing owed to us: the Best Damn Space Simulator Ever.
Knowing that one million people (and growing!) are counting on us will only further fuel our desire to deliver. Every member of the Star Citizen team already knows that we work for the backers… and reaching one million is just another reminder why we are giving this project all of ourselves. Right now that’s getting Star Citizen Alpha 2.0 in shape to share with all of you in the near future, and we’re in the process of closing down Star Marine as well.
Until then, the team and I thank you from the bottom of our hearts in making this possible. Star Citizen lives by the support it receives from the community, and that support has been loud and clear over these past three years. As I look around at artists, designers and engineers prepping Constellations and Retaliators for their multi-crew launch, I can say with certainty: I will see you very soon… in the ‘Verse!
What a show! We hope you enjoyed the CitizenCon 2015 livestream. For our part, the team is thrilled to have been able to finally share some of the incredible work being done on Squadron 42 and other aspects of the game. We hope it lived up to your expectations, and we can’t wait to push the envelope even farther! But now, it’s time to find out how we did it! This month, we asked each studio to write their monthly report as through CitizenCon had already happened, so you can hear exactly what they worked on to make the event happen. (It’s also important to remember that this work wasn’t just for a demo; everything you saw today was part of larger game development milestones!) Read on for details.
Subject: Organizational and Studio changes
Recently, we’ve heard from backers who are worried over rumors that individual CIG studios are closing. This is not the case! In fact, Cloud Imperium Games is continuing to expand as we continue to find talented employees; we had twelve new developers start in September, alone! The root of this confusion seems to be the fact that the reorganization that began when Erin Roberts took over as head of global production is changing the specific requirements of each studio. In the spirit of open development, we are sharing the exact e-mail Chris Roberts sent to the team on the subject of restructuring two weeks ago.
From: Chris Roberts Sent: Friday, September 25, 2015 8:12 AM To: CIG GLOBAL STAFF Subject: Organizational and Studio changes
Hello everybody,
I wanted to update everyone on some organizational changes we are making to maximize our creative synergy and development abilities.
It’s no secret that having a distributed development structure presents challenges as much as it provides advantages. At the outset of Star Citizen I decided that I wanted to go where the talent was rather than try to make the talent come to where I was. Without this approach we wouldn’t have some of the most talented people in the industry working on star Citizen. There are people in Los Angeles, Austin, Manchester and Frankfurt that are only working on this game because we have offices in these locations. We truly have a WORLD CLASS team.
With every positive there is always a negative, and that negative is the communication challenges that present themselves when people all working together on the same project are separated by large distances and time zones.
At the top level of the company, especially on the development side we’ve been discussing how best to reduce these issues while keeping the positive.
We’ve begun to think about how we can focus development at our various studios so people working on a certain feature or discipline can be concentrated for maximum effectiveness. Audio in the UK is a great example – the sound design and audio implementation in Star Citizen is just amazing (especially for our stage of development) – and this is partly because Lee Banyard, our Audio Director and almost all our audio staff are concentrated in Manchester, allowing them to frequently interact and problem solve in a way you can only do when in the same location. This is why when talking to Zane Bien about the possibility of becoming the global UI Creative Director, part of the discussion was about him leaving the beach and sunshine of Santa Monica to be with David Gill and Karl Jones and the rest of the UI team in Manchester that we are building to handle the global UI needs of the project.
We’ve also been thinking about how to make sure the key creative leaders in the company spend more time together and most importantly allow me to spend quality time with my key development lieutenants as I was feeling spread way too thin creatively – especially when we were in six game development locations with Illfonic and BHVR. When it was just Austin I could spend a lot of time between Austin and LA but as we’ve expanded to more locations and added external development my ability to spend time on the ground at each location has been reduced.
After much deliberation we have decided on the following:
To increase creative and game direction synergy Tony Zurovec will be spending significant time in LA (but still be based in Austin) in order for me and him to work closer together in getting the Persistent Universe in the hands of players.
Sean Tracy will relocate to LA as the Global Content Tech Director, allowing him to have a bigger impact on the whole company and help the LA team.
We’ve also decided to further continue the streamlining of our development groups – We’ve made a decision to focus the US engineering into two teams –
The backend services which is headed by Jason Ely will remain in Austin and will continue to work closely with Live Ops, which will also remain in Austin.
The Space and Persistent Universe game play and systems will be concentrated in Los Angeles, where things like the new item system and vehicle / space systems are being developed. This makes sense as Austin is weak on engineering CryEngine technical knowledge whereas LA is strong, and to really have an effective gameplay team we need one fairly large unit that can interact with each other on a daily basis. Having Stephen Humphries out in LA working closely with Paul Reindell and Mark Abent has really cemented the upside of having the people all working on the same systems being in the same space.
The current PU Art and Animation team will also stay in Austin, as will the Austin ship artists. Mark Skelton will be based in Austin but will split time between Austin and LA as the US Art Director. I really welcome having Mark out in LA regularly as I think it will significantly help the team.
On the design side Pete MacKay will move from Austin to LA to be on the ground with John Pritchett and the rest of the ship balance team to work closely with tuning our ships and weapons. Rob Reininger will remain in Austin to support Cort and prototype Persistent Universe locations.
We will staff up a small QA staff in LA, potentially with some key folks from Austin in order to support the gameplay work and also be collocated with the balance team (which has always been an issue as the designers that balance the space combat and flight aren’t in the same place as the QA teams that give feedback on this). We will also look to increase QA in Frankfurt for core engine and tech testing. QA in Austin will focus on Live release support and testing.
We are going to split Dev Ops (build support, internal distribution of builds) from Live Ops (deployment to the cloud, distribution to the players, maintaining & monitoring the game servers). Dev Ops will move to Frankfurt to be next to the engine team and the group that knows the absolute most about the engine and how best to compile it.
On the Production side Jake will remain in Austin and run Austin Production, with Jason Hutchins and Mark Hong both moving out to LA to help bolster the LA production staff – Having Jason in LA will be a great help as he has lots of development experience and has experience in getting big complicated online games out the door
Global IT will remain in Austin.
John Erskine will continue to run our various online operations, digital publishing and IT from Austin but will also regularly spend time in LA in order to actively create opportunities for our senior executive staff to interact in person regularly (no matter how good Skype is, it’s still not that in person discussion about an idea around the coffee machine)
We are actively hiring in Manchester and Frankfurt to build up the ship, environment, prop and character teams and in all locations to bolster the engineering teams.
Finally we are trying to focus our remaining external development partners on content creation as opposed to engineering , which we want to bring in house as much as possible.
We will have more internal staff than we have now – they will just be distributed differently between our four studios in LA, Austin, Manchester and Frankfurt.
As with all reorganizations there will be some roles that will no longer exist in their current location – we are really trying to reduce the single man outpost syndrome – as well as concentrate feature teams in single locations. In the event relocation doesn’t make sense for the roles that are now redundant we are at the minimum giving the small number of people affected five weeks’ notice as well as two weeks’ severance to allow people to try to land on their feet. In some cases we are allowing for work until the end of the year to give even more runway. This is the not so great part of the reorganization as we will definitely be losing some hardworking and talented people and we haven’t come to this decision lightly but ultimately we felt we owed it to the backers and the game to make sure we were allocating our resources effectively. So for the people in this category I’m sorry and hope the big lead-time helps.
I know for some of you these are some big changes but we wouldn’t be doing them if we truly didn’t believe they would help us get the project out and work closer together as a team. Please feel free to talk to your Studio Director if you have any questions or concerns.
We have an amazing opportunity to build something special. There is nowhere else that we would be given the support, the funding to make the open universe game we are making. No publisher or VC would ever back a game this ambitious on a PC, and probably not even on a console. I see the potential with Global Entity Ids, Entity Streaming, Large World, Local Grid and the Zone System coming on line to really build something that has both incredible fidelity and massive scope. I don’t think our backers are expecting just how cool their first experience of a large world map and multi crew will be. I also don’t think they are prepared for just how amazing Squadron 42 will be and how it’s going to push the envelope for interactive storytelling and action. I’m looking forward to blowing them away in two weeks and then putting the content in their hands and continuing to add and improve until they have a game that no one can compete with.
We will make history with Star Citizen. People still talk about Wing Commander 25 years later. We can go one better with Star Citizen.
It won’t be an easy road. We’re very public and there will always be obstacles trying to block our path, whether they are normal problems that crop up in development or outside agitators that are threatened by a completely crowd funded project building a dream game they wished they had the talent or support to build. Just remember that this is all noise and at the end of the day the game will speak for itself. It always does and that is the best reply to anyone that doubts our ability to deliver something great.
Let’s blow them away at Citizen Con and get Star Citizen and Squadron 42 in people’s hands!
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
September will be a month to remember. We finished so many major milestones we can’t wait to share with you below. We’ve been knocking things out left and right here in Santa Monica so check it out and let us know what you think!
Engineering
With a lot of action happening on the Santa Monica Engineering Team, we have been able to knock a few balls out of the ballpark.
The Engineering Team’s focus has been on improving the game’s stability. Lead Engineer Paul Reindell and Engineer Allen Chen have made various improvements to the servers, resource management, and Large World support. This work is directly improving performance.
AI Programmer Chad Zamzow has completed an AI module that allows players to fill empty seats in Multi-Crew ships with AI players during those long, lonely voyages into the blackness of space. Now we just need to teach them to fight! The visual effects of the Quantum Travel feature have had their finishing touches programmed by the team while Bugsmasher Mark Abent has been a titan in spearheading the refactoring of our Item System all while taking care of multiple Blocker and Critical issues that have been sent his way in preparation for the next release.
As part of the Engineering Team, UI guru Zane Bien has implemented a series of Flash callbacks which allow the different station screens to communicate with the engine. This and other completed milestones steer towards having players being able to take on various roles in a Multi-Crew ship by making sure each station has its own UI based on that player’s designated role.
Design
In the weeks following the massive amount of completed work for our Multi-Crew tech during the month of August, the Santa Monica Design Team has been capitalizing on the creative energies rippling through the office.
We completed designing the next step in the evolution of GOST that allows our designers greater flexibility while minimizing its resource footprint by using an “Entity Token” system. Senior Gameplay Programmer Steven Humphreys has been finalizing the system’s long-term goals. Many of those milestones having already been completed, the next are teed up for completion.
On the ship side, Designer Randy Vazquez and Senior Designer Kirk Tome have been working on the white-box designs of the Caterpillar, Xi’an Scout, and Drake Herald. Randy has finished writing design specs for how the Caterpillar’s various components will work together with emphasis on the new Salvaging system while also finishing the prototyping stage for these ships. The Drake Herald and Xi’an Scout just finished white box animation design with Kirk, where one of the biggest challenges was how to finesse the ergonomics of the alien Scout’s interior to be compatible with human animations – you’ll remember that a similar considerations were necessary for the human-flyable Scythe and Glaive as well.
If you frequent the chatroom on the website, then you will know our Designer Matt Sherman has been discussing his progress on the continuing development of the Ship Component systems, with several major milestones completed this month. These new systems have inspired discussion threads on our forums with regards to the Hacking mechanic and proposed further development on the self-destruct mechanism in ships.
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
The LA art team hasn’t had any time to slow down since last month! This month we’ve been plugging away and focusing our efforts on completing some of our longer-term ship and character goals – with a special focus on Squadron 42’s needs for the character team, and Multi-crew for the ship team – as well as working in tandem with design to flesh out the art for some ships that will be bringing some exciting new mechanics to the Verse!
Our character art team has had their most exciting month yet in preparing for Squadron 42 and beyond. In September we completed our male and female base sculpts, as well as for several other special characters. It has been a long process of iteration to reach the level of fidelity we want, but we’re very happy to say we’re there! Long term clothing and armor variations depend so much on the base sculpts being available, so that means it’s now full steam ahead for those aspects of character customization. This is a huge accomplishment since it’s not only a ton of hard work – but also sets a baseline for the rest of our characters. Lots of effort has gone into making these compatible with motion capture and body scan data as well, and we’re just beginning to see our first completed characters coming through these final stages. We’ve also put some final polish time into the Vanduul and Xi’An to make them even more realistic and impressive.
We’ve also made significant progress with ship modeling. The first half of this month saw lots of work on some of our smaller in-progress ships – for example, the MISC Reliant completed its whitebox stage, and the Drake Herald greybox is wrapping up. Towards the end of the month we concentrated resources on the RSI Constellation to culminate in one final push. Less exciting but equally important is all the hard work we’ve continued to pump into building technical tools and improving process and architecture for our ship development pipeline, which is already making our life behind-the-scenes significantly more efficient.
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
A lot of ship concept art has also been completed. Our focus for the month has been on wrapping up the Crucible and the Endeavor, which will introduce some revolutionary repair mechanics and exciting new science/and economic gameplay respectively. Both required more concept art work than your average ship… which has all been worth it to ensure that we’re bringing design’s visions to life in the best way possible. We also finished up the Vanguard variants, and have been making fantastic progress on both the Reliant variants as well as the luxury version of the P-52 Merlin also known as the P-72 Archimedes.
While we’ve primarily focused on new content, we’ve also fixed a variety of bugs. These include (but are of course not limited to!) some geometry and collision bugs across various ships, tightening up texture seams, and a whole slew of glass reflection bugs. The ‘highlight’ was a bug that occurred when we merged streams to AC 1.2 which made all of the textures on the Merlin disappear! We fixed that one right away.
Last but certainly not least is the work we’ve completed on components this month. Working hand-in-hand with the design department, we’ve blocked out all of the locations for components on all of our ships that are currently live. This was a massive undertaking, and we’re pleased to report that it went exceptionally well.
We’ve been making phenomenal progress, and the excitement isn’t over by a longshot. Stay tuned for next month’s report!
Writing
I refuse to accept that it’s the end of the month… dammit…
We’ve been on a heavy push on multiple fronts to get stuff ready for CitizenCon. To avoid spoiling any of the reveals, I’m going to speak in incredibly cryptic terms.
The entire writing team has been focused on one task in particular, meeting every day to brainstorm additional ideas about that, which has been an interesting and educational process. We’ve then been translating those discussions into lists of data as well as brief, evocative descriptions. The emphasis has been on ‘brief’ because often times it’s much more difficult to distill an idea down to a few sentences rather than having the luxury of writing for pages, more importantly, doing so can be a really valuable exercise to establish why that thing is different and unique. With this task, however, we have a character limit, so there’s a technical reason too.
Meanwhile, Will and I have been interfacing with the UK to provide dialogue lines and build some narrative scenes for two more things that are in heavy development.
All that in addition to the general workload of news updates, jump point articles and the general narrative and lore needs that come up in the day-to-day.
So, as you can tell, lots of things are happening. You’ll know it when you see it, because it’s going to be chock-full of the kind of lore you’ll really care about.
There you have it! Another productive month getting us closer to the larger vision. We have a great time working diligently to bring you the best game possible. Thank you for supporting this venture and working alongside us. Santa Monica out!
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
September has been focused on many items including the recent launch of the Social Module, and the upcoming first expansion to that module. Many other parts of the game are coming together and receiving multiple daily builds from DevOps and regular testing from QA – reaping the benefits of improved processes we discussed in previous monthly reports. We’re looking forward to Citizen Con which is fast approaching and will include a number of big reveals!
Persistent Universe Team
Art
The PU Art Team has been working towards our Social Module v1 milestone, which is the second iteration of the Social Module v0 milestone we released back in August. Much of our efforts this month have gone into what we’re calling “ArcCorp Phase 2”. This new phase of Area18 adds a construction zone that splits off back behind Dumper’s Depot.
This construction zone doesn’t have any shops or anything yet (although there are some vacant shop exteriors that you can see in progress), but is meant to provide a venue for multiple facets of gameplay in the PU. Areas like this will seem innocent enough during the day, but at night there will be loads of illicit activities taking place here for NPC’s as well as Players to take part in. We hope this area will eventually showcase the dynamic nature of the PU, where you never know what will happen in any given area until you stick around long enough to find out.
Additional features of ArcCorp Phase 2 include a gigantic crane prop created by Patrick Thomas, a gathering area for people to breath in fresh oxygen being pumped up from underground (the air on ArcCorp isn’t exactly healthy, after all) courtesy of VFX artist Lee Amarakoon, and a wide open area to drive buggies around in. A hearty thanks goes to Cort Soest for leading the charge on getting this new amazingly detailed area optimized enough to run on everyone’s machines.
Our concept team is ever looking ahead, and this month spent their time fleshing out the look and feel of additional landing zones. Ted Beargeon has been focusing on defining the differences between the various Stanton landing zones and is now shifting focus to defining the MetaClassicism architectural style. Megan Cheever has begun concepts on the Frontier>Fashion Casual clothing line, which will primarily be seen on the upcoming Levski landing zone in the Nyx system. Lastly, Ken Fairclough has been working away on look/feel concepts for Crusader. This particular landing zone is Mark Skelton’s favorite so far, and we can’t wait to show it off to you.
On the Animation front, we’ve been busy developing all of the new emotes you guys are getting with Social Module v1. We originally set out to provide 25 new emotes, then decided we’d go the extra mile and provide 50, count ‘em FIFTY, new emotes instead. We hope you guys enjoy burping, whistling, waving, standing at attention, and doing the chicken dance in the new release, among many other expressions.
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
This month’s goals for PU Design largely had to do with preparing Social Module v1 for release. There was a lot of back-and-forth going on between our designers and animators to get the emotes implemented and hooked up, for example. There was also much time spent on getting the PTV Greycat up and running so that it could not only drive around ArcCorp, but deal damage and explode as well. We expect players will have loads of fun with this feature!
Tony Zurovec spent much of his time this month drafting up the design document for the Endeavor. This posed a number of design challenges but ultimately when implemented in the game will be one our most intriguing ships to date.
This excerpt from the link above says it all:
“The extraordinary level of customization possible as a result of the Endeavor’s modular design will allow players the most comprehensive opportunity yet to construct a multi-purpose ship according to their own precise specifications. The ability to retroactively and cost effectively alter that design – by swapping out modules at a later date – will enable owners to quickly shift between different economic pursuits depending upon the most attractive risk/reward opportunity at a given moment or simply their whim, which is a dramatic departure versus other ships with a fixed purpose.”
Other aspects of PU design were focused on kicking off a couple of new environments. We signed off on the blueprint documents for both the Casaba Outlet clothing shop and the Million Mile High Club private lounge. These two environments are now in full production at Behaviour in preparation for our next milestone.
All in all our future is looking bright, with so many fascinating and engaging features in play. We’re excited for you guys to try out the Character Loadout Selector, the improved chat interface, all the additional emotes, and the PTV Greycat in Social Module v1! As great as these features are in the upcoming release, they are just the tip of the iceberg for what we’ve got in store in the coming months. So get pumped!
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
September was heavy with feature development for Social Module iterative releases, support for FPS and Multicrew feature development, as well as working closely with QA, DevOps and Production on stabilizing our Game-Dev branch after integrating our huge Alpha 1.2.0 stream down into Game-Dev. This is all a push to work towards a more stream-lined workflow for all our future feature releases and bug patches. It’s been a labor of love with big pay-offs and we’re looking forward to the continued reaping of benefits from that branch integration.
Austin Engineering has been working closely with our friends at Behaviour on such systems as improved chat (including private chat channels) and putting a lot of under-the-hood work in place to support being able to have the game choose instances of ArcCorp where your contacts are hanging out. A ton of restructuring of universe services based on tests and experiment data has been underway as well, and the Network/Server Team has been syncing up closely with DevOps on the most efficient ways to get various systems and databases in place. Working with our friends at Wyrmbyte we also got in a lot of network optimizations for both player characters and NPCs to improve your experience, not only in ArcCorp but throughout our various modules and the PU as a whole. We have also made several improvements and bug fixes to our Generic Instance Manager (GIM) and lobby system.
Long term technical discussions have been going on between Austin Engineering, the UK team and Wyrmbyte, and planning has been ongoing for a lot of crucial network/server needs and concerns. We’re working to ensure that our near and long-term core network/server needs are scoped and scheduled in together with the appropriate feature development across all CIG, with the various dependencies and puzzle pieces in mind.
In short, we’ve been juggling near term Social Module feature development, support for other near-term modules (such as FPS and Multicrew), and long-term planning and work for various network/server core systems that will be needed for all our CIG studios and Star Citizen experience as a whole!
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
For the month of September, QA has been focusing on the stabilization of the Game-Dev branch. QA will begin each day by comprehensively testing each module and verifying any potential fixes. At the end of each day QA will email updates broken down by module which detail the general health of the build listing the most critical issues present and any new issues found that day.
At the same time, QA is continually testing new content. On the Star Marine front, Tyler Witkin and Andrew Rexroth have been very busy testing the newly implemented character rig and ensuring that all animations play correctly and that the hand IK (How your hands hold the weapon) are accurate and working properly. Also a new HUD (Heads up display) and Helmet UI came online this month. Tyler and Rex have been heavily testing the new HUD/Helmet UI and providing feedback. The new Helmet UI is way more intuitive with lots of combat warning indicators(warns you about grenades/incoming fire/etc).
Social Module testing has been continuing as well. Some of which include a significant expansion to Area18, updated store fronts, a revamp of the chat system, additional emotes and a new outfit changer in the Hangar.
Robert Gaither and his UK counterpart Steven Brennon have been busy testing multi-crew ship functionality and our new massive largeworld map called Crusader. Crusader is part of a prototype of an actual system in our Persistent Universe. Crusader is proving to be quite impressive and will change the way we play dramatically.
Additionally much work has been done on our back-end services. Jeffrey Pease has been working very closely with our back-end engineers Tom Sawyer and Jason Ely to ensure each resolved issue is verified fixed and each issue submitted has all the required information to be effectively investigated.
We are very happy for the official release of the new Issue Council! The Issue Council can be accessed through the Community section of the RSI website and will help to streamline player generated bug reports. Other members of the community can then contribute and vote on each issue. The Issue Council has already proven very useful and will make reporting issues a much better experience.
Each module is coming together. The true vision of Star Citizen is beginning to take shape. We are very excited to witness and share with you this moment in history and very much look forward to seeing you in the Verse!
Game Support
Game Support has been busy in September and we’ve been nothing but excited with the successful rollout of the Issue Council. For the first time, players have been able to submit bugs with reproducible steps, have them reviewed and voted on by other players, then have CIG look at those verified reports and get them into the development pipeline.
We’re really looking forward to showing you the fruits of those results in our upcoming 1.3.0 Patch Notes, where we’ll highlight how your contributions are making the BDSSE even better.
We continue to work with DevOps and QA and we’re happy that the new Launcher is performing up to production levels today on all OS versions. Now that 2.4 is out the door, we continue to hammer away at the one-off issues that are affecting fringe systems.
One other note: Quite a few players have asked about our “playtester” group that we’ve talked about in our last monthly report. We’ve had to push that out of September and into late October since some of our timelines for testing changed, but be assured, we very much want to start this process up after CitizenCon.
And, Game Support is growing! We’ve just posted openings for a Game Support Staff position in Manchester, UK and we’ll be excited to provide more hours of support throughout the day between Europe and North America.
IT/Operations
Each month this year seems to be better than the last. The IT department has been working on several exciting projects this month to keep us very busy. Hassan and his team didn’t get much time to relax before starting all the preparations for CitizenCon which will be hosted in Manchester at Runway Visitor Park. We are all looking forward to this event as it may be one of the coolest venues we’ve setup so far.
Several members of the IT department got to work directly with DevOps on the build system improvements. Massive improvements in performance and efficiency were gained this month through our coordinated efforts. Doubling the number of development builds internally is great but this doubles the amount of data we’re delivering between the studios again. This used to be a bottleneck, but now we’re ready with the improvements already in place on our existing replication system, and we’re not stopping there. Mike “Sniper” Pickett is already testing prototypes of a new demand only system he has written which promises to further reduce our long distance build transfer times.
This month we also got a very special visit from our friends at Intel who brought us some new hardware to test. Everyone in IT has been impressed by the performance of the new 750 series PCI Express SSDs we’ve been testing. These drives are actually so much faster than standard SSDs that you can see it. Windows boot time on one of the machines was simply too fast to time. Of course Star Citizen runs great on these drives but they really shine on the dev boxes particularly for Artists and Engineers. We then we got to thinking about the build servers and the constant need for improved build times and faster iteration due to the size of our game. We asked Intel for help with this and they responded with a test server that is simply stunning. Our testing has only just begun but we’re already thinking of new ways we can utilize this technology to take us to the next level in efficiency and performance.
Dev Ops
This is our 1 year anniversary as a formal department here at Cloud Imperium Games! To celebrate this achievement we’d like to share some of the improvements we’re most proud of
When DevOps started one year ago, getting a game build created, patched, and uploaded took an average of 13 hours. Now that average is just 3.5 hours. A year ago it took developers on average 90mins to copy a build to their machine to begin work, now that takes just 24mins. A year ago it took a player on average 2hrs to download 25gigs with a 100mb connection. With the new launcher it now takes 14mins with the same connection. A year ago the team had to upload and build the live server infrastructure by hand, which was error prone and took on average 2.5 hours to finish. Now most of the deploy is automated and takes 45mins. You can see how critical these improvements are to preserving the efficiency of an average day at work when you have lots of developers, including testing and deployment! With the completion of the new BuildBot build server this month, we have had even more improvements roll out.
In all, the new build server took average build times from 4 hours down to 1.5 hours. We are now able to simultaneously run 3 builds at a time, where before we were able to only run 1. Due to these improvements, we can now run 48 builds a day, as opposed to only the 6 builds we were able to before. This huge accomplishment, which was completed in only 4 months of work, should drastically increase the productivity of the company.
As you can probably tell, September was all hands on deck to finalize this new build server and its corresponding build status page. We have recently decremented the old build server and cannibalized its delicious hardware to supplement our new system. In support of this project and its deadlines, all members of the DevOps and IT teams pitched in to help build, troubleshoot, and deploy the surrounding support infrastructure that is required for a modern build server. Data storage, build server hardware, server deploys, data replication to each studio, build distribution to developers, uploads to the CDN, and then testing each of the items listed, were all worked on this month to make sure we hit our deadlines and improved the company’s productivity. I personally want to thank every one of them for the incredible effort, creativity, and long hours that were put in to make this happen!
The team has also continued to release launcher patches that added functionality to track player behavior and create records of issues players experience for future investigation and fixing. These patches have also fixed some of the known bugs and added a new compatibility mode that fixed most of the people having trouble downloading torrents. There was also a pass done to improve the speed of the peer to peer traffic.
DevOps has also have been working with the Network Engineers to refine services, fix bugs, and analyze the issues we are currently seeing in the live environment. The team is continuing to refine the deployment process to QA servers, PTU, and Live with the goal of continuing to reduce deployment time, and complexity.
Next month we will begin to put more time improving our internal build copy tool and build status page. The v2.3 and v2.0 of each of these tools are scheduled to roll out in October and will hopefully continue to make work easier and faster for the company. October should continue the trend of improving productivity here at CIG!
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Greetings Citizens,
Let’s get right to it…
Art
One word – Growth! The team is really expanding, we’ve been adding extra desks here there and everywhere, making plans for how we can get our projected staffing levels squeezed in, we are two floors, who knows – maybe another soon!
Lots of concept work going into props needed for the Idris, additional style guide work, Idris Front turret, Freelancer interior revision, Idris mess hall and a new fighter ship from Aegis. We have hired two new internal concept artists and this will really help us proceed to define and clarify many areas of SC.
UI
Screens, screens, and more screens – Power, Shields, Global Overview, Missiles, Idris interior screens PLUS Gav has been working on the Idris hanger decals, Comms relay screens and the Airlock screens as well as updating FPS HUDs to fit in with the line work and a new ammo system.
Environments
This month the environment team in the UK has been hard at work sprinting through full production on the “baby PU” large world map. There will be multiple POI (Points of Interest, or things to see!) for you to explore within this large world sandbox so we are trying to make sure that each of them feels interesting and dynamic. There will be plenty of cool places to discover and rewards for the adventurous space traveller, but in the mean time we need to continue to polish, polish, polish to get something outstanding out to you guys; believe us, it’s time well-spent and you’d notice the difference if we didn’t. Additionally, we are working in delivering in art passes, as time goes by the areas will update and increase in fidelity and function – initially rooms will be quite basic working with the core set, then from there we’ll identify the functions of the rooms and really start to give personality to the space stations.
Ships
Ships are ripping along! There has been a lot of movement on the Idris interior and exterior, the Retaliator modules (now being constructed in-game) and the Avenger. We’re building both the single and double cockpit versions, along with living quarters and rear modules for the variants. The process of bringing the Vanguard into the game has started, with an aim to get it fighting in the game sooner than later. The Starfarer Captain’s room and airlock have been finished, and work is ongoing on the Cutlass damage system and cockpit fitting.
Props
The Prop team has been heavily focused on delivering assets for the CitizenCon deliverable. We’ve been working on some rather special hangar objects and rewards. Some ship specific props have been worked on and they should be coming to a ship near you soon. A fair chunk of bug fixing has been happening for FPS fixing up physic proxies and making sure you can shoot without clipping the edges of collision shapes and through gaps in the props. (That’s why “polish” is often essential and isn’t just cosmetic. It has a real impact on how functional versus how buggy these early builds may feel you as a player!)
A small amount of work has been invested in supporting new game modes where possible, making sure the other teams have what they need to flesh out their ideas. Finally we have been helping out with creating a new ship weapon and have started looking at the new ship component system.
VFX
What a busy month it’s been – no change there then! The VFX team have continued to “sanity check” existing effects since the major game-dev merge and 3.7 integration the previous month – which basically means checking through our particle libraries to make sure all our effects are still behaving as expected.
Due to the sheer volume of effects we have throughout Star Citizen, this has proven to be a time-consuming task, but worth it nonetheless; these kind of maintenance tasks (often referred to as the “non-sexy stuff”) also give us an opportunity to update any older effects that we feel can benefit from new features (such as greater control over soft particles, and finally a working camera distance offset) and better texture assets etc.
Continuing with the “non-sexy stuff” (someone’s gotta do it!) we recently encountered some issues where environmental effects were not showing up as expected. This meant we needed to check through every level/map in the game and fix up anything that was missing. This turned out to be less than straight-forward because there were several, unrelated reasons for this happening (i.e. it wasn’t a one-fix-for-all solution).
Aside from checking on our existing work, of course we’ve been busy creating new content! For example:
Following on from last month’s destruction pipeline improvements, we have been rolling out the latest exterior damage effects for several of our ships (and even a buggy) as well as implementing “Interior States” – formally referred to as GOST – effects for the Constellation, Retaliator and Cutlass to name but three. We’ve also begun ambient interior effects for Idris, which technically is a ship but feels like a level given its size! Can’t wait for you all to see how awesome this ship is looking by the way…
We have also begun effects work for several new map areas, including dust and debris for MASSIVE asteroid clusters and ambient effects for a satellite base. Aside from this, we also gave some love to the laser sniper rifle’s effects, and two new ship weapons also required a full set of effects.
All that’s left to say, is that we’re super excited to be attending CitizenCon in “sunny” Manchester and showing off our latest stuff – roll on October!
Engineering
We’ll that’s CitizenCon been and gone for another year and we hope you’re as excited as we are for Squadron 42! It being held in Manchester this year, underneath the iconic Concorde, made it extra special for us.
If you watched the event you would have seen the Morrow tour of the Idris. This gives you a sense of where we’re trying to go with making you feel like you’re not only part of a fully functioning ship, populated by believable characters and not just some robotic androids, but also making you feel like you’re part of a family where you can form relationships with the other crew members. This brings several technologies together, all working seamlessly with each other, from the conversation system, Subsumption, AI, animation, inner thought text, speech, lip sync, and many more. For example having the Morrow character walk and talk at the same time. Doesn’t sound or look hard does it? Except you wouldn’t expect a normal person to just walk at a set speed, looking straight ahead whilst chatting away. They’re also going to be spending some time looking towards your character, they’re going to be gesticulating, slowing down, stopping, speeding up, reacting to you if you drop back or even just walk off (this isn’t just a cutscene – you’re still in control of your character!). And none of this can just be one big pre-canned animation, as we don’t know where you the player are going to be or what you’re going to be doing. So this involves the AI doing its pathfinding but contextually depending on what they’re talking about and where the player is. We need to have the walk animation, but with some gestures fragments, blended with a look pose and maybe a soupçon of IK to make it all look natural. The use of Subsumption enables Morrow to have a sense of purpose, the conversation system adapts so that you can react to what he’s been saying using the inner thought text. And all this will change depending on their current mood. If you’ve messed a mission up and they’re angry characters can display very different body language than if you’ve aced it. Then apply that across all the characters on board the ship and we feel the interstitials in Squadron 42 will really bring the game to life. You may never want to leave!
The inner thought text is a new system we’ve been developing to allow the player to be able to make choices without it feeling like you’re just selecting some line from a 3 option menu. The idea is if you are looking in the direction of something you either can interact with it or make some choices by way of some text that will subtly appear allowing you to select what you want to do, or if you want just ignore it and carry on with your day without committing to any particular posture or action. It’s designed to be as unobtrusive as possible so as not to interrupt the flow of the game, but also give some better contextual sense of what you want to achieve. A good example is if you look at a chair a “sit down” message might float above it, which will be a definite improvement on our current “USE” prompt everywhere!
We’ve also been working hard on getting the large world map into your hands, which again you will have seen a small portion of at the event. We now see this a proving ground for integrating all the various systems we need to get working for Squadron 42 and Star Citizen, as it takes all parts of what we’re doing and brings them together in one big whole. One of the next big steps forward we’re working on is the level streaming. At the moment we can only have one level resident in memory at a time, so when you want to go from one area to another you have to unload the current level and then wait for the next level to load usually with a loading screen. We’re going replace all the level loading code with a new ZoneContainer system which consolidates everything within a level, and also the prefabs as well, into its own new structure. It also shows the power of the zone system our friends over in Frankfurt have been writing, which as you can tell by the name each container is its own zone as well. So almost everything becomes its own ZoneContainer, systems, planets, ships, space stations and so on. It allows us great flexibility as we will be able to now have levels within levels, or levels orbiting levels and, with the new seamless background loading of the ZoneContainers, a practically infinite playfield as well. Happy days!
Animation
The UK animation team has been busy getting all of the amazing performance capture scenes ready for the Morrow Tour demo on-board the UEE Idris Stanton, as well as filling out some of the background animations to bring the ship to life! We’re all really excited for everyone to finally know the ground-breaking Squadron 42 cast! The performance capture that Chris shot is fantastic and it’s now making its way in to the engine – we can really see it starting to take shape. We have also been working with the Squadron 42 level designers to figure out the best technical process to chop these animations up and get them game-ready and feeling natural in the most efficient way possible.
Our resident tech animator, Vin Chander, has been working hard on the facial tech so that we are able to deliver some top class facial animation for our outstanding Squadron 42 cast, and we’ve also been helping out with the FPS v0 requirements in order to get that out to the fans as soon as possible, which in turn helps drive the Squadron 42 schedule by sharing some of the same animations for ground combat.
Design
What a month! The excitement of CitizenCon has dominated all of the UK Design department’s minds in September and we have seen some great developments in the Large World system.
Following on from the GamesCom demo we have had lots of engineering updates allowing the Large World team to fully populate a huge area of space with lots of new and interesting points of interest. We have lots of different satellite stations, asteroid bases, communication relay stations, derelicts and ship graveyards dispersed throughout the large world map for you to find and explore, to name just a few. We are hopeful that all of this will soon be at your disposal and the Large World map will become a place that will finally begin to feel like the first step towards the “Star Citizen” vision.
You will have something that we can build on with regular updates, together with all your valuable feedback and with the design progression we already have planned I’m sure we can really set Star Citizen apart from anything seen before. For CitizenCon we wanted to give the player a taste of the universe that they can feel part of, explore and discover areas and points of interest. We wanted to get all the various systems a few rungs further up the development ladder as well, such as Quantum Drive, Landing, Multi-Crew, Local Physics, EVA, etc. The push for CitizenCon has really helped focus development on these and we have solid platforms to build on for a lot of core game systems.
Anyway…we hope that we managed to get something special in front of you at CitizenCon and we will continue to push as hard as ever with your continued brilliant support.
Graphics
This month, the graphics team have been exceptionally busy, as always we’ve been trying to make Star Citizen look as awe inspiring and as smooth as possible. We’ve been working on optimisation techniques, such as improving the shadow system to allow for efficient shadow rendering at large distances. Refining the level of detail (LOD) merging system which combines geometry at various LOD levels to significantly reduce draw calls. As well as improving the CryEngine’s LOD selection algorithm with a more intelligent system that takes into account poly density for all LOD levels; this ensures objects of various sizes and scales will switch LODs at appropriate distances. All of this is fundamental work towards enabling the game to handle such beautiful art work over such a massive gameplay space. It’s very important work – the lessons we learn here will inform everything we need to do to deliver the rest of the persistent universe over time.
We’ve also been working on the character hair shader to make it compatible with our lighting system and supporting the rollout of the wrinkle technology, which you’ll see in the CitizenCon Bishop’s Speech and The Morrow Tour.
As well, the damage system has been going through a large refactor to improve efficiency, robustness and functionality; it’s coming close to the end of the refactor now so our larger multi-crew ships where inter-changeable parts can take damage as well as the main body of the ship. As many people on the forums comment about multi-GPU support for Star Citizen I can openly state we make sure everything we do is multi-GPU friendly and the damage work is no different; we have put special work in to make sure it functions as desired in multi-GPU environments. The damage system is now ready for the next stage of development which is for the Repair mechanic.
QA
So another month over and another successful live performance from the UK QA team! We’re becoming seasoned pros with all this live stage demo stuff – next stop Hollywood, ey Chris?
In the build up to CitizenCon, the UK QA team had been working tirelessly to ensure what was demonstrated on stage was as ready as possible – daily reviews and constant iterations have led to what we hope you’ll all agree was a very polished showing.
We’re always doing our best to ensure that the latest features of Star Citizen reach the community as quickly as possible. QA’s role is never more pivotal than just before a large update to the game – and we’re really excited for the fans to see all of the new core tech that is coming together and the big announcements for Squadron 42!
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Hallo aus Frankfurt (Hello from Frankfurt),
The team here is in full stride and had a really productive month, as you’ll read below.
We continue to grow, bringing in 4 new people to the team this month alone.
Code
During September, we started working on planetary rendering and procedural generation – combined with other key systems being worked on previously (Large World, camera relative rendering, Zone system etc.) all these systems will combine together to reach our long term goal of seamlessly transitioning from space to a planet FPS ground level.
We researched and implemented a prototype for (earth like) planet atmosphere rendering, and the results are very promising.
We did an Initial full pass on fixing all static code analysis warnings and errors in the code base. This revealed several critical bugs in game logical, buffer overruns, etc. Moving forward we plan to have such checks be part of the prerequisites in our continuous integration and code submission process. This will reassure that builds are stable for the dev team and limit any extensive downtime.
Strong push on entirely revamping our build system for code to allow much for faster compilation as well as being able to locally build for non-native platforms (e.g. easily build the Linux server on Windows). We also pushed hard on our trybuild system into which continuous static code analysis check will be folded in. This system will prevent latest code in depot to break – that is, not compile or link – due to the influx of concurrent code changes on a daily basis. Goal is to mature our development process so people can work as uninterrupted as possible which can be an honest challenge as the team size grows. Growth can mean more productivity, but you have to invest work in a good development foundation. Otherwise it just makes traffic jams.
We did cherry pick several improvements from the 3.8 SDK updates such as the Character Tool which simplifies character creation and animation setup. Along with this we integrated initial support for 8 weight skinning (more finely accentuated animations especially on faces) and character attachment merging (to significantly reduce draw calls during shadow rendering). We plan to revamp these features to further improve the character animation and rendering pipeline.
In the animation and physics module we finalized the low-level functionality for procedural hit reactions, normal ragdolls, driven ragdolls and blending in and out of ragdolls. We started to clean up the interfaces and the implementation in Mannequin so that the game-code gets full control over all physical features. The functionality from SDK3.8.1 to create secondary animations on characters (simulation of capes, skirts, hair, etc…) was integrated and fully activated in the latest build. All functions and interfaces related to “auxiliary physics” were completely removed from the animation module. During The end of the month we started to modify the management of the physical setup for articulated entities, so that each “loadout” can have a unique physical setup.
We also continued to work with the UK team on finalizing the core zone system for multicrew release.
Cinematics
We worked heavily on finalizing the cinematic showing Bishop’s speech in the UEE Senate. This happens during an emergency session that happens after the Battle of Vega II (which kicks off Squadron 42)
This cinematic will run as its own little trailer at CitizenCon cinematic which is part of Squadron 42’s opening.
Bishop’s facial animation was a really good kick off test for the Squadron 42 facial animation pipeline. It is all running in real-time in the engine, including animated wrinkle and diffuse maps and lots of blend shapes.
The scene itself was captured at Imaginarium in May during our main story shoot where we shot all of Squadron 42’s story scenes.
What you see in the cinematic is pretty much an unedited performance by Gary Oldman. He was so good as Bishop that the whole crew went silent when he took the stage for his first rehearsal of the speech, seriously silent.
The environmental art for the Senate is really coming together nicely, only the giant statues flanking the podium holding the shield and sword are missing as we write this, but by the time you guys and girls read this, it should be all finished!
The UEE senate also features some cool mural artwork depicting mankind’s journey across 8 panels on the right wing of the senate rotunda and another 8 panels depicting mankind’s virtues. Artwork is heavily influenced by 1930s/40s Art Deco mixed with our Star Citizen tech. The Senate chamber should feel like it had been built in another time period before the events of Squadron 42 which is a nice touch.
We are also doing a little cast name reveal that will bookend the cinematic at CitizenCon, revealing Squadron 42’s principal cast.
Can’t wait until the fans see Admiral Bishop and the other amazing cast members for the first time!
We are also planning ahead for the next big sequence that will be tackled after the Senate speech is out…
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
We currently have one cinematic artist in the Frankfurt office, this month his main focus was finishing off the senate scene for the credits cinematic.
He modeled the senate interior with everything included to a semifinal stage, got it to a point that it could be handed off and used for the cinematic. He’s now working on the final stage and putting in the last tweaks and details.
He also started to work on the Skydock (also part of the credits cinematic), both the textures and mesh was created. He tried to make a kitbash approach to the skydock, using existing pieces to create something totally new. It’s a concept that we’re going to take full advantage of while building out the persistent universe, and we’re very happy with the results we’ve seen so far!
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
This month we focused on AI functionalities we’re using in a specific section of Squadron 42.
First of all we have integrate the CryEngine AISequence into our system.
Sequences are used to allow level designer to request an NPC to execute a specific activity as walking to a specific spot, reach a position and play an animation, converse with the player, look at a position or entity in the level, and so on. The importance of the sequence is that they allow designers to create a package of operations the character has to do. The package is considered as a whole, meaning we as programmers can make sure that something that is requested for gameplay reasons is going to happen no matter what, that it will have priority. In addition to that we can guarantee the level designers that if they want to abort a set of operations, all the actions following the interruption are not going to be executed.
We then extended the AISequences to support parallel actions. This is a key feature to allow the final results you have seen in the “Morrow Tour” section during the CitizenCon. We can drive an NPC to execute both primary actions (as walking, playing a full body animation, etc.) and secondary actions (as playing upper body animation, use dialogs, etc.) so that we can create a smooth experience between the AI systems as pathfinding and pathfollowing in addition to the Mocap animations related to the actor’s performances. Doing this also required some extension of the Mannequin system so that we can correctly override only specific scopes of a running animation (as an example imagine overriding the facial animation while the character moves).
We continued working on polishing the usage of the Usables as navigation links. We are now able to allow a character to smoothly transition from the locomotion movement to an animation controlled motion as a special vaulting, jumping, and so on.
We are also working in parallel on functionalities for PU and AC. Such as, this month we supported the PU emote system to correctly play looping animation in a multiplayer environment both for players and NPC.
In addition to all of that, the Frankfurt office has continued coordinating the work made by Moon Collider on the improvements of the DataForge/Behavior tree connection, and the improvements/new functionalities for Arena Commander and ships AI in general.
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Design
The design team has been focused on numerous things this month. Primarily we were busy refining the design direction for the game and providing feedback on key features for the FPS release making sure it gets completed in a state that everyone is happy with. At the same time we’re hard at work building out the roadmap of all the future content releases, detailing gameplay functionality we need, weapons, dependencies, etc.
The level designers have been working hard on finalizing the Gold Horizon map and finishing off all the specific details required for implementing a new game mode for the upcoming FPS release. At the same time they have started work on the new level & mission building pipeline and the upgraded prefab system that will allow us to create these missions far more efficiently for both Squadron 42 and the Persistent Universe.
On the AI side we are setting up the archetypes, items, mechanics required for the Morrow tour that we will show at Citizen Con this year and setting up the base systems and workflows that will be used for all Squadron 42 and Persistent Universe NPC interactions.
Another focus for us this month has been taking a hard look at the list of career mechanics being developed and figure out how they work with future ships and even existing ones as the cargo, component, and travel systems become increasingly more defined. We need to reassure that the design for both ships and careers work hand and hand with one another. After the research we’ll have a much better understanding of which ship fits which career and what still needs to be worked on for those ships & careers to really shine.
FX
Over the past month we looked into improving some of the effects for the ship weapons. This will make the dog fighting feel more exciting and cinematic. The end result is to make it feel in par with large epic space battles you’ve seen in blockbuster movies. We’ve also been working on polishing up the FPS weapon effects so they are ready for the launch of the fps module. Everything from muzzle flashes to impact effects!
To the right, you can find a few shots of some of the new effects for the dog fighting.
Audio
This month we added the audio scrubbing feature to the Editor TrackView (something that has never been done in CryEngine before), which means that our cinematics team are able to work much more quickly and efficiently on the awesome sequences revealed at CitizenCon. It’s going to pay off over the long term, as there will definitely be more of them in the future!
Aside from this, there was lot of bugfixing and post-integration cleanup work to make sure the audio system code is clean and stable, providing the solid foundation for upcoming modules and features
We also hope you liked the audio in the explosions previz shown in Around the Verse! Audio makes a huge difference and good audio really helps to sell the effect. We’re really happy about the feedback and reception that the previz received and look forward to working with the designers and effects engineers to deliver that across all the ships you’ll have in the game.
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Citizen Con is around the corner and we’ve been working hard throughout September to be able to show you some amazing improvements at this event. Without further ado, here’s what the team has been working on.
Design
The BHVR design team has got its hands full. We’ve finished the Million Mile High Club whitebox and have created two new shops for planet Nyx: a personal weapon shop and the medical unit. We also designed a new character loadout selector, we cleaned-up the ArcCorp level after its initial release and we created and integrated on a bunch of new flair items. We fixed a tonne of integration bugs on ArcCorp and in hangars and a few other surprises we can’t reveal as we are writing this update. It’s a very exciting (and busy) time for us now that the Social Module has been released.
UI
For the last week of August through to mid-September we were in the UK working with our colleagues at Foundry 42. We spent a lot of time discussing UI unification; when several different people spend over two years working on a various UI systems with very short deadlines between each release, a few inconsistencies naturally develop, but they need to be smoothed out. Working across different time zones can also be quite challenging, so when you can get everyone in the same room together to talk about a UI feature, how it should work, what it should look like, it really makes a big difference.
We also discussed different ways of improving our UI pipeline, identified some troublesome features, worked on how to improve manufacturer style guides (the UI team doesn’t just create interfaces, we are also responsible for a large part of the branding in Star Citizen). We left the UK feeling like we had accomplished a lot of work, and solidified a great working relationship.
Once we got back to Montreal, we kept the momentum going: we planned out our next steps to move towards UI unification, we updated the chat interface, improved the default keybinding control images, created a loadout selector interface, and fixed a whole bunch of bugs.
There are a lot of plans in the works, so stay tuned. Much more to come
Art
The art team has been hard at work fully optimizing ArcCorp. Thanks to this optimisation, we will be able to get more players in the same instance. We’ve also built a new area in ArcCorp. It’s still under construction … literally, but this will show how vast and immersive the planetside locations will be.
Code
During the month of September, we’ve worked on adding UI Support for new Chat features such as private conversations as well as a general UI overhaul of the Chat Interface. We’ve also worked on a new useable item and new UI interface which will allow you to customize the player loadout in a more convenient way, rather than using the F6 Key to swap a couple of set outfits.
We’ve been working on providing more information to the player with regards to the locations s/he will travel to via the Transport Elevator Console available in the Hangar. Information such as how many of your contacts and what contacts are already at a certain locations will be provided. We’ve also improved the Control Customization menu by making sure that changes are more frequently saved. Additionally, we’ve started expanding the Contact List functionality UI so that will allow players to form a Party with their Friends.
We have also been helping out on Star Marine. First we’ve been working on the UI and functionality that allows a player to customize his loadout before a Match, making sure that the proper items are available depending on what items/item package he actually owns. We’ve also been providing engineering support for Scoreboards that appear throughout Star Marine matches.
Some of us were flown over to the Manchester CIG Studio this month. During that time, we’ve had the chance to improve the Toolset that allows us to create UI. The main goal was to allow engineers/designers to be more efficient.
In the next Patch, you’ll also be able to appreciate a lot of the optimizations and improvements we’ve made to the holo-framework over the last two months. You might have already noticed some of the new features and optimizations in the Large World Demo that was shown at Gamescom.
Last but not least, a lot of the team effort has been concentrated on stabilizing the build following the integration of changes from a release branch back in to the main game development branch. We’ve worked on making sure that all features we owned are once again up to par.
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
This month was a great feature development month, with a lot of solid work on improvements, particularly on the ship front. It also saw us adding a new member to our team. Aline joins us from Pennsylvania where she’s just completed her PhD and we’re excited about the boost she brings to our R&D.
So what have we been up to?
We made quite a few improvements this month to Arena Commander and ship combat in general, such as adding a new missile sub-profile to the ship AI. Each ship AI agent is configured via a profile that can be customized by designers to make them behave differently, and to make this job easier, we have several sub-profiles defining different aspects of their behavior, such as their flying style or how they select targets. The new missile sub-profile allows designers to better customize how different ships will make use of their missiles, which will contribute to more variety in combat encounters. This mix-and-match flexibility will give us much more room for creativity and variation when it comes to rolling up varied behaviors in the game without having to limit ourselves to a small set of predefined personalities
We also did some rebalancing and tweaking of various ship behaviors to better support the greater variety of ships that enemy AIs are now able to pilot. With some of the newer ships being faster or more maneuverable than previous ones, we were finding that some of the behaviors weren’t performing as well and resulting in less enjoyable combat. This is always an ongoing process as we try to make behaviors take advantage of the capabilities of the different ships that AI can find themselves piloting.
Some interesting optimization work we did was allowing for obstacles to be defined for AI without requiring CryEngine entities to be created to associate with them. On some of our maps we have thousands of objects that ships need to avoid, and having to create full CryEngine entities to register each one as an obstacle can become expensive. Sometimes you still want this for other reasons, but with simple objects like rock fragments floating in space you can take advantage of registering it as a much more lightweight and simple object. So this will allow for performance improvements and creating larger and more complicated levels.
One really exciting task that we’ve just started on and will talk about a lot more next month is death spirals. This is the addition of cool death behaviors by ships to make defeating enemies feel even more satisfying. Once you’ve damaged an enemy ship so much that it’s going to be destroyed, we want to look at some different ways of making it fly out of control and possibly explode. This makes for great readability since it lets you see that the enemy is no longer a threat, and it allows you to savor the victory of a tough battle a little longer. There are several different approaches that we’re experimenting with to see what works well and what doesn’t, so keep an eye out for the results in next month’s report!
On the character behavior side of things, we’ve been making some improvements to how our behavior trees handle switching characters between performing different high level tasks. The Kythera architecture now supports a couple of different behavior paradigms, but the one we used for ships was based on the idea that when you tell an AI to do a new task, he will switch to a different behavior tree to do it. However, in character AI, smooth, carefully choreographed transitions are vital for high-quality results, and so it can be helpful to keep them running a single larger behavior tree and have them switch between different parts of that tree to perform different tasks. So we’ve added various bits of infrastructure that allow a tree to register itself as handling multiple tasks, while also making it easy to add handling of those task switches in the tree.
Finally, we added a few new features to the Kythera Inspector web debugging tool, particularly in order to allow better debugging of those big behavior trees I mentioned above. With smaller trees you can usually see the whole thing within your browser window without a problem, but with these really large trees you need to pan around a lot, and the existing scroll bars just didn’t cut it. So we added in a panning feature where you can just hold down your left mouse button and drag the tree around to see the part that you’re interested in. We also added in some persistence features so that if you’re looking at the behavior tree of a particular AI and you want to hop out of the game and make changes to the tree, when you hop back into game the Inspector will remember the AI that you were looking at and keep it selected for you, which streamlines behavior iteration and debugging. Whether or not that sounds exciting to you, the tool should help the content creators do their work more easily. The result: more content for you!
That will do it for this month. We currently have several cool ship related features that we’re working on (in addition to the death spirals mentioned above), but you’ll have to wait until next month to find out more!
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Greetings from Montreal! Here’s what we’ve been up to in the last month:
Community Hub
Last month, we launched the Community Hub and were overwhelmed by the quality and variety of your submissions. Keep it up! For those of you who haven’t checked it out yet, the Community Hub is your home for user-generated content (Citizen Spotlight), interesting links around the ‘Verse (Deep Space Radar), Livestreams and Podcasts. Staff picks will be displayed on the landing page, but you can click on “View All” to see all the contributions. Enjoy!
Issue Council
We released the Issue Council in the middle of the month, and we’ve already received over 500 bug reports. By using this tool, the community can contribute, evaluate and prioritize bug reports. Members can confirm bug reports, and up-vote or down-vote them. Once a bug report has been triaged and prioritized by the community, CIG can select which reports become “Acknowledged.” Acknowledged bug reports are automatically entered into CIG’s internal bug tracking software, so that they can be assigned to their developers. By involving the community from the very beginning, we save CIG developers a lot of time evaluating reports and identifying which ones are duplicates or invalid. The more you use the Issue Council, the more time (and money) that is saved!
Ship Upgrades
We continued to work on the revamped Ship Upgrade system, whereby you can upgrade one ship for another. The new user interface will make it a lot easier for you to choose from a list of eligible ships. You will be able to access this feature from your Hangar or from the Pledge Store.
Referral Program
Want to invite your friends to play Star Citizen? Now’s the best time to start recruiting new players and to take advantage of our Referral Program. Each member has a unique Referral Code which they can share with their contacts. If your friend signs up for an account on the website, they will automatically receive 5,000 UEC. And if they buy a Starter Package, you will earn 1 Recruitment Point. The more Recruitment Points you earn, the more rewards you will receive. To view all the possible rewards, click on the “Referral Program” tab in your RSI account page.
Squadron 42 Landing Page
To prepare for the CitizenCon announcement, we built a landing page to showcase the upcoming Squadron 42 single-player campaign. As we are given more information about the game, we will be adding more content to this page, and expanding the section to include the background story and other information about the game. Stay tuned!
Starmap
We have been pulling out all the stops to have the Starmap ready for presentation at CitizenCon. On the visual side, we added a preliminary set of textures for the different Planet types, configured different looking stars for every Star System, re-skinned the long-range scanners, tweaked the animation of the routes, and completed the user interface. We also added an intro loading screen and WebGL detection screen.
On the development side, we completed the routing algorithm (choosing the best routes between two Systems) and search tool. We’ve also worked closely with the CIG writers to validate all the data in our Starmap.
We’ve been working with the CIG audio department to add new sound effects to the Starmap, including original background music. You will have the option to toggle off the sound, but we believe you’ll want to keep it on.
By the time you read this, the Starmap demo will be available for your viewing pleasure. We hope you will love it!
Ship Happens
This was an exciting month for ship launches! We saw the unveiling of the Vanguard variants, the Harbinger and the Sentinel, fulfilling bomber and e-warfare roles respectively. We also introduced Battlefield Upgrade Kits, to be able to change the role of your Vanguard, bringing a whole new level of choice and variety to the already awesome ships. Not only was there the Vanguard sale in September, but also, right now the Endeavor science vessel was made available for the first time. The Endeavor was another exciting launch as it introduced the community to the idea of science as a role in the universe. Continuing with the theme of choice and variety, the Endeavor is being sold in packages with different science pods, or separately so you can mix and match pods to suit your needs for your next mission. Check it out while it’s still available (which is only a few more hours!)
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Part of Aegis Dynamics’ Phase Two of new ship models, the Sabre was designed as a space superiority fighter for those situations where you need to leave a lighter footprint. While no one will deny the Hornet’s place as the UEE Navy’s brawler, the Sabre offers an elegant and nimble alternative to handle an ever-evolving combat landscape. Designed to be a rapid responder, the Sabre is more than capable of establishing battlefield dominance for any number of combat scenarios.
Engineers looked equally to the past and the future to build the Sabre . Incorporating Aegis’ battle-tested power distribution systems into their dependable ship-hull construction while developing cutting-edge flight and system technology, the Sabre is truly a next generation fighter that represents the new Aegis.
Aegis Dynamics has designed the Sabre in response to a United Empire of Earth Navy’s request for proposal for a next-generation fighter capable of outmatching the Vanduul STINGER-class heavy fighter in speed and turning. While the Navy has not yet accepted the the Sabre bid, Aegis has opted to make a run of production prototypes available to licensed civilian operators.
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Ship Details
The Aegis Sabre is a new starfighter designed explicitly to premiere at CitizenCon 2015! The Sabre will be available from October 10, 2015 through October 19 as a concept sale. The Sabre has been designed to make use of systems already in place in Arena Commander, to allow it to come online faster than a ship that requires new game mechanics.
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
LENGTH
26m
BEAM
24m (Folded) 30m (Deployed)
HEIGHT
5m (Gear down) 3.8m (Gear up)
NULL-CARGO MASS
18’000 Kg
CARGO CAPACITY
None
MAIN THRUSTERS
2xTR3
MANEUVERING THRUSTERS
8xSize 2
RETRO THRUSTERS
2xTR3
BODY WEAPONS
2xS3 Fixed Laser Repeaters
WINGS WEAPONS
2xS2 Gimbaled Laser Cannons
SHIELDS
4xLight
POWER PLANTS
3xLight
All specifications are subject to change for game balancing.
About the Sale
This ship is being offered for the first time as a limited concept sale. This means that the ship design meets our specifications, but it is not yet ready to display in your Hangar or to fight in Arena Commander. The sale includes Lifetime Insurance on the ship hull and a pair of decorative items for your Hangar. A future patch will add a poster and then once the in-game model is finished you will also be given an in-game mini ship model! In the future, the ship price will increase and the offer will not include Life Time Insurance or these extras.
If you’d like to add one to your fleet, they’re available in the pledge store until October 19, 2015.
Disclaimer
Remember: we are offering this pledge ship to help fund Star Citizen’s development. All decorative ‘flare’ items will also be available to acquire in the finished game world. The goal is to make additional ships available that give players a different experience rather than a particular advantage when the persistent universe launches.
Limited sale
Military Ships Sale
In addition to the Aegis Sabre, we are bringing back a variety of military spacecraft in honor of CitizenCon’s Squadron 42 theme! These ships are being offered with three year insurance in honor of our third year of development. All will be available through October 19, and are listed below. Whether you’re looking to intercept bombers in a Gladius or to support your fleet with a Starfarer Gemini, this is your chance to pick up some advanced weapons!
Additionally, a ‘Fleet Pack’ featuring all of the ships in the sale plus the Idris-P corvette will be available for 48 hours starting with the CitizenCon livestream. You can find further details on the ship pages linked below.
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
WELCOME TO THE UNIVERSE
FREEDOM OF INFORMATION
At the dawn of the 29th century, a new center of knowledge and understanding was constructed: the ARK. Not bound to any one place, species or government, the Ark was established under a simple principle: to provide a neutral repository for all galactic knowledge.
A pet project of Imperator Marshall Leon, the desire was to usher in a new era of cooperation between species after hundreds of years of hostilities. Imperator Leon believed that the simplest path to peace was empathy and sought to unite the greatest minds of not only Humanity, but also of the Xi’An, Banu, Tevarian and even Vanduul* to endeavor towards this noble goal.
There were many hurdles along the way. The Senate refused funding when they learned the project was going to be run privately. Some vocal opponents were worried that the data shared would be used against Humanity. The invitation to the Vanduul incited calls for Imperator Leon’s removal from office. Yet despite all that, the Ark was completed, and as we approach the institution’s sesquicentennial anniversary, it is hard to deny the positive impact this incredible resource has had on civilization. To this day it continues to strive to present a holistic viewpoint of history; collecting as much knowledge as they can, from as many sources as they can.
Currently residing in the Tayac System, the Ark and its team of dedicated archivists and researchers curate this information for the Galactapedia and the Starmap. Invaluable tools that allow all beings to better understand the universe and find their way through it.
*The Vanduul, to date, have not participated in the Ark program.
EXPLORE STRANGE NEW WORLDS
The Starmap is a public resource that aims to provide a complete user-friendly overview of the galaxy, showing that we are all just a small part of something much larger and at the same time, that even a distant world can be only a few jumps away. And, as the universe is not a static place, neither is the Starmap. As our knowledge continues to grow, the Starmap grows with it. Compiled by the Ark with the latest data from the Imperial Cartography Center, private infobanks, individual surveyors and university astronomical studies, the Starmap attempts to provide an unbiased look at the galaxy. Though some information has come from the Ark’s other member species, it has been limited in scope due to Xi’An diplomatic complications and difficulties inherent with Banu recordkeeping.
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
Data Sources
In addition to tracking celestial objects and jump point routing information, the Starmap incorporates demographic information from several trusted sources:
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
POPULATION – NID 2944 Population Assessment Report
Generated by the UEE Naval Intelligence Division every year, this report is intended to serve as a reference for Naval High Command, policymakers, senators, and planetary leaders. Point-In-Time population estimates are derived utilizing data from UEE Census Bureau, UEE Department of Development, detailed orbital scans, and Naval on-site teams.
ECONOMY – J&P Score
The Jappa & Penner Economic Health Score has been an Empire standard for close to three centuries in evaluating the financial status of regions. Named for the firm who derived the ranking system, J&P Scores take into account a myriad of factors such as trade, growth, debt, capital, etc. to assign letter grades ranging from F for an area with little potential, to AAA to designate a hub of extraordinary economic value.
THREAT – TSAS
The Advocacy compiles crime statistics and casualty reports to create Travel Safety Advisory System (TSAS) to inform the public how dangerous they expect travel in certain sectors can be with Threat Levels ranking from ‘minimal danger’ to ‘extreme danger.’
Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
As excited as you probably are to get your hands on the Starmap, we are probably more excited to be able to share it with you. The culmination of months of debate, research and brainstorming between Design, Lore, and the Web Dev teams, it has been nothing short of epic to build a universe. With dozens of pages of lore written, countless spreadsheets shared, an exorbitant amount of wikipedia articles pour overed, hours of patient astrophysicist explanations, endless web code tested and re-tested, jump points nudged, stars tweaked and belts tightened, our heads, like the planets on the map, are spinning.
And we’re not even done yet…
Even as of this morning we were making adjustments trying to get things just so. And we don’t expect the updates to the Starmap to stop anytime soon. Consider this to be your Starmap Alpha.
For this initial pass, our focus was on the feel of the Star Citizen ’verse. We wanted to make sure that the systems you can visit (or sneak your way into) are not only interesting, but encourage you to want to go there and explore. But this is still a project very much in development. Those of you who have been following the game closely might notice some differences between what is presented in the map and what we had described earlier in places like the Galactic Guide. The Starmap represents the most up to date and correct information we have. If something disagrees, trust in the Starmap.
On that note, please bear with us as the map will change. The designers are still creating new gameplay, and we’re going to gain useful information on how to make systems the most fun they can be. We are continuing to work with astrophysicists and astronomers to take all our crazy sci-fi ideas and refine them to make them more scientifically accurate and as immersive as possible. To top it all off, we are continuing to plan for the Galactapedia release which will tie directly into the Starmap and provide you with even more information.
Of course, there is one huge major thing missing from the Starmap: all of your feedback!
ACCESSING THE WEB STARMAP
You can access the web starmap NOW via the RSI menu or clicking the ARK logo below:
BUILDING THE ’VERSE
by Benoit Beauséjour, Turbulent
Community vote
What a ride. Several months ago the community voted for our next project to take on. The starmap won ; by a long shot. Wide spread panic, tears and terror spread through the Turbulent office. It was the largest and most ambitious project on the table, required major coordination with CIG and was deeply rooted with the game. We were afraid not because we were worried of our abilities but because this is a such an important project inside the Star Citizen universe. We wanted to wow you guys and build the best damn web star map we could to really showcase the depth of the work the amazing CIG Writers team is doing. We wanted to make a map that would feel like it’s in the game….but in your browser.
Taking it on
Our first order of business was to get involved in the universe design process with Tony’s team @ CIG and start prototyping the User Experience. One of our core design goals was to build something on the web that could be ported and used inside the game space. This influenced the design of the different UI controls that power your experience in order to account for potential use with game controllers and the like.
We knew we needed to prototype and we knew we needed help to get there. We enlisted our next door neighbour, Gamerizon (Hi Martin, Robert and Louis!) to help us get off the ground and build our first round of the map prototype in Unity.
Our first prototype of the map, was demoed at the 2014 Christmas livestream. This prototype allowed us to test many interactions and design our base UI that would become what you will see online today.
Technology choices
We had made this choice beforehand but we confirmed it in our next step. WebGL was the way to go in order to bring a fast and efficient rendering pipeline in the browser. This standard browser API exposes the graphics card layers to the Javascript runtime of your application. This way, using a talented shader artist like Martin at Gamerizon, we were able to build nice holographic representation of stars, black hole and other phenomenons.
We needed an engine and we opted for Three.JS. It’s lightweight and fairly well supported and we used it before with the Holo Viewer. The map also uses several bleeding edge technology on the front-end side, the UI makes use of SVG animations, is built using a combination of languages and tools including Typescript, ES6, webpack, gulp, nodejs and more!
Moving from a stack like Unity to web-based GL API is a big step ; but one that proved worth it in it’s simplicity and performance.
Modelling an API
We knew from day one that we needed to be able to manage this universe. We set out to build a data model to represent the universe ; its stars and systems, planets and wormholes. Complete with an management interface and importers from CryEngine, this backend empowers designers to create planets, move stars and systems, collapse jump points and tunnels.
On top of this management interface and data model we constructed a solid REST-style API to allow the map client in your browser to load data sequentially, based on zoom and position, about the systems you visit. This API also has support for the search, persistent bookmarks and route searching algorithms.
Audio
If we wanted to reach our goal of building the ultimate browser map ; we need a soundscape and sound FX. There was no way we were going to try to do this ourselves and so we got major support from F42 audio. Matteo Cerquone built an amazing sound effect setup for the Starmap. Lee Banyard and Matthew Webster coordinated to get us a track from Pedro Camacho which once again blew us away.
The talent with the audio group never ceases to amaze me and I thank them for their support in the ARK Starmap!
The future
Major expansions plans for the map are in the works! Addition of real-time data coming from the game simulator, more models to represent other elements and phenomenons in space as well as possibly support for orbital mechanics. With the advent of other 3D browser standards like WebVR, maybe integration with virtual reality devices ?
The final list is still in the works ; but you can be sure we plan on expanding it and using this map to allow you to interact with the game universe even when you are not connected with the game client.
The result
We hope the result pleases the community. This project was very special to us because it is so close to the heart of Star Citizen.
I can share with you guys a little snippet of the behavior tree where the AI selects a cover spot that has a shooting posture and it then sprints towards the cover location.
