6 replies to this topic

[Reactorcore]

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?

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!

[Vilem Otte]

Okay I don't have so much time right now so I'll give u just brief answer (I'm being forced out of my PC to go swimming - and so I will do, because it's around 40°C outside) on code organization and how to do it (e.g how we do it in company). (With hope that my answer really answers your questions)

It's a bit different in every game engine and game. For example in our previous and our current project we strictly organize (e.g. project organization) every part of project into it's own folder, sometimes even we do it as separate project (e.g. we make a library out of it).

Our simple folder structure right now represens how code is structured:
/bin - binary
/data - data (contains gfx, audio, game scripts, etc. etc.)
/etc - contains scripts for game engine
/usr - contains user data (saves, screenshots, captured video)
/src - most important folder, contains source

in /src we got basically just makefile (who needs IDE - good text editor + GCC/Clang and it is like a heaven) + main sources. Then the folders are organized in way, where every one represents module (f.e. OpenGL implementation is in opengl folder, Game Engine is in engine folder, Our vector math is in math folder, etc.), they also have some sub-folders (engine/graphics, engine/physics, etc.).

The second is code organization - e.g. not to have spaghetti code - every programmer must comment code so it's understandable (and comment a lot!) for every other programmer (we're currently 2 on current project, so it's not a problem). Also the naming should be united, nothing is as horrible as multiple naming systems in single project (class CShader, class model_t, class Texture ... no way - use single one, F.e. class CShader, class CModel, class CTexture), the same counts for procedure/method/structure/... naming. E.g. use one single naming system.

Also use namespaces in C++ or C# for organizing code (e.g. I call this inter-source organization) - F.e. I got namespace Engine, where is class CModel, this class can load models from obj file format (it can more, but one is enough for an example) through obj loader in namespace LibObj, uses containers for data from namespace Math.

If you keep high code organization the project (even monolithic) is easy to maintain.

Note: I don't say that our organization of code and project is the only one right... there are more ways to keep stuff organized and non-spaghetti.

[fireside]

I think finite state machines work well for a lot of gaming structure. You can have game states: menu, level1, level2, etc. You can have states for objects: door open, door closed, door opening, door closing, you can have states for characters: dialog, rest, attack, etc. I combine those with a global variable system. If(hasTicket) state = whatever. I write small games. For game saves, save the scene state and global variables. The global variables might also be main character variables, or whatever. I think object oriented code is the most maintainable, but not always the fastest. The ideal, for me, is to use an engine of some kind and then object oriented code for the interactivity. Plus, I hate detail work. You start with an entity and build up, animated entity, enemy, etc.
I'm a hobbyist, so this might not apply.

[BlackWingedGames]

One of the best things I learned to do was to structure my code in 'scenes'. When I first started, I had a behemothic application class which was a state machine, deciding what to do and what to render at a given time. But now, I have a singleton SceneManager which maintains a list of classes that inherit from Scene. Scene has virtual init, update and draw functions. So I have LogoScene, OptionScene, MenuScene, GameScene, HighscoreScene, StoryScene, etc. These can be kept completely separate. Also, the scenemanager knows which is the current and next scenes so thats where I do a nice fade transition.

[Stainless]

The sad fact is that most commercial code is a mess.

You start out with a nice clean design (I agree, scenes are the best), then you need to add a patch to get it working on <insert random hardware here> which means you have a load of #ifdef #else #endif all over the place.

Then management want to support <insert random os here> and so you have another load of #ifdef #else #endif

Then someone decides that this is all round and hairy dangly bits, so they write an abstraction layer, but they leave before it's finished......

Etc. Etc. Etc. ad nauseum

At the moment I am trying to get a game working now I have ported all the code. I found a macro that couldn't possibly work on any compiler/os/hardware, yet it is in their code. So I dug a bit deeper and found this file was in the source tree, but not included in the build.

Don't think commercial games are beautiful pieces of production quality code, they usually aren't

[alphadog]

Reactorcore, on 01 July 2012 - 04:10 PM, said:

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?

What you are asking here is for someone with experience to do a mega-mind dump of experiences, practices and processes...in a simple forum reply. Yeah, not gonna happen.

However, I can tell you that effective code is modular code. Seems blatantly obvious, until you see how much bad code is out there. There are two simple concepts: cohesion and coupling. You want to understand what code "goes together", and keep it in one method/block/module/function. At the same time, you try to minimize coupling, or how explicitly connected that block is to other blocks. You want highly-cohesive, minimally-coupled code.

From those two simple principles spawn a slew of methodologies, architectures, patterns, languages, language features (ex: generics), heuristics (ex: YAGNI, Law Of Demeter, etc.) and development tools that, to various degrees of success, help you keep those two principles in check.

In theory, you want to optimize furiously for both those broad concepts. But, in practice, there is a balance. The more effort you put in cohesion-coupling optimization, the more you may affect performance, development effort, maintainability, testability, etc. So, it's not just a matter of lining up the right "magic architecture". Also, as Stainless colorfully alludes to, there's the realities of development and the roadblocks that can make sticking to principles difficult or overlooked.

Some of my favorites "thingees" that are tied to the above discussion, off the top of my head: domain-driven design (esp. the concept of aggregates), inversion of control/dependency injection (to promote low coupling), functional languages, MVC-type patterns for UIs, component-based architecture and Haskell + functional-reactive programming.

Some notable books: Design Patterns, Code Complete, Game Engine Architecture, etc.

There's probably a million more things I could give you, but these were the neurons that fired during this post. At least, hopefully they should help you have starting points to google with...

[Reactorcore]

lol at the "b )" turning into a smiley.

Thank you for your replies, you guys have given some really good directions to me.

@ Vilem Otte:

Thats some very good advice, especially the folder structure example which was something I didn't think of right away. Although, what exactly is the /etc/ folder for specifically? Did you mean that it contains third party libraries/plugins for the engine or something else?


@ Fireside:

Yeah, state machines will definitely have uses for various components, such as the menu system and AI, atleast.

Since I'm doing this using C# with Unity3D, object oriented design is being used extensively because I like how OOP works and C# has great support for OOP. I want to create a component-based architecture so that everything would be modular and easily expandable/modifyable.


@ BlackWingedGames:

Can you please tell me more about how do you start coding the singleton scenemanager and how do you progress? This is something I'm trying to figure out for my menu system, but I'm not sure where to start with it.

Infact, I want to use the singleton pattern to make a gamemanager class that would control the flow of the entire game system, but I don't know how to go about it properly. I don't know how to start coding it and I don't know how to progress from there on.


@ Stainless:

Haha yeah I'm very well aware of that. However most modern games made today by big companies don't crash, thanks to consoles being more strict to enforce more stable code and better technical design (no tolerance for framerate loss unlike on the PC platform).

I'm pretty sure game programming has evolved to have better practices, even if not every company might have enough time to actually use them, but still, there are way to properly code something, including games.

Also the fact that I'm using C# and Unity3D as my engine for the project, which takes away some of the issues you mentioned there, like porting to other platforms, because its designed in the way to be able to deploy to all the platforms of your choice without having to fiddle around with the details too much.


@ AlphaDog:

Modularity is definitely a priority for me. Not just because the project I'm doing actually demands it due to its functional design, but I like the concept of it and I also find it very robust and flexible. Thats why I'm planning on creating a component-based entity system once I get to that point (and learn how to do in the first place).

You give some really good advice and directions here, for which I'm very grateful of and I do realize my question(s) are very case-specific and that they have multiple different answers for them. I was hoping that posting it on a forum would bring small hints from various people, not necessarily one person that would answer everything at once, and so far it has been a success. I take what I can get and you people have given me lots. A little bit of this and little bit of that from many places will eventually accumulate to the big answer you were looking for.

I'm currently studying design patterns as well as the full language features of C#, but you also mention various other topics I haven't heard of (MVC, Domain Driven Design, Haskell...), so I'll have a look at those. Thank you.