Any chance you might update this to use ECS/Job system?

[MostHated]

Hey there,
With the awesome performance that is coming out of ECS/Job system, I was hoping that you guys might consider updating this to take advantage of that. Has any thought been given to that? I would absolutely love to see that!

Thanks,
-MH

[MostHated]

I have been attempting to try and convert this myself, I am having some issues though because of the fact the waypoint itself has a bunch of functionality. I would guess maybe it would be best to perhaps try and move that functionality out elsewhere?

[kkjamie]

Hi there. It's not something we have considered to be honest, as this project has not had a lot of use recently. However we do still aim to maintain it. What functionality are you having troubles with?

…

________________________________ From: MostHated <notifications@github.com> Sent: Sunday, February 17, 2019 2:08:26 AM To: dubit/unity-waypoints Cc: Subscribed Subject: Re: [dubit/unity-waypoints] Any chance you might update this to use ECS/Job system? (#4) I have been attempting to try and convert this myself, I am having some issues though because of the fact the waypoint itself has a bunch of functionality. I would guess maybe it would be best to perhaps try and move that functionality out elsewhere? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#4 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AFWkFjNPWZkGm8xVRwrNmOGTj_GU5Uqnks5vOLmagaJpZM4a84ZN>.

[MostHated]

(Edit - My apologies, I didn't expect or mean for this to get as long as it did. Also, here is an extremely rough first draft of what I was trying to come up with for the actual GetPathSystem. https://hastebin.com/xofilequwo.cpp - I was mostly just trying to get it to a point where there was no error first and foremost. You have to keep in mind I am still trying to learn all the ECS and Job stuff, so don't laugh, lol.)

Primarily what I ran into was that trying to use the actual GetPath in a job requires only structs or value types essentially. The actual Waypoints are a class which then also had a number of other containers and methods inside of it. Lists and Dictionaries cannot be used, so NativeList and NativeHashmap have to be used in their place.

I was thinking that perhaps each waypoint could end up being its own individual entity, but the problem with that seems to be that since the waypoints connections were stored within the waypoint class on each one, attaching those connections is troublesome considering that normally you would define an entities stored values using IComponentData, but that is unable to contain NativeContainers(NativeList or NativeHashMap) as they are not blittable, so I am not able to simply have each waypoint have its connections on it from the start, at least not in the way I was hoping.

I am thinking that maybe using some sort of external list or container that is not attached directly to each waypoint, but instead using some sort of predefined identifier, maybe something as simple as an int field for each one with 001, 002, etc to identify each waypoint, the list of connections could just be passed into the job during the actual path generation so it can reference the connections that are available when needed and then just spit out a list of float3 waypoints in a NativeList which I could then use in the movement system I created.

I just mostly am having trouble figuring out how best to try and break things apart since there are a fairly decent amount of dependencies on multiple classes, such as WaypointConnection, WaypointPath, WaypointPathTracker, etc in order to bring everything together to make it as simple to use as it originally was. Mix the decoupling of those things with the fact that the actual editor functionality and visualizations would not work anymore with the nativelists and things of that nature as they are not serializable, it might take having the actual setup and editor part of things use List and Dictionary, but then at the start of the system it would need to copy over those things into the NativeList and Hasmaps in order to be usable in the jobs. The other thing is a lot of parts use == null or != null, which with structs being value types, they can not be null, so I have been trying to use either Equals or !Equals(float3.zero) for the time being.

The biggest issue with all this is I am just not the most amazing programmer and am getting lost in trying to figure out the best way to go about things, so I might be overcomplicating the hell out of it, lol. I definitely love this system, it works great for my game so far as I was not needing/wanting to use Navmesh, or Agents. I just use it to make some cars move around a town and people to walk around, but in the never-ending pursuit of increased performance, particularly for mobile and VR, as well as "keeping up with the Jones' " in terms of technology and coding, I am trying to learn as much of it as I can to take my game and move as much as I am able over to ECS/Jobs.

I have looked (and trust me, I have really looked) for any other sort of system that is already using ECS/Jobs (particularly the jobs portion, not necessarily so much ECS for this, but it helps), but most all other systems I have come across use A* along with manual or auto-generated grid systems and things of that nature. I am a big fan of this for the one and two-way functionality of essentially straight line pathfinding between predefined waypoints as it works great for my vehicles, and then the two way for the sidewalks and crosswalks for the pedestrians. Any sort of variation or deviation from that I build into the actual movement, it is not necessary in the actual pathfinding and waypoints.

I know that based on the amount of stars this system has it seems like it's not really in use, but I can assure you that I definitely use it, and it is a big part of what makes my game possible. : D It doesn't seem like much yet, but I am still working at it, lol.
https://i.imgur.com/wlMxb8G.gifv
https://www.youtube.com/watch?v=v0fekItapVs

[kkjamie]

Forgive my earlier response as I didn't really have time to think it the problem through.

Making this ECS/Job System compatible would mean a substantial refactor. The system was written in the unity 5 era and so pre-dates those APIs. That doesn't mean it wouldn't be possible. The biggest consideration would be how to keep the compatibility with the non-ecs paradigm, as it's still common place for many unity developers.

One thing we have found when developing systems like this is that you cannot hit every use case for every game. This system is a perfect example, we built it for one project but designed it to be abstract enough for others. When other projects came along we had to make changes to fit the situation.

As far as the specifics go. I have to say you are on the right lines. In ECS/Jobs paradigm a big thing is to treat your data like it lives in a relational database, rather than the typical OOP approach. So each node and connection refer to each other by IDs like you say. In that way we would probably want to split our data from our functionality, and we would be half way to an ECS compatible system. Once it's in that state it's probably just a matter of making IComponentData, and some systems to consume the data. And after it should be next to trivial to jobify.

It's unlikely that we will be actively pursuing these changes, are happy to consider pull requests on your fork though, and are happy to aid you where possible.

Also your game looks rather funny!

[MostHated]

I definitely can understand if you guys were not looking to update it or anything. I guess I was partially hoping that just writing everything out like I did might help me get some ideas on what to do, which I suppose we shall find out if it did. I edited my post several times (too many) and finally added an example of what I was doing with the actual getpath system, but figured I would share a few more things I was doing, if you had any feedback, that would be great! (Keeping in mind everything is a huge cluster right now, lol.)

For the waypoint itself, I figured it might be a good idea to try and just not rely on IComponentData so that I could keep the NativeContainers in them and try to make it more of a hybrid item. I made the WaypointECS a struct for the Job system to use, but then also made WaypointComponent and tried to somewhat intertwine the two so that the needed lists and functionalities were there for the editor, but then I am going to pass that into the struct for the system to use as soon as I get to that point and can piece it all together.

For the actual assignment of a path back to an entity that is what WaypointManager struct would hold (which I just moved onto the WaypointComponent and made public instead of keeping it inside the pathing system), and I would need to make a separate WaypointAssignment system which would use the stored entity and the waypoint list to send it back to the entity. Essentially the WaypointManager will be created when a vehicle needs a waypoint, it will hold reference back to the entity that needed it, what its last pathpoint was so it can use that as the start of the new path, and then hold what the actual path ends up being, then it will get pushed back to the entity that needed it.

https://hastebin.com/xofilequwo.cpp - GetPathSystem
https://hastebin.com/viludacino.cs - Actual Waypoint Component
https://hastebin.com/edozurugek.cpp - WaypointConnections
https://hastebin.com/sicehupife.cs - The system for determining distances and when to create path, etc.
https://hastebin.com/ozuboracex.cs - My actual movement system

P.S. Thanks, my goal was to try and make something fairly silly and funny, as I always got a good laugh when playing around with the PuppetMaster asset.