Applying Software Development Concepts to Game Development

I'm starting to spend waaaay too much time dealing with design problems, and I don't want to if it's not going to benefit me.

I'm studying Programming in college (graduating this summer), and I'm wondering: am I applying software design concepts where they don't belong?

I'm relatively new to game development (this is my first serious project), and I'm struggling to find a happy medium between the part of me that believes in design and documentation and the part of me that just wants to make the game.

I'm trying to use strong OOD in my game, but am new to doing it in Unity, and the component based system is throwing me for a bit of a loop.

I have hierarchies of classes as follows:

StatManager : Monobehavior
PlayerStats : StatManager
EnemyStats : StatManager

and

ActionManager : MonoBehavior
PlayerActionManager: ActionManager
EnemyActionManager: ActionManager

ActionManager is abstract and has a stats object of type StatManager. In my PlayerActionManager I want to set stats to a PlayerStats object, and in EnemyActionManager I want to set it to an EnemyStats object.

However, I also want to be able to see all of the values contained in each stats object in the inspector.

See Below:


The only way I've found around this is making an empty object with the PlayerStats or EnemyStats class attached to it and assigning it to the Stats field. I can then see the variables inside the empty game object, but this doesn't seem to be the greatest of designs.

Attached to my player:


Attached to empty gameobject named GameObject, which is assigned to my player's Stats field:


I could also add a PlayerStats component to my Player, and then put my Player into it's own PlayerActionManager's Stats field:


...but this stinks of circular dependency to me, and in my experience, that leads to terrible things.

What do you suggest? I really want good code design for maximum maintainability and ease of expansion, but as I've said, I think the component driven system is making this difficult for me.

• Am I getting too hung up on design, and should I just hack through it?
• Should I maintain the way I'm going with my OOD and just find a way to make it work with the component based system regardless of the fact that I don't think it seems 'right'?
• Or is there some conventional way of doing what I'm trying to do (mix OOD with the component based system)?

Let me know what you suggest, or how you might tackle this problem if it were you.

I'm struggling to apply (or to not apply) the software design concepts I've been taught to game development.

Please help. My brain hurts.

 

There is such a thing as paralysis by analysis, and I too suffer from the condition from time to time.

I would add the PlayerStats and the PlayerActionManager directly to the player game object as you have done in your last screenshot, then assign the player to the PlayerActionManager's Stats field. There is no real concern of circular dependency because PlayerStats is not aware of PlayerActionManager, and when you assign the player object to the Stats field, its really referencing the component that matches the type of the field (so it gets a reference to the PlayerStats component, not the player object itself).

Otherwise your design seems sound. I often refactor classes as a project develops because the design requirements become clearer and clearer. There have been projects where I made subclasses for everything I could imagine needing, which left room for a lot of flexibility. I later realized that the idea behind many of the classes would have been great if it was necessary, but the project became overly confusing to support features that I never did implement. So I spent a bunch of time simplifying things to match what I really needed, not everything imaginable. Point is, either way, refactoring is a part of the development process for me, so I try not to over design up front.

 

I would look into State Machines instead of "action managers". Unless that's essentially what it's doing. In that case, carry on. Programming is about making an efficient environment for yourself. Just make sure the code feels comfortable.

 

I would seperate the stats from the manager. A stat is just a number attached to a name, in essence. Then in your manager class, you have an array of Stats. If your Stat class inherits from ScriptableObject, you'll even be able to edit the Stat from the manager object in the editor.

It'd be one way to increase the expandability and flexibility of your system, and let you use the editor how you want. With Custom Property Drawers, you could even get really fancy stuff going.

 

For starters, video games are software, so software design applies here just like it does to any other software. Also, just like with other software, how far you go depends on a variety of things.

Moving on, I suggest reading up on inheritance vs. composition. For whatever reason people new to component based design seem to commonly think it's at odds with OO, where really it's a type of OO. It can also be used in conjunction with class hierarchies, and often good solutions come about from a combination of the two approaches.

 

+1 on this. I ran into the same wall when I started Unity awhile back - things sort of clicked for me once I realized that composition works WITH OO, not against it.

 

Thank you, this is very reassuring.

 

Thanks to everyone for your posts. I'll definitely look into the things you've suggested as research.

Much appreciated.

It's good to know I'm not the only one who's experienced this issue.