@@drewcastalia6372 that was a tough one! I want to go back and see if I can figure it out and check out the other levels too

A lot of it went over my head though haha.

Nope, this just uses a simple node to node path for the minions and essentially random motion for the AI champions. Wanted to keep that part simple to focus on the ECS/Netcode aspects. The Agents Navigation asset on the asset store is a great example of an ECS based system that uses Unity's NavMesh - I have some videos on it if you want to check it out

@@TurboMakesGames oh cool! Thanks for the info! I basically use NavMesh in all of my Unity projects now. It’s probably my favorite thing about Unity. Does it fair pretty well in a networked Netcode for Entities environment? I’m not even sure how you would sync up say the baked NavMesh and the various NavMesh agents for the different players / clients.

Thank you so much for the support 😀

If anyone has the same problem: "Negative network delta time will skip updating the system group." Fixed in Netcode for Entities [1.3.0-exp.1] - 2024-06-11

It is lol - my host migrated my site, so I just updated DNS. Should be back up soon(TM)

Cool - glad to hear that repetition was helpful! Nice work on completing the tutorial 👍

Definitely would like to do a jam like that in the future!

This will work with Unity 6 100%! Newer versions of ECS have even been more stable lately and they work on both 2022 LTS and 6

@@TurboMakesGames Awesome thanks. It definitely seems ECS support is only getting better with time!

Mind sending an example snippet that breaks. (I recall having made tests that ensured it works for IJobEntity and System generators)

@@danielkandersen6599 I removed #regions from my whole Unity package but I will try to recreate the problem for ya. It's possible it got fixed in the meantime but I never heard mention of it. So I will let ya know what happens. But from what I remember it seemed like it would break from simply having #region <using directives here> #endregion and then try to write an IAspect or IJobEntity, possibly worse if you have multiple definitions in a .cs file.

​@@GameDevNerd wouldn't be surprised if IAspect still fails, but hopefully IJobEntity doesn't. So if you find it I'll be on the case :)

Two bugs were found with your FinalProject. 1st: When I set the minPlayersToStart to 2, the game will start correctly once the 2nd player joins. However, the 3rd player will be frozen with the game start UI "Waiting for -1 more to join...". And the TeamPlayerCounter component for all clients has 0 for both BlueTeamPlayer and the RedTeamPlayer. (But the 3rd player won't have this problem if he joins before GameStartTick) 2nd: Only happens if the host is a build not the editor. If there are more than one player. The host's abilities UI for Q and W will not be on cooldown correctly. Also, the host's abilities cooldown UI will be on cooldown if the 2nd or 3rd player casts a spell. This only affects the UIs, the internal cooldown is correct for the host or clients. Another bug is, the "var skillShotAbility = ecb.Instantiate(skillShot.AbilityPrefab);" will be excuted on both the client and the host if the client casted a SkillShot. Similiar with the 2nd issue.

Solution for the 1st bug: In the "ServerProcessGameEntryRequestSystem", change "if (playerRemainingToStart <= 0 && !SystemAPI.HasSingleton<GamePlayingTag>()){ }" to "if (playerRemainingToStart <= 0) { if (!SystemAPI.HasSingleton<GamePlayingTag>()) { // If enough players joined and the game hasnt started before. var simulationTickRate = NetCodeConfig.Global.ClientServerTickRate.SimulationTickRate; var tickUntilStart = (uint)(simulationTickRate * gameStartProperties.CountdownTime); var gameStartTick = SystemAPI.GetSingleton<NetworkTime>().ServerTick; gameStartTick.Add(tickUntilStart); ecb.AddComponent(gameStartRpc, new GameStartTickRpc { NetworkTick = gameStartTick }); var gameStartEntity = ecb.CreateEntity(); ecb.AddComponent(gameStartEntity, new GameStartTick { NetworkTick = gameStartTick }); } else { // The client joined after game started. ecb.AddComponent(gameStartRpc, new ClientJoinedAfterGameStartedRpc { }); } }" . Add "public struct ClientJoinedAfterGameStartedRpc : IRpcCommand { }" somewhere. In the "CountdownToStartGameSystem", add the if statement like "if (!SystemAPI.HasSingleton<GamePlayingTag>()) { var gamePlayingEntity = ecb.CreateEntity(); ecb.SetName(gamePlayingEntity, "GamePlayingEntity"); ecb.AddComponent(gamePlayingEntity, new GamePlayingTag()); } ecb.DestroyEntity(entity); OnCountdownEnd?.Invoke();". Otherwise, there will be more than one GamePlayingTag if a new client joins the game while on countdown. Also, add "foreach(var (clientTag, entity) in SystemAPI.Query<ClientJoinedAfterGameStartedRpc>().WithAll<Simulate>().WithEntityAccess()) { var gamePlayingEntity = ecb.CreateEntity(); ecb.SetName(gamePlayingEntity, "GamePlayingEntity"); ecb.AddComponent(gamePlayingEntity, new GamePlayingTag()); ecb.DestroyEntity(entity); OnCountdownEnd?.Invoke(); }" just after the exsiting foreach loop. The last thing is add "_beginGamePanel.SetActive(false);" inside "GameStartUIController.EndCountdown()" because we skipped the countdown.

Solution for the 2nd bug: In "AbilityCooldownUISystem.OnUpdate()", add "WithAll<GhostOwnerIsLocal>()" at the end of the first foreach query. Solution for the 3rd bug: In "BeginSkillShotSystem.OnUpdate()", find the 2nd foreach loop which instantiate the skillShot entity. Add "GhostOwnerIsLocal" inside the "WithAll<>".

Thank you so much! ECS certainly benefits the game types you discussed, but that is far from an exhaustive list. ECS can also work very well for smaller games with dynamic entity structures

"add a "state.RequireForUpdate<MobaPrefabs>()" in the "ClientRequestGameEntrySystem" " saved me. This issue didn't bother me till I started testing the MaxPlayersPerTeam. It's like the player has been connected and counted as a +1 for the selected team, then disconnected for a reason (I dont know the reason exactly).

Thank you so much for the support and confirmation this is working on the latest version 😀

Make sure in the ThinClientEntrySystem you are adding an AbilityInput component and an InputBufferData<AbilityInput>> buffer to the thinClientDummy. That *should* be all that is required for thin client ability input. Hope this helps get it working!

@@TurboMakesGames I had those, turns out in my ThinClientInputSystem if I don't create a new AbilityInput component before the input timer expires, the next frame the inputevent was still "Set", oddly though this would mean that every frame "WasPressedThisFrame" was true, but yet when inspecting the InputBuffer in the inspector it was not and my system that queries the InputData was not seeing it. The aspect that returned ShouldAttack was always true as well which was confusing. Anyways, figured it out, thanks for the help.