Designed A Game In My Head How To Organize It

Search Unity

Unity ID

A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate in the Unity community.

Forums
Menu

Hello!
For the past months I've been studying programming and I've finally learned how to code, but one thing that is confusing me is how to properly organize the design of a game project - code wise.

The game I'm building is a pretty standard commercial game. It has the basic components of a normal game: A world, characters and items interacting with each other and all of this is run by game manager. Basically you play as a hero in a world and do stuff. Fight, explore and interact.

Think of your standard adventure game that starts off with an intro, goes to the menu system, then gets into the game and back to the menu. Pretty much like 99% of any commercial game or otherwise serious game projects. Thats what I'm aiming at.

The problem is:

How do you properly code a commercial game architecture?

How do you organize it?

How do you make it not become unmaintainable spaghetti code?

What specific things to keep in mind when building this, codewise?

How you can help me:

a) Please tell how do you code your own game projects. What is your thought-process when designing the architecture?

b) Recommend books, blogs, tutorials, videos or anything else on how to organize a commercial video game.

c) Give hints and tips on do's/don'ts when building a game, codewise.

Please help!
I don't think there is a right or wrong way to do it. Im not a pro but for the games I have made, I start with the engine first. Work in all the features and systems. Then I'll design terrain, assets, characters, story telling etc. Finally I'll create the opening and ending screens.
If you are using unity, which you hopefully are, the process is much simpler and every thing is devided up into its own script. I also used to visit www.gamedev.net quite a bit. You might find more helpful information on the design process there.
Yes, I'm intending to build the game with Unity3D and C#.
Can you tell me how do you begin coding the engine of a game and how do you progress from there?
After some games and other systems I made, I achieved some pattern that worked for me.
It is hard to list every detail but I have a common structure of gameobjects/scenes in my project:
Scenes:
- Loading: Load (duh) all initialization stuff and global vars from HTML or whatever. Show some loading bars and feedback.
- Mainmenu: Show options to configure the game, help, splash screen,...
- Game: Scene where the game unfold and stuff happens.
- EndGame: Scene where game finishes and guide the user to game over or next stage/game
- Game - N: Possible next stage if the game has stages. This leads to another stage or endgame.
- Scores/Ranking: If there is a ranking or so. Make some load data (to show scores) and send game data to finish the user interaction. Then return to mainscreen.

Script: I follow a model of structuring the code like this:
+ application (holds reference for all main elements)
+ ui (contains screens, huds, panels, and everything UI related)
+ manager (contains scripts that receives feedback from UI and Game and apply them to the correct targets. Contains all Game Logic data in it)
+ game (contains the scene, players, enemies, hazards and so on)

- UI and Game MUST not change ingame data nor change game state logic. They are slaves of the Manager. They notify stuff and the Manager will handle it.
- Why? Because with this model each programmer team works in pieces of code that do only what they are supposed to do and notify the Manager. The "Manager" team asks only for events and stuff and do not need to mess with UI or Gamecode.
Ok, I will take another stab, because I think the current answers does not address your real question related to architecture.
Some obvious things that comes to mind is inheritance. You really need to think about this when designing your architecture. This is somethning that I think many game developers neglect and it is difficuilt to explain without a proper example. But one example I can think of, is writing your own, proper inventory class that is so generic that it can be used (without physical modification) in any of your projects. So this inventory class might for example inherit from MonoDevelop and thus making this the base class of another class will also inherit MonoDevelop, together with the inventory class's members, methods etc. That is why I say you really need to think about the purpose of this class, it members and methods. Which methods needs overloading. Do you really need to make a variable public or can you rather use GameObject.Find() to populate the variable etc. Another example that I did recently was to script my own message display system. So now I can just add that namespace and very easily implement it.

So I would say your short term goal should be to start making your own namespaces/library objects that are generic and can be used&modified through all of your projects. Once you have done that, you know that you are on the right track.

Hope this helps
Yes inheritance and other OO programming methods must be used.
But before that happens you need to define your environment wich includes the scenes your game will need. And the root components that will handle the main features of your application.

Here a simple example to make it easy for every element gain access to its manager.
public class Entity : MonoBehaviour

public MainApplication application { get { return GameObject. FindObjectsOfType ( ... ) ; } }

public class MainApplication : MonoBehaviour

public ManagerController manager;

public GameController game;

public class UIController : MonoBehaviour

public EndScreen gameover;

public GameController : MonoBehaviour

public ScenarioModule scenario;

public EntityModule entity;

public class ManagerController : MonoBehaviour

public InputManager input;

public class Player : Entity

if (damage) application. manager . game . OnPlayerReceiveDamage (who) ;

public void GameManager : Entity

public void OnPlayerReceiveDamage(who)

application. ui . ShowMessage (who. name + " hit you!" ) ;

data. health -= who. damage ;

application. ui . hud . health = data. health ;

public void CallGameOver( ) { ... }

//So every "alive" element that generates feedback in the application is an "Entity". Being an "Entity" allow them to access the Managers in the "ManagerController"

//Example: A screen can be an Entity that when detects mouse interaction in the buttons it tells UI manager to hide the screen and activate the game

//Example: The player is hit with a projectile and tells GameManager about it wich handle the activation of the particle effect and decrease of the player health. If the health is zero process the game end by calling the end screen from the UIController.

//This way a Team would develop the UI and another team would develop the Game and other team would develop the managers that //listen to them and handle the Application execution state. No conflicts between programmers.
Sirex

Joined:

Feb 7, 2011

Posts:

77

What i did was basicly seperate my program files in 3 cataloges. ObjectDataDimension, GamePlayAspectDimension and TechnicalDimension. In the first i have pure data classes.
In the second i have behaviour code like move and attack, these have their own folders.
In the third i have gui, gamestate and network.
An editor GameObject/PreFab is construct usually with one ObjectDataDimension class, several classes from the GamePlayAspectDimension and these implement gui interfaces and network interfaces. All classes are unity components, that they inherit from MonoBehaviour.
I based this on Multi dimensional separation of concerns, which is the thought process.
http://www.st.informatik.tu-darmstadt.de:8080/lehre/ss02/aose/Papiere/Thema7/sac2000-HyperJ.pdf
he idea was that it should be easy for me to add new behaviour without having to open up some big class.
I keep it from becoming spaghetti code with refactoring and generalising /subclassing. To keep the classes from each other i usually create service interfaces and scan for these. Like in the move catalog i have a interface called IAfterMove that has a function AfterMove(). Any class on the gameObject that implements the interface will get the function called when the object has moved. Thus no other class need to know anything really about the move class. Example is that the a sight script might want to update what the object sees.

What i keep in mind is refactoring and avoid duplication. You need to minimize duplication that can lead too maintain nightmare. Also aware of easy functional solutions, like first class functions and closures. I also have found that i use the strategy pattern, but with first class functions instead of the OO mess solution.

Try to decide on how part system of the code should communicate. If you find that all parts have two way communications with all parts you probably have a problem. Also separating code do with a set of gameRules to check against don't work, trust me.

If i would have started over i would probably map my data classes 1-1 to database tables.
I also faced this problem too after I tried to make my commercial project,in the end this playlists helped me out!

It is a great playlist named Non game dev tutorial by a channel named Board To bits

what I do in my games is
- There is a 'don't destroy on load' object called 'Scene Manager' or I create a singleton.
  
  It checks which scene are we currently on and call the necessary managers to perform their functions
  
  for example: If I am on my Game Scene ( where we play the actual game) the scene manager will call the Game Manager or Level Manager and then the Game or Level Managers will set up the level.
  
  Or if I select to go to shop then the scene Manager will open the shop scene and call the shop manager or any other manager that you have to do the specific function.
- For better code learn how to use delegates, inheritance, OOP concepts properly.
The channel mentioned above has some great videos which can help you in your code like Scriptable Objects

You can also use websites like trello.com to plan and manage your games, for example: making a chart like thing to get a physical view of your code structure
I will add if I learn any thing new!