I suggest you use an object oriented language (C++ or C# or Java … you know I'll steer you toward C# and Java but it's up to you), and then make a class diagram. For the purposes of what I'm going to talk about, we'll talk about C# and .NET/Mono.
In that way, you can draw a class diagram. Do an abstract one (not a strict UML one) to get the basic concepts down to a T. Decide what your classes will be.
Classes should reflect real world objects. When you try to think of classes for a game, imagine it as a board game, it helps. For example, you have a player. That's one class. You have the game field, that's another class. You have items, that's a class. You have enemies, you can have an enemy class. You'll also have the game as a whole, that's a class in itself.
When you do this, think about inheritance. Inheritance is when a class can be based off another class. Rather than have a billion classes for different kinds of items, perhaps you could have a single item class. Each different kind of item could inherit from the generic item class. Therefore, you re-use code efficiently.
Code-wise, when you instantiate a class (turn it into an object in memory) you can use constructors. Constructors plus inheritance equals code reuse if done properly.
You should learn about the object oriented programming paradigm as a concept rather than jump into programming without it. Learning an object oriented programming without learning object oriented concepts means you'll write a semi-procedural program which is event-based but not object oriented.
The reason I promote object oriented languages and concepts to you is that it can dramatically simplify the development process. Procedural programming has its advantages too, but for the purposes of your game, I think OOP would be simpler.
