Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. Dismiss Notice

Help with code design/architecture

Discussion in 'Scripting' started by Dorf, Oct 20, 2018.

  1. Dorf

    Dorf

    Joined:
    Aug 13, 2013
    Posts:
    10
    My project currently has a player running around trying to wrap packages. The player moves to a pile of packages, gives an Input from the keyboard and gets an item in his hand (very similar to overcooked). He then has to walk with it to the wrapping table, give another keyboard input and the table takes the package away from the player, changes the color of the mesh and spits it out. Player then picks up the package again, goes to the back of a truck and puts the package in there. Rinse and repeat.

    I'm having a bit of a problem of spaghetti code at the moment. The Player class handles the input and calls PickUp and ThrowItem classes based on it. I do have an interface called IStation that both the truck and table implement. It basically has 3 functions. One to check if it's in use, one to receive an item and one to give an item away. There's also an Item class that basically just has code for changing the color of the package to indicate it being wrapped.

    In the future I would like to have different stations like one to wrap, one to attach a bowtie and one to slap an address card on the package. However I'm getting a bit overwhelmed by the amount of complexity and not really sure how to design the code to be, well good and extensible. Both my ThrowItem and PickUp codes require a reference to the Player script because Player scipt knows where the character's hands are so items can be placed properly. Player script requires a capsule collider and a reference to an item the player is holding so it can disable and re-enable collision between the item and player. It just seems like everything depends on everything and it's driving me nuts!
     
  2. TimmyTheTerrible

    TimmyTheTerrible

    Joined:
    Feb 18, 2017
    Posts:
    186
    I feel yer pain, and to some extent, a lot of things are going to need to know about each other(especially if those items require some sort of interaction).

    It would be worth it in my opinion to look into something like behavior trees. In behavior trees, you can design small chunks of code that contain only the references and code they immediately need to complete some task. You then string these nodes together to form a final resulting action.

    I use this one https://assetstore.unity.com/packag...or-designer-behavior-trees-for-everyone-15277

    If you watch some of the tutorials for it you will get the jist. The general idea is just to make small chunks of code that can be plugged together like legos. In this we you can reuse small portions of code anywhere in the behavior tree. The behavior tree itself will eventually become quite complex, but this is better to me than making huge classes that become a spider web of wtf.
     
  3. AdamRamberg

    AdamRamberg

    Joined:
    Dec 8, 2016
    Posts:
    22
    I would recommend looking into this video and this article on how to use ScriptableObjects to make your code more modular, editable and debuggable. Great stuff that will help you create less coupled code.
     
  4. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    Pass the references you need in when you need them.

    In your examples it seems like the player should be the code that's 'in control'. The player walks up to a package and calls IInteractable. The player gets a reference to the package and picks it up.

    Later the player gets to the table. He calls IInteractable on the table. He passes in a reference to the package. The table takes control of the package, and the player nulls its reference to the package. If needed the table can pass back animation instructions, which covers off the hand movements.

    And so on. When the player calls IInteractable on a table that has a package, the table gives him a reference to the package, and the player picks it up again.

    Throughout the exercise objects only ever have references to objects they are currently directly interacting with. As soon as the interaction stops, the reference is dropped. This is a simple form of dependency injection. Do it by passing interfaces around, or possibly even small structs with all the data nicely grouped together, and no code needs to be overly dependent on any other code.
     
    Munchy2007 likes this.
  5. mvinc006

    mvinc006

    Joined:
    Jan 1, 2018
    Posts:
    91
    That video is gold. I had no idea singletons weren’t really going to help me moduslize my project, it’s an eye opener that’s for sure