I'm making a text adventure game, but I've run into trouble when it comes to structuring my objects.

In my game, every item (objects, weapons) implements the GameObject interface.

public interface GameObject {
     void viewDetails();    
}

List<HealthPack> healthList = new ArrayList<HealthPack>();
healthList.add(new HealthPack(3));
healthList.add(new HealthPack(5));

display(healthList);

public static void display(List<GameObject> objDetails){
      //loop though the list and display.
}

public abstract class HealthPack implements GameObject {       
   //the sub-class could be a ration, potion, or pills
   public abstract void replenishHealth(){}
}

List<HealthPack> healthList = new ArrayList<HealthPack>();
List <Weapons>  weaponsList = new ArrayList<Weapons>();

interface Character{   
    void pickUp(Weapon weapon);
    void pickUp(HealthPack healthItem);
    void use(Weapon weapon);
    void use(HealthPack healthItem);
}

public class Paper implements GameObject {
  public void writeText(String text);
  public void foldPaper();
  @Override
  public void viewDetails();   
}

Java or C#, right?

I see a lot of these baseclass (base interface) GameObject things, and from there running into all kinds of trouble, like you describe.

It originates (I think) from trying to make all things the same, in some way. As you're describing, different things are actually different, so yeah, somewhere it becomes a mess, as unifying truly different things isn't going to work.

So instead my suggestion is to honor that different things are different. Don't try to throw everything in one basket just because OO says you need a base-class, differentiate where it is useful. You're doing that already with eg Weapons (although you didn't write the precise properties that make a weapon a Weapon). Do it more. Nobody said you cannot have a Carryable interface for stuff you can carry around, or a LightGiver interface to provide light in dark matters. A big candle can have a Weapon, Carryable, and LightGiver interface, no problem whatsoever (as long as the candle isn't too heavy to lift).

As for storage in containers, this is really nice with interfaces, you can make a container for an interface, so you have collections of related stuff all for free, in every relation you make an Interface for, eg "ArrayList<Carryable> contents".

Now, as items generally have several interfaces, how do you access that? This is why "instanceof" exists.

if (item instanceof Carryable) { // Yay, I can carry 'item'!
    Caryable cy = (Carryable)item; // Cast to the allowed interface
    contents.add(cy); // Do your thing with that interface.
}

A second point is (which is probably much more important than the previous), don't design a hierarchy without need. It's very tempting to make a nice extensive generic interface for your items, and it's very good if you're doing a homework assignment to demonstrate your OO skills, but in real-life programming, don't build what you don't need. Make it all as simple as you can, and extend only if it improves the time to get to your goal.

Less code is less errors you can make.

As an example, couldn't a health-pack be a weapon with negative damage?

Honestly, an easy way to handle this is to make a generic container that is basically a bag of holding It will hold anything of an item interface. Then to access data or to lost specific items, you allow the generic to filter out types.

You can trade off time and space in most problems. This is one.

A solution for C# and Java --- and also in C++ but with some caveats --- is to have one container, and upon request return a container of objects that implement the interface.

These dynamic casts are speedy if the conversion is to the base class or the leaf classes, but in all languages conversions anywhere in the middle of the tree has a potential performance cost. For a base or leaf conversion it is usually a single-digit nanosecond, and for mid-tree conversions it is either single-digit or double-digit nanoseconds. When you multiply by thousands of items those nanoseconds become microseconds, or maybe tens or hundreds of microsoeconds if you're doing many. That's enough to be a concern on big games, not so much on hobby projects.

You gain the space and difficulty of maintaining multiple lists, but it comes with the cost of doing tests for convertibility.

In C#, you can make a container of of the specific type, for each item in your source list see attempt to convert with the "as" operation, if the result is not null then add the item to the result container.

In C++, if your code has RTTI enabled, build the container for the target type, for each item in your source attempt to convert with dynamic_cast, if the result is not null then add the item to the result container.

In Java, you can similar make the container, for use instanceof for every item, if the test passes do the conversion and add it to the container. (It may have changed in newer versions because of demand, but Java does not have a convert-or-null operation, instead it has a test operation and a convert operation, if you convert something that would fail the test it throws.)

The caveat in C++ is that there are many different options and several ways to do things badly. Many code bases disable RTTI entirely because in the 1990s and early 2000s there were some serious issues on some compilers, and sadly people are slow to accept that compilers have gotten better.

Further in C++, comparing directly with typeid() is exactly the same speed as a well-written implementation of custom system that returns a unique value for each type, except typeid() is built in to the language. The drawback there is that it only works with exact comparisons, not across sibling types or child/parent types. (It also is potentially different on each compilation, which means you can't use the value for any serialization purpose, so game developers usually ignore its existence.)