FPS Sample 0.3.0 now available

Noticed Unity put a new update on github. Changelog here:

[0.3.0] - NEXT NEXT NEXT NEXT

• UNITY_DISABLE_AUTOMATIC_SYSTEM_BOOTSTRAP no longer set in project settings. This means ECS systems automatically starts and runs in edit mode (Unless [DisableAutoCreation] attribute is set, which it is for most of our game systems)
• HitCollision no longer uses Unity collision system for queries against moving colliders. For lag compensation server needs to do queries using different historical data and moving Unity physics colliders multiple times per frame is very inefficient. Now queries are handled using custom collision primitives and burst jobs. The structure of the collider and history data is still WIP.
• Unified how ECS components are serialized. Serialized components should now implement either IReplicatedComponent, IPredictedComponent or IInterpolatedComponent and will automatically be serialized appropriately (if attached to entity with replicatedentity component). IMPORTANT: It is currently also required to define a static methods CreateSerializerFactory that returns a serializer factory for the component type. This is something we are working on getting rid of.
• Removed support for replicated monobehavior. All serialization is now performed by ECS component.
• Config var debugmove 2 now also makes character shoot secondary weapon
• UserCommand buttons now uses single int property together with enum to defined pressed buttons.
• Removed sprint button from UserCommand. This is now handled by button Ability1.
• Removed DebugPrimitive module from project. Not used and needed cleanup.
• Added VFXSystem that manages VFX assets. Currently has interface for starting spatial and hitscan effects.
• SpatialEffect and HitscanEffect now uses VFX system. Pools of effect prefabs are no longer created as effects can be triggered without gameobject instantiation (Yay!)
• SpatialEffect and HitscanEffect registries removed.
• Character properties that should be replicated to all clients have been moved to to new ECS component CharacterRepAll
• Replicated MonoBehavior components converted to ECS components. Including GameEntityType, ReplicatedEntity, RagdollState, SpectatorCam, DamageHistory, HealthState, UserCommand, HitCollisionOwner , TeleporterPresentation, Moveable.
• GameMode, PlayerState and CapturePoint are now replicated through an ECS component (they need to stay MonoBehavior as they contain strings properties and we don’t have good solution for storing strings on data components atm)
• All abilities now have a request phase that is executed before movement update. This allows for multiple different movement abilities (before Ability_Movement was always active)
• Renamed DefaultBehaviorController to AbilityCollection. AbilityCollection now has a general way to handle all abilities (before there where hardcoded handling of e.g. movement and death). All abilities are registered in one list and what abilities are active are determined by their requests (acquired in the request phase) and rules for what other abilities an ability can run together with and what it can interrupt (This is setup on AbilityCollection)
• Setup of buttons that should trigger an ability is now setup on each individual ability scriptable object.
• Item registry removed (Items are not currently being replicated - they will probably be when weapon switching is implemented. All abilities are owned and replicated by AbilityCollection)
• Added new module called Presentation. This is responsible for creating and attaching presentation geometry and logic to replicated entities. Entities can have different presentation depending on platform (e.g. Server, Client) and other properties. Only grenades use this atm.
• Grenades are now replicated as pure ECS entity. Client presentation handled by Presentation module.
• Fixed error spam from BuildWindow after deleting scene. Build window now regenerates level list when it finds invalid level info.
• Registries are now automatically generated before bundled are build (Manual generation can be triggered from FPS Sample->Registries->Prepare Registries). Manual fix-up of registries no longer needed after deleting registered objects.
• ReplicatedEntityFactories are now stored in bundles. The goal is to generalize creation of entities (from prefabs or ReplicatedEntityFactory). Note: ReplicatedEntityFactory is currently used to create pure entities, but a prefab like workflow might be used in the future.
• WeakAssetReference are now blitable (struct and guid saved as ints) and can be stored on pure ECS components.

 

Great catch! I hope Unity/Peter is planning to come in here and update us

Hope 3.0 is supported on 2019b... ?

 

It's still 2018.3. They updated to HDRP 4.6 and Visual Effect Graph 4.8 though. Now everything uses shader graphs and visual effects graphs, including the previously demanding furnace (which is now vfx graph). Also weapons Fov projection is now done on shader graph.

 

Thanks Rizu! Sadly, you are correct.

Wonder why, when 2019 is in beta.Would sure love Terrains to correctly save seems, and a GPU powered editor...

:>

 

The instructions (on GitHub) say use Unity 2018.3.0b12, but when you go to open it it requires 2018.3.0f2 (which is the official 2018.3.0 official release). Someone want to update that?

 

I think we are just faster than the Unity team right now, Hopefully they will update the docs and release some tutorials to follow this

 

I had older FPS Sample ported to 2019.1 before, will see if I'll find time to port 0.3.0 as well. Changes on SRP side are now minimal so that's definitely easier now but HDRP 5.3+ use different post processing so that will bring it's own challenges for the projects setup.

 

That would be amazing,I am going to try and do it as well. But you sound to definitely have a better handle on it, so I would love to hear what you find

Cheers
Micah

 

I find the number of errors I get when trying to do anything pretty distrubing. Like attempting to do just rebuild the bundles (nothing new, just pressing the All [force] button)... it takes bleeping forever, and then I end up with:



I don't think this an issue with the project so much as an issue with the creeping instability of Unity when exposed to projects of real-world complexity. And, to be fair, this project is far from a even that in so far as a viable commercial product is concerned.

 

@nsxdavid i have found the way to find stability with Unity as they aggressively push the edge for us. is to always match version exactly. I see you are on top of the readme.md update request. Did you open it with 2018.3.0f2 or some other version.

[edit] also on that readme, there are a few shader mentions did you happen to catch all those as expected behavior? With these HDRP shaders they are trying to push the system to the theoretical max and that is why we see the blow out errors. My understanding is that they will compile ok after a long time but editor preview we see these errors/warnings with the trade off being fast compilation time.

I can say esp. when using preview packages, the expectation is preview behavior. It has been frustrating learning this, but I have found if I keep a drive full of Unity versions and always first open something with the specified version. I could almost say I never get any serious errors. So for UX I suggest this approach. I chalk it up to the cost of finding the edge. My beef is in this should just be stated somewhere as the MO, because I agree as users we expect small version changes shouldn't impact stuff. But at the speed we are moving now, this is no longer the case and is amplified with preview packages as well.

 

@CommunityUS
But that is the correct version to open it with. That's the one Unity says the project (as acquired via github) was last saved with.

I know things are at the edge, but that's what I'm talking about. My real point is that I love the fact they are dogfooding here, because they can now see these things more clearly. We spend a lot of time at the edge with our projects too, and it can be rather painful. Unfortunately the vast majority of users are really not delivering commercial studio titles, and so just from a "how many people experience this" standpoint, may of these issues don't rise to the top. Which is why I told them that the whole "vote for bugs you want fixed" thing was complete bubkis.

 

I agree. Wasn't sure if you needed help or how experienced you were. I have seen you pop up elsewhere now that I have looked around the forum. So yup, if that is what the intent was I agree. I also think they learned a lot during Adam series and trying to use timeline in production, they basically built it according to Oats studio feedback. I get the same sense that they have learned to change their approach in their dev model. The more open source they get like this fps sample project and the more studios the align with to get meaningful feedback from production the better. And of course still innovate the things we don't know we want yet.

 

But, how much do they listen to us? I mean, we still don't have a post about 3.0 being released.

This is the fps sample forum right? :/

 

TLDR - approach it as a vertical slice of a full production [1]

I try to approach it like this, Unity has just had a lot going on internally: SpatialOS + Improbable issues directly about FPSSample/new multiplayer, and Unity updating ToS commitment to being an open (liberty/freedom) platform. I personally feel Joachim Ante is the secret sauce for us devs. I know unity like any company has to find ways to turn a profit and a lot of the stuff they have rolled out for us that is cloud based is a grab at that. I try keep these bigger things in mind, and then I reflect back at all of Unity's source offerings whether it be back when the Asset Store first started to today's partial offerings on GitHub and then still more exclusively on blog posts, or in learn etc.

Unity's assets and I think of FPSSample as a type of asset/template/project basically Unity's take on offering something like Unreal Tournament / Cry / Source SDK but the Unity way and perhaps a more modern way with even kids in mind. But unity's asset release have often had between 1-3 stars never 5 till recently. I think a lot of that is because they a dev focused. Even with the Blacksmith stuff a lot of those solutions I then found stripped out and repackaged into Asset Store offerings while Unity did the innovation. So for me, I see Unity as doing the job of keeping their eye on trends and looking at bug reports. Maybe a few times a month they will scan these forums for gripes but here this is our opportunity to do something with the project and ignite what it can do ourselves and I think that is what they want. If we see them heavy handed in the forums we won't rise up and make it our own.

So with that line of thinking in one hand, in the other hand I think back to a video where I saw Gabe Newell talk about Source and the mod/workshop community. He said something akin to and this was before DOTA 2 took off if I have my dates right, but basically spoke about how getting involved in steam and valve source offerings (it's not source code spoiler for those that don't know the misnomer of the sdk esp. source 2 I mean we have half-life...blah I digress) but Gabe described the feeling he anticipated devs having while on the path as being a feeling a little bit like an RPG game.

So with above in both hands I then lastly assume they don't want to make anything too easy on us, because economics. It should be hard so we can make products that have value because they were hard to come by. With this in mind I personally see the day of the solo studio either changing or disappearing. Happy to chat more on that in PM or start a topic etc. not wanting to steer the thread astray.

[1]Ref: https://forum.unity.com/threads/tho...le-project-feedback-on-content-design.574549/

 

Great Post @CommunityUS

This, helps to put things in perspective.

I look forward to them catching up to the competition, or up to date with multiplayer, depending on your perspective.