Hey,

So I'm currently working on my first serious project. It's basically a rogue-like combat game that focuses on melee. I want the combat to be a blend of Crawl and Hyper Light Drifter. Anyways, I've been thinking about how to structure the game and cannot organize my ideas. Earlier, I wanted to create a health system for my player. Instead of just adding one to my 'PlayerController' however, I made a generic one with variables and methods that would allow for generic data storage. You'd specify a max health, and then use a method to inflict damage whenever needed. There was also a method to check if the entity died.

I'm not sure if I can structure my whole project this way. So far my only other script is the one controlling player movement/attacks. I'm using Unity, so component-based design is a pretty big thing, Now I have to implement things like an XP system, a generic control for monster AI, and a template to define weapons. How should I approach all this code? How should I structure it? I took a look at this but still don't quite understand what it means.

The entire time I've been making games, I've just been doing my thing. I found out with my last decently sized project that just writing code is not a good idea. Can someone introduce me to some game design/structure principles?

Thanks.

So the problem you might have with the approach you took is being able to guarantee that a specific object has a specific module. So what would happen if a Crate Object was attacked but you hadn't given it a 'health' module? Sure you could go ahead and give it one but when you start entering things like: 0 health 100 damage reduction, into your modules just to avoid things crashing you are hacking your away around an issue.
Like wise, Unity provides functions for searching and checking for components being present:

SomeScript script = gameObject.GetComponent<SomeScript>();
if( script == null ) {
	// error out 
}

But that, while good coding practice to handle errors, is writing special exception cases for things you should be handling a little more consistently and smoothly. Also if the above code was to appear everywhere an entity tried to attack another entity, you would have a lot of redundant code that is prone to introducing errors.

So my suggestion would be to find some way of generalizing what actions can be taken in game. For example if you dictate something like "ALL objects that are physically present in the game are a subclass of class X" then you can place all your interactions that are possible in class X: hit, push, pickup etc. That way no matter what tries to 'hit' any object, for example, you know that it is an action that can be handled. Now of course you want to have every object act differently when interacted with. So that is where you could use the Strategy Pattern to 'attach' different behaviors to objects. Ask me directly later if you need help with the Strategy Pattern itself.

There are other ways to solve this problem of course, as is the way with programming, but this would be my specific recommendation. 

It helps me a lot to think about everything in the game as an object, and then understand the concepts beyond gameobject hierchys and Interfaces(like the C# term not the User inteface one)

Everything in your game will likely be a gameobject, so you should create a gameobject prefab.

Anytime you update your GameObject prefab, those changes will happen globally to any prefabs using the GameObject prefab.

Then think about the people in your game world, because in my world ALL players/npcs interact with physics. So I built a character prefab.

The character prefab handles ALL environment related interactions.  If I build it right, I can build it once and never look at it again in a best case scenario.

Expand character into 2 new prefabs.

Player and Enemy

Player -> attach Controllers  to move character

Enemy -> Attach AI to move character.

Sorry if my explanation is weird, but the overall idea is think really really hard about your objects and try to make them as versatile as possible and slowly expand.  If you run into a physics problem 8 months into the development process, you don't want to have to look through 152 different objects with physics attached to them, you just want to try to fix 1.

Don't be afraid to write, and if you study UML that is not a bad place to start either.