Jump to content
  1. Official

    1. Moosecat Twitch

      Changelogs, conversation, and anything else related to the Moosecat Twitch project!

      10
      posts
    2. Moosecat Manor

      Changelogs, conversation, and anything else related to the Moosecat Manor project!

      51
      posts
  2. Community

    1. General

      Do you generally chat? Generally that will go here.

      1
      post
    2. Fitness

      Do you like working out? Want to discuss how things are going with your workout life? This is the place to do that!

      1
      post
    3. Creativity

      You make things? You fix things? Show us all the interesting stuff!

      • No posts here yet
  • Blogs

  • Posts

    • I did update it a smidge. if (data.UniqueID != Accessor.ReturnComponent<HandlerMoosecat>().UniqueID) { return; } I can only assume this will be a faster comparison than the full classes, I bet if we look it up the answer is "No those are exactly the same speed."
    • I had been mulling all the different ways that we could validate if the actor receiving an event response is the one that should be responding. But seeing as our act calls are unique per actor I can just do a simple equivalency check. if (data != Accessor.ReturnComponent<HandlerMoosecat>()) { return; }   It is literally this easy. At the start of my act function I just compare the incoming data to the same data that is on this state machine. If they match its the same object that made the call, if not it is just another live actor that matches the type. You might think "Will this scale?" and the answer is basically yes. We'll have a finite number of actors, Humans, Moosecats, perhaps eventually other magical creatures. But each time you are looking at a single new handler for probably hundreds of variants of that thing.   This should mean that going forward while I do need to add additional support it ends up being a few lines of code to cover me for that entire new family of critters.   I don't know why I was overthinking this. But starting tomorrow we can run the test on multiple cats. I'm very optimistic and now I've gotta go discard some changes.
    • Currently for the cats I am simply doing a lookup of behaviors in the scene and checking for those that implement the satisfier interface. In doing this I can tell if they are something that *could* satisfy the curiosity or needs of a cat. Classically this hasn't been very efficient in Unity and I'm not even sure I need to do it. If we think about it, when assets are created or "destroyed" I'm actually just activating and deactivating them. If we lack a sufficient number of "pooled" assets then I create a new one and add it to the pool.   Eventually when a player has played long enough they reach a point where no new assets are created or destroyed. This means I've actually got collections of every possible asset already in the spawners. So what I'm thinking we'll do is create a central hub that has all of our spawners and their pools, then we can pass in the ID of the kind of thing we are looking for, food, play, rest. From here we'll check for a source that is available and active in the scene.   Once those needs are met that object will be assigned to the cat and vice versa (thus removing it from the available pool). If either the asset or the cat is adjusted in any way this will break the link. The cat will become free and the item will be free for other kitties to interact with.   The only things this won't cover are objects that will be in the world while I'm building, but we can always write a script that skims all that data when a zone is finished, if we assume the items cannot be removed. If they can be removed then simply skimming the map on load and seeing if anything is not currently tracked will be sufficient.   The last note for future me, I will want this container to live in an SO that is reset on load (when in editor), because we need it to persist between scene transitions, assuming we do full unloads. Time will tell.
    • Our little buddy is finally coming together! The Moosecat will now transition between Idling, Wandering, and Traveling to precise needs. These will also transition between one another as you'd expect. I still need to take care of the listeners for multiple Moosecats but I'm real excited! We are finally getting things actually going. Just check out how fast this little one is going? Look at that terribly slapped on trail renderer for effect!
    • Alright I need to do a few things tomorrow. We need to add in a declination (or veto) feature to our event system. That way I can do things like cross reference uniqueIDs or other data to see if an event should be respected by all listening assets.   Once this is done we can then move into the next step of finishing up our wandering system. That will get us pretty close to having the baseline logic system done and allow me to move onto other work.   I still want to add a few debugging adventures and have Moosecats travel to them when they can't satisfy a need. I also need to think about how kitties will act if their target gets taken by another cat while they are on the way. I suppose we could add little images of their faces over the asset so that the player (and other kitties) magically know they want to use that thing.   I'll think about it. I want it to be fun and simple to track for folks.   As far as the title goes, we've got spawning done for now. It spawns random food at random points across the central navemesh which is where I'm doing all of my work.
  • Members

    No members to show

  • Member Statistics

    • Total Members
      1,263
    • Most Online
      614

    Newest Member
    Joe Mama
    Joined
×
×
  • Create New...