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!

      91
      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
  • Who's Online   0 Members, 0 Anonymous, 7 Guests (See full list)

    • There are no registered users currently online
  • Blogs

  • Posts

    • Hey Folks, So the next thing I want to setup is holding items. If we want to place items it makes sense that we'd need to be able to hold them. I haven't really thought about how we should do this but I'm going to spitball here and see what captures us. The Player Handler only does a few things currently: Saves and Loads Player Data. This actually also includes WORLD data as well currently, just out of convenience. It tracks the player position and updates that positional data. Contains the various artifacts critical to the game running so that they can be saved and loaded to. That's not much, in fact 1 and 3 are basically the same thing. I think the lean nature of the player handler is very ideal. I'm going to try to not sully this in the long term. And just as I'm writing this I realize I'm forgetting about another class on the Player Object. Our Player Input Handler takes care of all the KBM or Controller inputs of the human player. Well maybe Human, maybe cats will ant to play this, I don't judge. Regardless, we have a class that handles this information. I worry that this class has gotten far too big, basically the inverse to our player handler's lean nature. So what we can do is create an HandlerInteractorPlayer component, this will be the container that houses all of our interactor logic. Likely including rulings like "open handed" or similar. It will also pipe the "currently held item" back and forth from the player data inside the player handler. We can connect this to our Player Input Handler with an artifact like everything else. From there we can communicate player inputs through the interactor. This does leave me wondering if I want to break up the player input handler into some ScriptableObjects rather than multiple components. This would be easier to pipe into a game menu elsewhere. Perhaps that will be our first experiment this coming week. I think we'll go this route, make the base class with all our functionality then contain it within an artifact. Sure...ok. For now I think we only need to track what item that is selected. For now that can be handled with some keyboard commands, but later will likely be h...oh! I'll have it be the number row, maybe this will be a good time to put in a dummy UI for your inventory quickbar. Fun! Ok, that's it then. See you this coming week!
    • No matter how hard Manor Lords tried, I did manage to do a small bit of work tonight. Trivially added a new action to the adventure system that lets us reward items to the player. I'm really pleased that it only took a couple of minutes, this suggests to me that I'm on the right path with that design. In the future I think I'll want the actions to be coroutines, just so we can yield on some as needed.   If I've mentioned that before already, welcome, I'll be doing that a lot over the next few years. Lots of things to keep stuck in my brain and some of it loops.
    • I got it! Our action system works great with the adventures and provides us with a ton of flexibility with each new adventure. In this example our kitty goes on the adventure, then after the adventure finishes, they return and their need is satisfied. Tomorrow I'll see about doing an item award to the player. Obviously later these will need updating to include animations, sounds, etc, but the core is there! PARTYCAT_Smol.webm    
    • Today was kind of an awful day physically for me. But regardless, the cats send themselves on adventure, pool themselves, the adventures go through their timer, then complete as expected. So all that remains is to create the adventure reward actions! That's quite exciting, one of those will be unpooling the cat, another to satisfy a need and so on. Looking forward to playing with that tomorrow.
    • Alright! I took a huge detour tonight to work on an EDH deck of mine, but we've got the kitties able to send themselves on adventures based on their needs. In this case I made my kitty tired and there are no available beds in the scene. So they go to the adventure node to leave on an adventure. They find and add themselves to the right kind of adventure and start it. Tomorrow we'll get the hooks tested for them pooling and unpooling themselves and finally handle the adventure actions which (I hope) will be much easier. So that's nice! Also yeah, I need to name my cats so they stop just showing their guids for their name... Huzzah!
  • Members

    No members to show

  • Member Statistics

    • Total Members
      1,376
    • Most Online
      614

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