Planning Out Systems

I've only just gotten involved with Unity, because I want to make a game. I've watched the top-down-shooter tutorial, which I found very helpful in explaining the main components used in a game. So now I think I'm ready to tackle a project of my own (a simple one of course). In my programming class, we had a relatively large programming project due for the final, a game programmed in java. And one of the first steps the teacher gave us, in order to help us visualize the project, was to write out all the sub-systems the game would require. And then each subsystem was filled with placeholder methods, no actual code yet, all to give us a good outline for what methods and classes would interact.

So that's what I've done here, very roughly. I just want to know, for those who have experience with this, are there systems that seem redundant, or systems that could be elaborated on?

Systems:
-Map Manager:
Will generate new maps, will have a variable for the type of map. Will load during the start screen.
-Game Manager:
Handles health of player, score, and most importantly, the spawning of enemies.
GUI:
This class handles all the static info that is displayed to the player while playing. Will display score, weapon status, health, etc...
-Player:
This class/subsystem will control the input for movement, shooting, and other controls. Will have to manage
weapons (a whole other subsystem), equipped stuff, will communicate collisions with the monsters.
Enemies:
This will be a superclass that defines movement speed, collider size, and other general information, to be
loaded later for individual enemy types. The loading will be handled by the Game Manager.

I do feel like it's lacking though. I'm not looking for a guide on writing GDD's, but I realize that I haven't considered the Animations or Sounds. I was also looking into porting to ios, but I'm sure that brings a whole other group of things to manage. If anyone could give me tips, and advice on planning unity games in general, that would be very appreciated.

 

Sounds good. To have any plan before starting to do something, is a key for successful finish.

Perhaps, you noticed that most of game objects in Unity3d have different components like Colliders, Meshes, Transform and so on. It's one of the major concept of game development - to think about objects like about set of different components. Probably you should think about enemies like about set of abilities instead of something inheriting superclass.

 

Oh, I haven't thought about it in terms of Components too much. Just wondering, how do I translate the concept of having a superclass into the concept of using components? I figure I can reuse scripts and such, but i think it wll also extend to animations and colliders

 

Component classes can use inheritance, last time I checked.
Also, you can make one component require another one using this directive http://docs.unity3d.com/ScriptReference/RequireComponent.html

I think you're overcomplicating stuff, at least in "Enemy" section. Play around in unity editor for a week or so and see how it works. You'll throw out half of the system out of the window.

Everything is GameObject that has Components attached. Components define what the object is and what it does. They have lots of function that are called in specific circumstances, and you modify their behaviors by overriding those.

So you don't exactly approach it from "global perspective" (as in traditional programming) where you imagine grand object hierarchy for everything, but instead you design many very small subsystems that know very little about each other and interact with each other very sparingly.
It is like playing with kid's blocks, but you can create your own new types of bricks.

For example, instead of "GUI manager" which monitors player and sets health gauge you can create component called "Health bar", which can only do one thing - from time to time request player from scene, check player health, and modify displayed value accordingly. The whole thing will be less than 50 lines of code, probably.

-------

Another issue is lightmaps with occlusion data. If you 'll be creating map dynamically at runtime, you won't be able to precompute visibility and lightmaps for it. But then again, maybe it isn't needed for your task.

 

Looks good. Nice single responsibility here.

Why are these items combined? They are not really related to each other.

Typically in Unity you would handle this with four or five components. Unity is pretty much built around the component pattern. Consider this when designing your system.

Again you want to embrace the component system. For configuration data you can check out scriptable objects.

Here is an old video I made around the concept of component based design.

 

Hey, happy thanksgiving people, and thanks for the very thorough advice.

I'll defintely be looking more into the concept of components, although I feel like heirarchies have some use still right?

Hm. I've thought about this issue. I figured I could avoid having to write a complex pathfinding ai by instead using a navmesh. But I plan on making the player traverse a map that changes a little (room-size, obstacle placement) each time. So is the navmesh system able to be reapplied to some extent, in-game?

And as for the GameManager system, I guess in Java I would typically group those systems in the same class for neatness sakes. But I can probably organize them differently if I think in components. BoredMorman, that video is pretty legit, and I think i understand the difference now. But does anyone have a source that's more in-depth about how to approach a problem with components in mind?

Again, many thanks for the replies

 

So I've redone the Enemy plan, and it's more based around components now.

Enemy:
Will pursue the player, die when shot, have variable speed/health/attack.
(Notable) Components:
-Collider
-Animator
-Animator Controller
-NavmeshAgent
-Movement Controller Script
-Health Manager Script
-Properties Script

I think I included all the necessary systems there. The only thing that I'm not sure about is the properties script. In it, I'll initialize simple public variables like SPEED, ATTACK, and HEALTH. And they'll be referenced to figure out how fast to move, how much the damage the player needs to take, and what the HP of the ENEMY is, respectively. I figured it's just neater to hold them in one script, but are there more elegant ways to do it? Is it bad practice to do it this way?

 

Build it and see what happens. There are advocates to the 'whiteboard' approach.

 

Yep. Making software is not building a house. Once you made something, you can always change it. So build it and test it.