In my game, I have a bunch of methods which handles interactions between the player and objects within the world. The list of these methods is only going to grow as I move forward with the game. My question to you is this:

What is the best way to handle methods between the player and world? Currently I have them in my Player class and main game class and even at this point it looks sloppy and unorganized.

Player class contains interactions with inventory, and interactions between tree objects in the world. I don't know why I put the tree methods there but it seemed like the right place at the time.

Main game class contains all collision detection methods, and methods for creating a fire. I think the collision detection methods should stay in this class, but there is no reason for the CreateFire methods to be in there.

Would I be better off creating a new class that holds all of these methods that handle interactions between the player and the world? I know in XNA you can create a Game Component type class which may work.

public class InteractionHandler
{
   //some variables here
   public InteractionHandler{}
   //empty constructor
   public void UpdateHandler(//some parameters here)
   
   //all methods that handle interactions
}

This is the idea I have in my head. I've never created a game of this size before so I don't really have an idea about how to organize this.

There's a gazillion ways to do this, and a mere bajillion are actually "right". Sarcasm aside, I think we need more information on what you're actually doing right now. Short of that, the best I can say is "don't over-engineer things until you actually know what you need".

I'm trying to get into the habit of organizing my code before it becomes too cluttered and I can't find a method when I need it.

Player class:

-Load, update, and draw

-Remove and add items to inventory

-Pick up, Craft, and equip items

-Get items from a tree and bush(should be in seperate class?)

Main class:

-Load, update, and draw

-check collision between map and player

-check collision between solid objects and player

-sets player variables nextToTree, nextToFire, nextToBush(separate class?)

-3 methods for setting tinder in fire pit, lighting the fire, and adding logs to the fire(separate class?)

This is kinda the breakdown of what I have going on right now. I feel like some of these methods don't really fit in those 2 classes and I'm wondering how to organize this

I'm trying to get into the habit of organizing my code before it becomes too cluttered and I can't find a method when I need it.

Player class:

-Load, update, and draw

-Remove and add items to inventory

-Pick up, Craft, and equip items

-Get items from a tree and bush(should be in seperate class?)

Main class:

-Load, update, and draw

-check collision between map and player

-check collision between solid objects and player

-sets player variables nextToTree, nextToFire, nextToBush(separate class?)

-3 methods for setting tinder in fire pit, lighting the fire, and adding logs to the fire(separate class?)

This is kinda the breakdown of what I have going on right now. I feel like some of these methods don't really fit in those 2 classes and I'm wondering how to organize this

Ok, I see what you're getting at now.

Yeah, you definitely don't want a separate method/variable for each type of object.

Consider that each object is just that --an object. Depending on what language you're coding this in, there may already be a use for that word, but be creative ("GameObject" or whatever).

In general, the player usually doesn't store that type of information directly. At best, the player class knows what it can do, given the inputs it can make. It's up to some external entity to resolve that. For instance, if the player presses a button presses the "set tinder in firepit" button, the game has to:

1. resolve what the button does. If it does multiple things (like a "use" button), that entails asking what's nearest to the player and in activation range.

2. actually resolve the effect. This is probably done on the side of the objects.

I wouldn't use a "handler" for this. The general rule is that "classes are nouns", and at your level of experience, I would treat that as ironclad. "Handlers" are kinda-sorta nouns but not really. They're more like conjunctions in disguise.

As an outline of how I'd probably do it at first shot (I can almost guarantee this isn't completely valid C#, but that's not the point, and you shouldn't copy this verbatim anyway):

/*Not shown here -- "action" is an abstract concept to handle overloads of commands.  if "q" does different things in context, an action is a way to map that to the object being acted upon and resolve that context.*/

interface IGameObject
{
    void onUse(Entity entity, Action action);
    //other stuff...
}

public class Tree : IGameObject
{
    public static int treeWoodQty = 5;

    public void onUse(Entity entity, Action action)
    {
        if(action == CutDownTree)
        {
            cutDown();
            player.give(Wood, treeWoodQty); //"Wood" would probably be a class of its own, implementing an interface "item".
        }
        //stuff
    }

    void cutDown() {} //not implemented here.
}

The inventory probably should exist separately from the player class.

Likewise, crafting and equipping probably shouldn't be in the player class.

Collision shouldn't be directly handled by the main class, but probably by a class that the main class owns.

Are you separating the idea of the player (what the user has collected, accomplished, etc...) from the idea of the player's avatar (the visible representation) walking around?

The visually animated appearance of the player in-game shouldn't own or know about things like inventory and crafting.