Jump to content

Characters (FPS) - 3.x


VoA

Recommended Posts

  • 2 weeks later...

Letter from the Chairman - Star Marine Update

LETTER FROM THE CHAIRMAN

 
 
09.jpg
 
 
 
 

Greetings Citizens,

On the set of Squadron 42On the set of Squadron 42Star Marine's Light Marine characterStar Marine's Light Marine characterMarine2.jpgMarine4.jpgThe Medium OutlawThe Medium OutlawOutLaw2.jpgOutLaw3.jpgThis set of images shows the recent lighting pass on the Gold Horizon mapThis set of images shows the recent lighting pass on the Gold Horizon map13.jpg12.jpg11.jpg10.jpg09.jpg08.jpg07.jpg04.jpg03.jpg02.jpg01.jpg05.jpgGrenade functionality updateGrenade functionality update

For the past ten weeks, I have been directing the performance capture shoot for Squadron 42 in London, next week will be the last week of the “main unit” shoot. Directing the Squadron 42 shoot has been one of the most fun and creatively rewarding things I’ve done. It’s where the story and characters written by David Haddock and William Weisbaum come to life for the first time and I can feel just how special Squadron 42 will be. The cast we have put together for Squadron 42 would not be out of place in a major motion picture. We are using the next level in performance capture, which is both motion and facial capture, allowing us to capture even the subtlest looks or moments. Every scene we capture we have between 1 and 3 cameras on every actors face, plus 50 cameras capturing their moves. This technology, combined with next generation character and facial rigs driving full 3D scans of the actors in the world of Star Citizen / Squadron 42 allows us to have emotion, nuance and subtlety that I don’t think has been seen in full player controlled gameplay before. I’m hoping that capturing this level of fidelity will make the world and story more visceral than anything I’ve done before, and will push interactive storytelling the same way Wing Commander did over its iterations. The story of Squadron 42 is going to be an experience that I think will be very special. Instead of watching a film play out in front of you it will feel like you are inside a living world, living a story that you only normally see on the big screen but it’s YOUR story, not one of some protagonist you need to associate with! By the time the shoot is over, it will have been longer than Wing Commander 4 (42 days) or even the last feature film I produced, Outlander (51 days.). You need this kind of time to capture real performance. We’re shooting something as nuanced and detailed as a film but in a way that it fuses with a fully breathable interactive world that you control the pace of. To me, this is one of the first, best results of Star Citizen’s crowd funding: the ability for the development team to live our passion rather than to conform to a publisher’s schedule or bullet points. So let me start by thanking every single backer for making this possible. You’ve allowed me and the team to do some outstanding work. I am thrilled to be here.

Now, though, I need to step away from the Squadron 42 shoot to address something that is on everyone’s minds. We initially planned to release the FPS module, which we are calling Star Marine, shortly afterPAX East in April. We demonstrated a build of the module at the backer event that ran fairly well. It lacked some polish (especially with animations) and still had several technical blockers that prevented a wide scale rollout…but we felt confident enough in the work to say that it would be available for everyone soon. Unfortunately that didn’t happen. Just over two months on, we are continuing to tackle technical and gameplay-related issues. I know that there are two questions above all others that you need answered, and I will now do my best to address them.

What issues are the FPS team facing?

The tl;dr is that we feel the current build doesn’t feel like it lives up to the standards we’ve want to achieve with Star Citizen. There are several issues that will need additional time in order to deliver the first iteration of the gameplay we want you to experience. The challenges facing the FPS launch are a mix of technical blockers and gameplay issues. The most significant technical hurdle faced today is the networking backend. After attempting to work with the legacy code, we decided that we needed to drop some of the legacy technology. That meant developing what we’re calling a Generic Instance Manager (GIM) and rewriting both the Matchmaker and (for the larger project) the game Launcher from scratch. Those efforts are all going well, but they’ve all taken additional time for our engineers.

Going into further detail on the technical side of these systems, one of our big hurdles was, as noted, the creation of the GIM. This new system will be responsible for all the game servers that make up Star Citizen, and we’ve built it to have far more direct control over the internal state and operation of each game server than was available before. The GIM not only manages Arena Commander and Star Marine instances, but also provides a solid framework for instanced multi-player Hangars as well as the instanced Universe game servers that will form the persistent universe. The GIM allocates and recycles game servers at a much faster rate and in a more reliable way than before, helping to get player sinto the action more quickly and keeping them in their games with less incident. The development of this system, which has been ongoing for some time, has been a group effort involving engineers from around the company. Once it’s integrated, it will not only improve the Star Marine experience but also chart the ‘behind the screens’ course for Star Citizen’s future. We’re looking forward to testing it in action internally next week!

The new GIM isn’t the only ‘home grown’ system we’ve come to need for Star Marine. A second challenge has been the need to rewrite the game’s Matchmaking system from scratch, taking an entirely different approach to the process that will eliminate long waits during the Match search process. Situations that use to result in “Match Not Found” no longer exist and every player/group is guaranteed a match in a match and in shorter time than they have seen before. The Matchmaker now keeps friends together such that players in a public group will always be matched to the same team as expected. I’m happy to report that, as of this week, the new matchmaking software has been integrated and is undergoing testing.

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

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

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

These new systems and processes were initiated to replace very serious limitations in what had come before. We’re taking additional time to develop them properly and will in order to get them right we will ultimately need more for proper integration (testing, bug triage and the like.) But we’re already seeing a great improvement: the new system is far more reliable and handles more concurrent players due to improved networking protocol and a streamlined back-end service architecture. In short, doing it ourselves makes for a better game today and sets the stage for even bigger things to come!

On the gameplay side, we are dedicated to making sure the game represents what we want for first person action in the Star Citizen world. This is where things are a little less technical and more about the ‘feel’ of the experience. One of the biggest issues on this front is getting the visuals right. If you read our last design post on the FPS, you will remember that one of the ways we want this experience to stand apart is that we aren’t ‘faking’ animations: anything your character does in the first person needs to look correct when viewed in the third person by another player without duplicate ‘fake’ animations that look different to each person. Making this look right is something that’s taking more R&D time than we had anticipated. It’s a challenge that we will meet…but it’s going to require careful work. We’ve tapped the new Frankfurt studio, which is staffed by Crytek veterans who know every in and out of the engine and some key ex-Crytek leads from LA and Austin to help the team in Denver make this work.

As we continue to tackle these challenges, the FPS team is continuing to improve other areas beyond the initial spec. New characters and weapons and so on, already scheduled, are being developed while newly recorded mocap animations are going in on a regular basis…and other resources are working on more subtle map changes. For instance, artists have been conducting additional lighting and detail passes on the Gold Horizon map with an eye towards quick silhouette reads and making it easier to understand where you are in the level at any time. These kinds of passes aren’t as sexy as building a new spaceship or firing a new weapon…but they’re essential to providing the kind of detail and gameplay we want out of Star Marine.

Arena Commander, for instance, “shipped” with what we thought would be a very early version of the control system, and we’ve certainly heard no end of the debate since! Like it or not, we know that with Star Marine we need to release a build that at the very least shows people where we want to go and not just what we were able to do before a clock ran out.

What do the FPS issues mean for the status of the rest of the project?

Star Citizen’s development is distributed across several different modules or sub-projects, with development happening on all of them simultaneously. By the numbers, only 15% of the team has been working on Star Marine; it’s just been the major focus because it was the next public release. This means that development of other areas, such as Squadron 42, multicrew and the persistent universe, have continued while issues with FPS have stalled development there (though even in that case, development continues in other areas: while network engineers battle back end code, weapons artists and level designers continue to work towards future FPS milestones).

I don’t want to say that there is no impact: integrating the FPSproperly will help move every part of Star Citizen forward, as the tech will help form the blood and sinews of the whole game…but I can’t stress enough that two additional months spent on Star Marine are not the same thing as two months of a delay for Star Citizen. The persistent universe team in Austin is still building brilliant new worlds, the ship team in Santa Monica is coming up with great concepts and integrating existing ships in preparation for future Arena Commander updates…and of course the Squadron 42 team in the UK is full speed ahead on the single player adventure. The biggest issue we have faced is that all the recent Arena Commander work, including new flyable ships has been done on the Star Marine branch of the game’s build. We expected to have 1.2 launched and wanted to take advantage of the great new tech Star Marine’s integration provides.

What’s next?

To that end, we are going to investigate releasing a build with Star Marine disabled that would allow you to experience some of the changes and updates we’ve made over the last few months to the core code base. There are some technical challenges in doing this, and it won’t happen overnight…but I feel that it’s incredibly important to do because we need to test with the public, we need to collect your feedback and frankly we need to continue proving that we’re working on what you care about.

When will we see Star Marine? Tonight, I don’t have an absolute answer for you. What I will tell you is that we know exactly what we have to do, and we’re already well on our way to doing it. With allocation of additional resources and increased cross-studio focus on the FPS portion of the game we are on our way… we’re just not there quite yet. I’m confident that with the significant updates and changes to the backend architecture discussed above that we will have an experience worthy of the Star Citizen name; it’s just going to take some additional integration and testing. On the public side, I know that it’s time to open up our communications on the Star Marine rollout process: starting with this message and continuing each week, we will provide a high level update on the challenges just as we did for Arena Commander.

We ended the 2012 pledge campaign with ‘The Pledge,’ in which I outlined our new company’s goals to be open about our process. Today, I want to rededicate ourselves to this: I can’t promise you we’ll meet every internal deadline or that every decision we make is something you’ll agree with. There will be challenges that we struggle to overcome, and we will never be able to predict all of these with certainty…but I can promise you we will keep you informed and that we will not stop working until the game is done right. After all, that’s why we’re here in the first place. Your support is letting us create the game we want to make before anything else. Because of you, we have the freedom to make sure things work the way we want, even if it takes more time and more effort. We won’t let you down!

- Chris Roberts

 
 
 
 
 
 
 

END TRANSMISSION

Link to comment
Share on other sites

I must to say ,this Gold Forizon station is awesome I can imagine so many flashbangs and speeled  blood all over the wals but  one thing will make many players even more angry than a drunk player who constantly trows flashbangs and that is trolls who will mess around whit gravity generator ,swiching him on and off constantly.

In my book of fer-play rules that type of trollism shall be gladly panished by shooting the troll betwin his eyes whit my blaster, simple as that.

 

Link to comment
Share on other sites

Star Marine Status Update

STAR MARINE STATUS UPDATE

 
 
Illfonic-5.jpg
 
 
 
 

Greetings Citizens,

Illfonic-6.jpgIllfonic-7.jpgIllfonic-8.jpgIllfonic-9.jpgIllfonic-10.jpgFPSLevelUpdate.jpg

Greetings Citizens,

Last week, Chris Roberts updated you on the status of the Star Marine module. As part of our promise, we will be issuing weekly reports on our progress until the PTU release. This week, we’re updating you on the engineering tasks Chris outlined in his letter; as we approach release, we’ll provide specifics about the blockers QA discovers.

Game Design

The last week has been a concerted effort amongst production staff to make sure we have all of the feedback from our internal playtests and design directors addressed. Jason Hutchins from CIG-ATX is spearheading the production on the Star Marin module since Travis Day has moved on. He was in L.A. last week to sync with Travis and the production staff in LA and is now in Denver this week coordinating with our partners at Illfonic and the other CIG studios world-wide. There are a lot of little details, and some major systems that needed to be tracked. Tracking is now in place for the large majority of work that is left to be done prior to release.

On the game design front, we have a technical designer in the UK, John Crewe, helping us change weapon and armor stats across the game. Armor values will be tweaked to make the differences between armor feel meaningful while changing weapon values in areas such as damage, perceived weapon rise from recoil, rates of fire, reloading, among others.

We are making other changes as well, in order to improve the player experience. Making it easier to understand your injury and bleeding states, as well as figuring out whether or not you are taking enemy fire and if your shots are hitting their targets. This hits all of the game disciplines, art, audio, coding, and game design.

Playtesting and Game Modes

Our primary focus is on the Team Elimination game mode. This is a great testing bed for us to use as a proving ground for player locomotion animations, weapon balance and feel, and the way we interact with different materials in the environments.

We have implemented a way to easily toggle how many players are required to start a match, and also made a new game type called Practice mode which doesn’t keeps score and doesn’t have a best of 7 round counter on is. This is very similar to Free Fly mode in Arena Commander and will allow for more practice opportunity and faster iteration.

Thursday’s internal playtest showed great improvement, even though we still have a long way to go. The comments were that the game felt fun for the first time in months. We still have a lot of tuning to get it to the place we want, technical issues to fix, bugs to smash, and action to polish but we see the light at the end of the tunnel. Hopefully that light isn’t a round from an enemy Mass Driver.

Environments

One of the big issues we found in our internal playtests is that it is easy to get lost in the Gold Horizon level. As a result, one of the things we did this week was create a Beautiful Corner using our game assets to see how these colored areas and iconography / signage will help to give the player a better idea of where they will be in the level and have reference points for communication. We’re implementing a simple in-game chat system for the FPS level for team communication as well. In the future we will make that system more robust, faster, and eventually integrate voice-comms as well.

Audio

For an upcoming release we are switching from an audio system,FMOD, to a new system called WWise. This has required a lot of work to re-enable sounds in flowgraph. Next up we’ll be working on better audio callouts for taking fire, injury states, hit indictors and additional ambient audio and some music between game rounds. WWise should also allow for some much improved spatial sounds effects that bring the environments to life from an audio perspective.

Animation

Sean Tracy, the CryEngine Tech Director from CIG-ATX, and Steve Bender from CIG-LA have been working closely with the animators and engineers at Illfonic this week to nail down the workflow on the base locomotion set. The project has been haunted by bugs in the movement code and in assets that require some thorough and precise debugging. That has gone well, and we saw significant improvements in the base locomotion sets, turns, jukes, strafes, and stop/starts in Thursday’s internal playtest. We still have a lot to do though, as we work through ADS, kneeling, weapon, grenade and gadget sets over the next couple of weeks.

UI

New helmet HUDs are coming along nicely, with integrated radar, health, ammo and weapon indicator iconography, along with integrated chat. These are custom for each armor type, so we’ll have 6 new HUDs going into internal playtests next week.

 
 
 
 
 
 
 

END TRANSMISSION

Below are images from the June Monthly report

Illfonic-1.jpgIllfonic-2.jpgIllfonic-3.jpgIllfonic-4.jpg

Edited by VoA
Link to comment
Share on other sites

FPS control scheme in Settings... from the last patch? Great, it's coming!!!

Hc1VsNm.jpg

 
 
 
JCrewe
 
 
 
 

Developer

Developer.png
icon-subscriber.png
icon-none.png
 
 
 
 
 
  
 
 
Posted: 3:24AM
 
 
 

Dear FPS devs, in the monthly report for June I found the following entry:

Could you please elaborate on how this can be realized on a keyboard, which is the main input device for most FPS players and does not feature any analogue inputs?
Obviously without the analogue inputs you don't get quite as much granular control but you still have five distinct movement speeds or "brackets".

Sprint
Lowered & Moving = Run Fast
Ready & Moving = Run Slow
ADS & Moving = Walk Fast
Walk/Crouch/Prone

So whilst you can't do the small blends with stick deflection, you still have multiple movement speed options each with their pros/cons.





 
John Crewe - Lead Technical Designer - Foundry 42
 
  •  
  •  
     
    JCrewe
     
     
     
     

    Developer

    Developer.png
    icon-subscriber.png
    icon-none.png
     
     
     
     
     
      
     
     
    Posted: 4:02AM
     
     
     


    So, just to clarify - the first 'speeds' listed above (sprint, lowered & moving, ready & moving, etc) are the five movement speeds available on the gamepad - it's just that instead of manually toggling the ready status, sprint, or walk/crouch/prone elements (as you would on the keyboard), it's done by the degree of deflection on the stick....

    So (in reverse order to the above list):
    *) a small deflection would be walking, 
    *) deflect more = walk fast, 
    *) deflect even further = drop out of ADS into ready, 
    *) almost full deflection = drop out of ready into lowered, and 
    *) full deflection = sprint?

    Is this correct?

    If so, will it be possible to disable some of these options (e.g. disable full deflect = sprint, and instead use a button / trigger to toggle sprint as required), etc?

    You still toggle the states on the pad, but you have the ability to do some inbetween movement speeds based on the deflection of the stick. Say the 5 states are the equivalent of 1,2,3,4,5, you'd be able to stay at 3.5 with half stick deflection when ready+moving but the actual realworld speed difference is not enough to make it worthwhile just staying at that stick deflection level, you'd just go full tilt up to the limit or swap to the appropriate state.

    If you need to do fine movement (i.e. slowly poking round a corner) you can use small amounts of stick deflection or on a keyboard you'd tap. With the momentum/jukes we have you have a small period of momentum buildup anyway which gives you that grace period of acceleration to allow small changes.

    Hope that helps?
    John Crewe - Lead Technical Designer - Foundry 42
     
     
     
  •  
     
     
    JCrewe
     
     
     
     

    Developer

    Developer.png
    icon-subscriber.png
    icon-none.png
     
     
     
     
     
      
     
     
    Posted: 4:06AM
     
     
     



    This may seem a bit different but has any consideration been given to allowing HOTAS controls to move the Avatar in FPS mode? Perhaps a setup where Throttle is for forward and backwards movement with the joystick used for turning left / right and looking up / down with left and right twist being used for strafing. 

    Although mouse and keyboard is acclaimed the most accurate for FPS there are times when a smooth transition from ship flight to first person movement would be preferred over accuracy. For example if my ship is falling apart and I need to get to a escape pod I'd rather be able to switch to first person mode and start running rather than trying to fumble around looking for my game pad or moving the HOTAS out of the way so I could use my mouse and keyboard. I imagine it'd also make life easier for those building dedicated sim pits. 
     

    This is not something we've spent a lot of time on yet but we would look to support this better down the line because as you say, in certain situations it may be easier to do this for certain players. You should be able to map your HOTAS to the functions needed in the initial FPS release but it may not be the greatest experience to start with and something we'd iterate on.
     
    John Crewe - Lead Technical Designer - Foundry 42
     
Link to comment
Share on other sites

Star Marine Status Update

STAR MARINE STATUS UPDATE

 
 
StarMarine-Art_v1.jpg
 
 
 
 

Greetings Citizens,

Ghost SightGhost SightHolo SightHolo SightOpen SightOpen SightRed Dot Sight 1Red Dot Sight 1Red Dot Sight 2Red Dot Sight 2

Greetings Citizens,

Jason Hutchins, Senior Producer at Cloud Imperium Games Austin reporting from Illfonic. While Sean Tracy headed to sunny Wilmslow for a character summit and then over to meet with the guys at Foundry 42’s new Frankfurt studio, Steve Bender and I have remained in Denver to assist with the Star Marine process. Our overall goal is to keep the focus on our core gameplay systems and character locomotion.

Here is what progress we made as a group this week:

  • An Internal playtest using a new version of the launcher across all of our studios. The new launcher successfully patched itself and the game client, and did it about 3 times faster than older launcher.
  • The internal playtest was also our first run through on the freshly-developed Generic Instance Manager (see Chris Roberts’ latest letter for details on this tech.)
  • There has been a cross discipline effort between animators, engineers, and technical artists, and tools specialists to resolve character locomotion animation issues. One thing to keep in mind is that while we are using CryEngine, what we are doing is not a simple reskin of a game like Crysis 3. There are fundamental differences between Star Citizen and other traditional shooters in the way we keep our 1st person and 3rd person models and camera in sync. Going into why we are in this state is a much longer topic for another day.
  • The complete juke/start/stop set for the Run animation is complete as of today. We are still seeing a slight pop in some quick transitions but it is a significant improvement!
  • The popping we saw in Turns has been resolved, and we look forward to seeing that in our internal test next week.
  • The cover system, which was removed from the build for a review, is now back in and working. It needs tuning and some bug fixing still, but the base functionality is there. When you get near an object that will provide cover, you’ll go into a cover mode. You can strafe or move out of cover to fire, or lean out of cover to fire.
  • Prone animations are much improved and we are looking at a version that has your weapon visible to you while in first person. This will continue next week.
  • We examined some new concepts for weapon sight components on the ATT-4 Laser Rifle. These are modular components and will eventually be integrated into the game for other weapons, too. We want weapons to be as customizable as the ships in future Star Citizen modules, so variety is the order of the day when looking at these kinds of assets. For the short term, we are going to pick one of these to add to the standard load-out on the ATT-4. Which one would you like to see as standard? I’m partial to the ghost sight for close encounters, but that may be just because it reminds me of what I use on my trusty [redacted] 590-A1 shotgun.
  • We have re-integrated a crosshair reticle into the HUD. This is not a traditional eye’s front cross hair, it is more like a visible laser “red dot” aim system that points where your muzzle is pointing. In previous builds, we had disabled this because of weapon animation issues and because QA was using the crosshair exclusively to hip fire their weapons while on the move. We made the decision to bring it back thanks to improvements to the weapons animations. We will deal with the run & gun gameplay using other designer-tunable methods. John Crewe at Foundry 42 has several knobs and dials he can use to tune these values until they feel right to us. Then when we get it into your hands we’ll listen for your feedback and be able to respond.
  • The VFX and Tech Art teams did a performance pass on the Gold Horizon level last week that informed a bunch of optimization work that we were able to integrate this week. Below you can find a video that showcases some VFX in the level that look great and are much less costly to client performance.
  • We have code support to deploy gadgets and grenades working again, and in a consistent manner.
  • We’ve even added some additional art resources, created in the past few weeks. New Proline Grenade models by Behring, have been added and new HUD icons for weapons, grenades and gadgets are in.
  • The teams across the pond are essential, too! Players can now heal themselves or stop bleeding out by using a Medpen gadget from the Foundry 42 team. BHVR mocked up the UI hints for it, which we’ll hook up next week for the playtest.
  • The new Free Play Practice mode (essentially a free-for-all mode on the Gold Horizon map) is all hooked up through the Lobby UI and will be featured in our internal playtest next week. We knew that this ‘free fight’ mode was a big request for the community, so we wanted to make sure it was added.

Here are our current blockers:

  • Melee attacks aren’t working/animating.There are a couple of animations using the weapons that we need to clean up and properly randomize so players aren’t doing the same attack all the time. It’s a last ditch attack, though, I don’t recommend it. Hopefully you can put a little distance between you and your enemy with these attacks. Sorry, Disco Rambo, no combat knife one shot kills just yet.
  • Ongoing weapon recoil issues: we need to get animation, tools, and code support in a place where designers can effectively tune recoil values; timing, muzzle rise, drift, etc without having to change animation assets.
  • There are still a number of locomotion animations still need to be cleaned up and integrated.
    • Starts/Stops/Jukes for Crouch movement
    • Crouch Locomotion and Idle pass
    • Weapon Select and deselect broken in Standing for all weapons
    • Weapon Select and deselect broken in Crouch for all weapons
    • Weapon Select and deselect broken in Prone for all weapons
    • Hurt/injured Animation Locomotion
    • From healthy to Injured State Animations
    • ADS to Lowered, ADS to Idle, Idle to ADS, Lowered to ADS
    • Jump for Stocked, Pistol- from Standing
    • Jump for Stocked, Pistol- from Crouch
    • New Grenade Throw animation and implementation for Stocked and Pistol in Stand
    • New Grenade Throw animation and implementation for Stocked and Pistol in Crouch
  • Bugs relating to Hit Reactions. Our first person and third animations, being synced, may cause gameplay related issues with getting it. Correcting this will require some additional R&D and tuning to feel good.
  • We are seeing some inconsistencies in the way characters are dying and how they ragdoll.
 
 
 
 
 
 
 
 
 
 
 
 
 
 

STAR MARINE GUN SIGHT POLL

 
 

Which Star Marine Sight Do You Prefer?

 
A
Ghost Sight
 
 
 
 
 
 
B
Holo Sight
 
 
 
 
 
 
 
C
Open Sight
 
 
 
 
 
 
D
Red Dot Sight 1
 
 
 
 
 
 
 
E
Red Dot Sight 2
 
 
 
 
 
 
 
 
 
 
 
 
 
 

END TRANSMISSION

 
 
Link to comment
Share on other sites

Star Marine Update! 

 
 
 
 

STAR MARINE STATUS UPDATE

 
 
StarMarine-Art_v1.jpg
 
 
 
 

Greetings Citizens,

The Winner!The Winner!Fps_shot.jpgFrame000324.jpgFrame000270.jpg

It’s that time again! As we promised, here’s your comprehensive review of what the Star Marine team (and those supporting it in this final push) worked on this past week. We’re going to format this update a little bit differently, more akin to the big Monthly Reports that the team puts together. Please join me as we walk through each of the different disciplines currently working to get Star Marine to thePTU!

Before we begin, we haven’t forgotten last week’s poll! It seems the Ghost Sight is the odds on favorite. The poll wasn’t just for show and we’re going to go with the community’s choice here. As a result, we’ll be integrating it as standard equipment for the ATT-4! If you loved one of the other sights, don’t worry: they’ll return in the future as modular options (and will likely appear as standard on other guns.)

Engineering & Code

We started things off by making a number of netcode improvements in the lead-up to Thursday’s internal company-wide playtest… and using the results of that playtest, we’ve gone on to make several others! A big focus of these changes is making sure that movement transitions are serialized. Issues with passing/clipping through objects have been significantly de creased with a pair of fixes by Paul J. He’s updated the game to use the living entity’s orientation rather than the articulated entity for intersection tests and also fixed a frame behind issue with the living entity’s bounding box calculation. In plain English: no more clipping problems!

We also tested passing data from game servers to our Platform services; that’s the process by which the game talks to the website and your Leaderboard data appears here on RSI. We identified one issue there, with a fix in progress as we speak. And we resolved another pair of outstanding issues: one that caused problems equipping/throwing grenades while holstering a weapon and the other that prevented the personal shield from being destroyed. We’re continuing to investigate a cause for issues with player prediction that are currently resulting in teleporting and hits not syncing up between clients properly. This investigation is ongoing, but we’re very hopeful this bug is about to be smashed.

Player Locomotion/Animations

The player predication and network improvements mentioned above have already had a positive impact on the animation status. Steve Bender, the animation director, has been reviewing and experimenting with Ragdoll effects for death animations. We’ve also been working on the non-cardinal direction walk jukes, the directional jumps in first person and several other specific animation types. Weapon holstering animations are in progress for the ladder mount, walk, run and spring, as are ‘transition’ animations (switching from a pistol to a rifle.) Making sure these look right in both first and third person is a real challenge, but we’re happy to report that it’s coming together.

I mentioned ladder animations, which have been a major focus lately. We’ve been tweaking the l adder animations to change climbing speed and are currently working an issue with ladder mounts and dismounts. They’re working, but they glitch sometimes in multiplayer and don’t synch properly. We’re looking into that, of course! Next, we’ll be using animation resources around the company to focus on updating crouch jukes and issues with our prone animation. We have the process for this down at this point, it’s just a matter of getting the animations to the right people!

Level Design

Our designers continued to look at Gold Horizon from the standpoint of a competitive combatant. This week, that meant tuning Gold Horizon’s player focal points and sight lines to make for a better battle experience. We conducted a performance pass, addressing areas of the level that were causing too many LODs. The result is a better framerate than we’ve seen! We fixed issues with the energy recharge stations and we have redone some of the lighting to improve their breakable functionality. We’d previously set things unbreakable to address a crash and now we’re going back and applying the proper fix to make the levels truly interactive. There are a LOT of lights, so that process will continue into next week, wrapping up just before the next big company-wide internal playtest!

The plan next is to add some additional spawn points to Gold Horizon for the new Free Play (FFA) practice mode suggested by the company. We’ll also be making a material surface pass on the level; certain tracer effects are not being cleaned up when they hit an imporper surface material. Since those tracers can reduce the frame rate when they don’t disperse properly, we need to make sure they do!

Game Design

Designers have been looking at individual game modes this week, discussing how to make Gold Horizon’s Team Elimination mode the slow-paced tactical gameplay we are aiming for. We want it to be a simulation of the rest of the Persistent Universe’s First Person gameplay rather than a throwaway action mode that doesn’t speak to the larger project. We want gameplay where there are consequences for death, so that the player is encouraged to be slow, careful and there’s a reason to help your friends and do your best to overpower, deceive and defeat your enemies. Next we’ll be making some tweaks to the practice mode, adding a round timer to Free Play (and some iteration testing associated therewith.) We will be adding a scoreboard for the ends of matches and testing a small respawn delay with a countdown timer to see how it impacts the overall feel.

Weapons & Gadgets

We’ve got guns! The Devastator Shotgun animations had a pass to add more pop and attitude during reload/fire. We did some exensive work on the two-handed gadget deploy/throw animations, breaking them up into three component parts: weapon deselect, gadget grab and throw and weapon select. These are undergoing review now and are looking good!

Sometimes, though, we make a gun TOO good. The ATT-4, seen last week, is a very satisfying game to use… to the point that we now need to enhance the other weapons to its level (rather than tuning it down, which might happen on an ordinary project.) We’ll be looking at our options there next, and we’ll also be doing a pass on the Laser Snipe rifle’s scope, VFX and charging mode. The feedback from QA is that it needs to feel more satisfying to use.

User Interface/HUD

Icons, icons, icons! New icons are being implemented for guns, grenades and gadgets, with new health icons expected shortly. We’ve finished work on updating the weapon select/ammo counter widget for the new HUD and we’ve begin to integrate a new Message/Chat widget (work should be done on this next.) We’ve been looking at several options for improving the aiming reticule and speeding up the ADS transition. We’ll continue iterating on this. Up next is the health/injury display widget, which needs to be updated to the current standard.

Blockers

We’re going to end off this week with a list of ongoing blockers. These are the issues that are truly preventing Star Marine from going to the PTU… and as such, they’re the ones we’re most eager to tackle!

  • Netcode issues. For the last couple of weeks I have read backer comments that we have been glossing over them. Its true, I was… but only because they’re very difficult to drill down to. What we are seeing in playtests are issues deploying gadgets, firing at targets that aren’t where you expect, and other issues that can look like high latency situations even with a solid connection to the server. Issues like this can and will exacerbate other smaller issues that on their own may not feel like a big problem. The netcode is improving (wait till you see 16-player Arena Commander matches in 1.1.5) but there’s still certainly work left to be done.
  • Jukes and stops need to be tuned. Our aim is less juke at slow speeds, more jukes on high speed strafes, turns, and stops.
  • There is too much weapon sway while in ADS (Aiming Down Sight) mode. We need to tune this such that the only movement comes from player input, some of our immersive animations from breathing, the results of being near cover, getting hit, or transitioning from a juke while moving are too strong.
  • Animations for all weapon types are not done, we’re burning these down; it takes time to clean-up integrate, test, and iterate on the animation to make sure they hit our high standards.
  • The new Visor HUD not quite ready yet (this requires code, art, tech art, animation, UI design, and audio support to get finalized).
  • There is a bug with Radar not drawing properly in ADS
  • Audio cues are not hooked up for all weapons, hit indicators, and UI elements. This will require a dedicated pass.
  • Proper positional audio for footsteps, and weapon fire aren’t being reported correctly to the player.
 
 
 
 
 
 
 
 
 
 
 
 
 

END TRANSMISSION

Link to comment
Share on other sites

Star Marine Status Update - Week of July 19

 
 
 
 
 
 
 
 
 
 

STAR MARINE STATUS UPDATE

 
 
StarMarine-Art_v1.jpg
 
 
 
 

Greetings Citizens,

Sniper_Round_Mid_Air.pngSniper_On_Body.pngShotgun_Window.pngShotgun.pngFlashlight.pngCover.png

As you can tell, we’ve had a very busy day at Cloud Imperium! But the Merlin and Alpha 1.1.5 aren’t our only focus: work continues on the Star Marine FPS mode. This week, we spent a lot of time focused on general gameplay and the animation system. As Chris discussed on 10 for the Chairman, getting the animation matching the vision is one of our biggest challenges… and it’s important because the technology we premiere here is going to be used throughout Squadron 42 and the persistent universe. It may seem like a lot of extra work right now, but it will all be worthwhile down the road when we’re seeing smoothly animated NPCs and players living in the ‘verse.

We’ve broken this week’s updates down into Gameplay, Animation and Art sections, with information on both our progress and the blockers we’re seeing. We’re attaching two videos to the post to show you how it’s really going: an animation and weapons test above (check out those jukes!) and a Gold Horizon walkthrough below. Enjoy!

Gameplay Progress

On the gameplay side, it was a week of fixes and adjustments! Fixes include a bug with the cover idle animation not playing, issues with cover look-poses, a crash when connecting a second client to a local dedicated server, an issue where the game was swapping to the default weapon on client connect, a problem with weapon offsets affectingADS and ADS movement lag that we had been seeing! We addressed a bug that was causing the HUD to report a suicide upon connection, an issue with the weapon reticule not fading correctly and a pair of grenade-related bugs: one where swapping grenade types after a throw wasn’t depleting your inventory and another where your fixed weapon would not be selected after running out of grenades. We also finished work from the previous week on the sniper rifle recharge issues. Whew.

On the adjustment side, we greatly improved fidelity and positioning in multiplayer by adjusting movement transitions on the dedicated server. We reduced feedback loops created during cover stance changes by adjusting cover rays to follow the eyes, and we adjusted spawn points for the new Free Play practice mode. This alone improved the playtest significantly; greatly reduced spawn camping! We improved the process for our designers, as well. By updating math to handle procedural offsets for ADS Y axis camera positioning and by working on procedural offsets for weapons, it will be much easier for designers to adjust relative camera positions using ADS without needing to update or redo animations. There was work done on the recharge station, which does not always activate over the network. And it wouldn’t be game development if we weren’t causing more problems for ourselves once in a while: we managed to break (AND FIX) weapon hand placement while firing.

Gameplay Blockers

  • Working on smoothing out cover transitions and fixing ADSdisconnecting when leaning out of cover, this is ongoing.
  • Working on prediction issues causing client aim to not synchronize, this is ongoing.
  • Adding Objectives to the Gold Horizon level for Team Elimination game type, will fundamentally slow down the gameplay on the level to encourage more of a capture and hold and careful play style.

Animation Progress

Any week where we get to play with machine guns is a good one! Animation finished updates to the Behring P4AR firing animation this week and kicked off work on the Behring ATT-4 AND the prone-firing for the Devastator Shotgun.

But it wasn’t all rifles and SMGs: we also tweaked jump timing, fixed blending issues with the walk slow and assisted engineers with their cover fixes. We made some great progress polishing walk starts/stops/jukes, some of which you can see in the attached video. We locked down our work on crouch turns and starts, and wie will continue working on crouch stops and the prone mode.

As we mentioned last week, Ragdoll death animations weren’t quite up to snuff (whoa, unintentional pun there.) That video got a lot of comments in the forums. It wasn’t merely a distraction, though: the research done while making that video helped point out an issue with our skeleton. What we found was an issue with the way our character’s skeleton joint orientations were set up. So we spent the last two days working on an updated rig with correct joint orientations to satisfy the requirements of CryEngine. Ivo, our animation specialist in Frankfurt, has a new rig in test now to check against the SDK. Then, he’ll check it against the animation code changes we’ve made specifically for Star Citizen and the end result will be a much improved ragdoll!

Animation Blockers

  • Will need a pass to re-target animations on the new character rig.
  • Started working on crouch stops, this is ongoing.
  • Melee animations have not started yet.
  • Injured locomotion animations not finished, multiple states need clarification.
  • EVA style animations for ZeroG not able to be cleaned up and used until we get the new rig. This is needed for ZeroG gameplay on Gold Horizon, let alone SATA Ball.

Art

The art team conducted a lighting pass to improve client performance. This included the re-addition of breakable lights (visible in the screenshots and video.) The re-work of Gold Horizon assets continued, with updates to stair heights and panel textures. (In the case of panel textures, we create two of each: clean and dirty. That will let us build more interesting levels more quickly in the future!) We worked with Cort Soest and Sean Tracy from Austin to reduce LODs and improve framerate issues. That work is ongoing, but it’s already showing positive results.

Art and design have continued to work together to improve the flow of the level. This week we added additional signage to Gold Horizon to ease navigation, and we have also updated floor decaling to this same end. Our weapons team certainly wasn’t idle, either: they finished a revision of the P4AR (including updated decals!) and then exported that work for use in other weapons by the same manufacturer.

Art Blockers

  • Continuing work on Gold Horizon assets so we can use it as a building block set for future releases.
  • Working on 1st person hit reaction HUD mockups, iterating on the look with Chris and the team in the UK. As mentioned previously, this is a big team effort requiring audio, animation, VFX, and HUD UI to make it look and feel right.
 
 
 
 
 
 
 
 
 
 
 
 
 

END TRANSMISSION

 
 
Link to comment
Share on other sites

  • 2 weeks later...

STAR MARINE STATUS UPDATE

Greetings Citizens,

Klaus & Werner Sniper Rifle CleanKlaus & Werner Sniper Rifle CleanKlaus & Werner Sniper Rifle Aged CloseupKlaus & Werner Sniper Rifle Aged CloseupKlaus & Werner Sniper Rifle AgedKlaus & Werner Sniper Rifle AgedKastak Arms DevastatorKastak Arms DevastatorKastak Arms DevastatorKastak Arms DevastatorKastak Arms DevastatorKastak Arms Devastator

Greetings Citizens,

Today we’d like to give you a more in-depth peak behind the curtain at the sometimes dirty and confusing aspects of game development. The week after a major demo like Gamescom is always hectic and fraught with issues. When we make demos like that we lock down development streams so that we can focus on stability and last minute fixes. When we unlock the streams and merge changes back into our development streams… things break, builds break, people break (just kidding about that last one; the Gamescom demo energized us all!)

This week was no exception, and is in fact a little worse for wear because of 3 distinct demo branches from Gamescom, as well as a live release of AC patch 1.1.6. So, most of this week was administrative code clean up and getting things back into shape to make regular builds and regular playtests with the developers. The UK team got one good playtest in this week, so for the most part we were focused on fixing broken things that had been fine the week before.

Moving forward, we have finished the big Gamescom merge this week and are going into next week starting a staging merge in order to get the FPS, PU, and AC modules back into one development stream. We expect that we will be continuing to grapple with these challenges through next week. While these ‘growing pains’ may slow us down, they ultimately will allow us to make faster and better progress in the future.

Todd Papy, the FPS design director from F42 in Frankfurt is at the Illfonic studio this week to work with the designers and engineers on some key gameplay features. Jason Hutchins, the Senior Producer from ATX Austin will be joining Todd at Illfonic next week as well, to work on the upcoming release plans and the changes we want to make to a new game mode we will release on the Gold Horizon map. Expect more info on that next week!

Here’s what we did this week, and what we’ll be working on into next week.

Gameplay

Fixes were the order of the day this week, largely because of issues caused in the merge. Many of these were specific to weapons: grenades not blowing up when you’re killed while cooking them, magazines not re-attaching to weapons after reloading, magazines swapping not appearing visually and an issue with the Arclight (laser pistol) battery display not working when a second client joins (likely because of ongoing network optimization work.) All resolved now! Other fixes included a default weapon selection bug, an issue with prone movement breaking with ADS, a crash when being killed during a reload and an issue with the ragdoll not playing after being killed (players would just stand back up!)

Beyond fixes, we worked on cover tweaks thanks to feedback provided by Todd Papy during his time at the Illfonic office, improving interaction with ammo crates (this had become inconsistent, likely due to the merge) and implementing a v7 loadout for game-dev so animators can test their new re-target work. We also kicked off work on the slide mechanic, now being re-implemented.

There was a good focus on the P4AR, with implementation, testing and tweaking of the selective fire mode (single, burst, auto) happening this week. This included work on the UI display and its respective text. We also added per-stance overrides for weapons positioning and investigated an issue with gadgets that was likely caused by the merge. Cleanup was performed on fall damage, and we generated a graph so that designers can make sense of the formula for future tweaking. The team fixed a bug that was allowing players to switch fire modes while firing, and re-enabled turn-in-place for remote clients. We deprecated a custom hit reaction RMI so that we can enable a different version. This addressed a bug with hit reactions not playing on clients (only on the server) which is now fixed.

Gameplay Blockers:

  • The Audio team in the UK did a LOT of work on the Gamescom demo over the last few months, so are getting back in sync with them to make sure we have support for FPSweapons, HUDs, hit indications, crack-bys, ricochets, other necessary Foley and ambient audio to make the game feel alive and responsive.
  • Network optimization, server stability, and general bug fixing are needed.
  • We’ll be working to integrate some engineers at F42 with the coders at Illfonic over the next weeks to give this the attention it needs.
  • Ladders. While they are more user friendly, there are still edge cases that we are tracking down.

UI Blockers

There isn’t much to report this week, save that several things that we had working last week were broken because of the integration. We’re fixing those up so we can get back to new UI development!

Art

Our artists, who were less impacted by the stream merge, continued their weapons work in earnest. They addressed material changes on the P4AR (pictured last week) and finished updates to the Devastator D12. Last week you saw an image of the D12 that had some glowing goo in the magazine. The goo is gone, and we’ve made some other changes to the art; check it out in this post! We also started making changes to the sniper rifle based on feedback, and you can see the latest version in this post. The environment team at Illfonic is ramping down their work on Gold Horizon for the FPS release; the remaining tasks include exporting props with collision updates and cleaning up scene files for handoff to the Foundry 42 team that will be one of those building future modules for Squadron 42.

Animation

The animation team created some new temporary animations to allow for cover tweaks, necessary this week so we could work with Todd Papy as a proof of concept. These included smaller steps when shifting left, right and back and a step out and hip fire. We changed all weapon pivot points to match up with the right hand parenting and started a magazine check animation for the new reload mechanics (we’re implementing a tactical reload with one in the chamber versus emergency reload of an empty gun.) We conducted a review of the new mocap data and started a fix for vent interaction animations which were having issues.

FPS-Gif.gif

The big news, of course, is that we started retargeting all FPS animations from the v5 rig to the v7 rig, which began this week. This included creating a file for retargeting pistol animations, exporting all CryEngine animation files, re-rigging the microwave cannon for retargeting, retargeting the pistol set (exported and checked in!) and retargeting the stocked set. Back in Austin, Tech Director Sean Tracy and animation lead Bryan Brewer lent a hand with the No Weapons animation set for v7 this week.

The big question is when we will make the company wide switch from the old rig models to the new ones. That will, as I mentioned earlier cause some legacy assets and scenes to break. This is a very good thing, as we’ll be on the new (albeit not thoroughly tested) rig for all modules. We’ve been developing on different rigs for most of this year. This is an exciting switch! Things will break, but we’ll take the hit now and make the fixes so we can move forward.

Animation Blockers

Remember those 3000+ animations we mentioned last week? We are just now starting to burn those down. Retargets are largely finished, now we are on to the NEW stuff on that list. Again, it’s a big task and animators and engineers from all studios are working on it.

Link to comment
Share on other sites

For the god sake, use spoilers. When I load this thread (or other where you made huge posts like that) it'll take ages before the thread stops expanding. You simply can't read anything while it's doing that.

Also: Damn, now I want the FPS module even more! It's making me sad not being able to play it (and probably not being able to play it when it's released...October is a bad time to release it)

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...