10 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?

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!

Edited by Reactorcore, 01 July 2012 - 10:04 AM.

[Canvas]

Hey,

Well
1

How do you properly code a commercial game architecture?) Keep everything slip, so if you have a hero keep everything that is related to hero in hero, if every class looks after itself you wont have any problems down the line

2

How do you organize it?) Like above, just keep every class specific.

3

How do you make it not become unmaintainable spaghetti code?) There is nothing wrong with white space and comments, just comment every method so you know what that method does.

4

What specific things to keep in mind when building this, codewise?) The class you are coding, thing of everything it needs to do and what it needs to return, or you will be going backwards and forwards adding new code.

a)

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

notes, lots and lots of notes with explaining what each "thing" will do.

b)

Recommend books, blogs, tutorials, videos or anything else on how to organize a commercial video game. Well to be honest it depends on what you are coding it? Java? C++? C? C#? XNA? SDL? SFML? Clutter?

c)

Give hints and tips on do's/don'ts when building a game, codewise. Well in my experience I have made many mistakes, and the best thing to keep in mind, if your new this isn't easy, don't try and make your first project huge, like a 3D fps with multiplayer and in game currency bla bla bla, make pong or snake.

[DevLiquidKnight]

How do you properly code a commercial game architecture?
How do you organize it?

Design it in UML first. Approach your designs using a software methodology that are you comfortable with with, and get used to using things such as a subversion system. If your really interested in mastering game architecture, study it, Game Engine Architecture, API Design for C++, 3D Game Engine Architecture: Engineering Real-Time Applications with Wild Magic.

How do you make it not become unmaintainable spaghetti code?
What specific things to keep in mind when building this, codewise?

Organize your code well, comment it VERY well. Design a coding "style" and do not skew from it. Take and implement insights from books such as Code Complete.

Edited by DevLiquidKnight, 02 July 2012 - 05:16 AM.

[Zoomulator]

Doesn't have to be UML, just atleast graph it out on paper so you have a rough idea how things are connected that is clear to you (and the future you). Some people like going with the top-down approach, all the way down. I don't remember which book it was that described the process, but it went something like this:
Start with a general overview of the whole system. Then for each object, make a general overview of it that's more specific. Re-iterate until it'd be easier to code it than to describe it, and so code it.

I'm not one that implements this method though. I do tend to sketch up a graph once in a while, but most my design decisions happen while coding. This is fine for a one-man project, but not to recommend if cooperating with other programmers. I can usually envision the relationships in my head, and a good system should be easy enough to do so, but sometimes it does require a less abstract viewing. Even some algorithms, like geometric problems often occurring in games, benefits of a visualization to make it easier to get your head around it.

Some people don't like to, but I use an event system in the core of my program. It is passed to game logic, networking and rendering, so that they can be separated. An event system makes it possible for systems to exists independently of one another.
Example: Logic creates a new object and sends an event about it. Now the rendering system can chose to register to such an event and handle it. Change of position and other states that can be useful for the rendering engine and can be sent as events as well. The rendering system then creates the right visual object for the game object and changes visual queues depending on the changes of state in this object.

Comments in code is good, and should be describing in short and accurate terms what is happening in blocks of code. This is however more difficult than it seems with long term projects. Preferably, take those blocks of code and make them into functions with a name that describes what happens in the function. If it's difficult to name a function it's probably not a well defined function. I do this frequently, much a constantly ongoing process. Comments can get old because it's seldom updated when the code is, which leads to comments making more damage than self describing code. I'm not saying you should be extremist towards one or the other. Just keep the issues of comments in mind, as well as littering your code with too many functions which makes it more difficult to gain an overview of!

Edited by Zoomulator, 02 July 2012 - 07:00 AM.

[L. Spiro]

The problem is:

#1: How do you properly code a commercial game architecture?

#2: How do you organize it?

#3: How do you make it not become unmaintainable spaghetti code?

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

#1: #2: #3: You basically just asked the same question 3 different ways.
The answer to all 3 is, “By leaning on the experience we have gained from past successes, failures, and experiments.”
It is not as if you are going to get an answer here that will just suddenly enlighten you and change your world forever. If such an answer existed, it would be on Google and we would have all done it.

Proper code and organization come from experience. Avoiding spaghetti comes from…experience.
I do however have some general tips to pass on, but I blogged them so that I would not have to retype them every time the issue arose.

Here are some tips for general coding safety. This helps your stability and memory-leak issues.

This post is more helpful for avoiding spaghetti (feel free to ignore the section on naming conventions). Following a strict set of guidelines means consistency. If your code is consistent then it is easier to work with it. A lot of the suggestions there have sound reasons behind them, and I tried to explain the reasons instead of just listing the points.

One of the things that causes spaghetti at the office is that classes frequently go from public to protected to public to protected to private to whatever.
People just randomly change exposure as they went along. This makes it very hard for me to find functions, members, etc. Just because I left one public section does not mean there are no more.
However, if you follow the rules, leaving a public section does mean there are no more, and if you missed something you now know you need to scroll back up instead of searching the entire rest of the file.


#4: I keep in mind past successes, failures, and experiments I have had. Seriously, there is nothing that can replace experience. Nothing we can say will suddenly just change the way you think about the code you are writing.

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!

A: Think it all out ahead of time.
People have mentioned UML diagrams and in other posts have mentioned drawing things out. Even my coworker today showed me something he had drawn out about his plans for a new feature. Made no sense to me, but then again I can’t really read hand-written Kanji. So different from typed Kanji…

It may just be me, but this just does not work. UML diagrams just result in me not wanting to make improvements to the code because it would mean extra work updating the UML.

Drawing things out doesn’t help me personally either, even if it is in English. It is just more natural and easier to keep these things in my head until the whole plan is fleshed out. You may not be able to do this until you have more experience, but I can’t say that I recommend UML and friends either. I would recommend just gaining the experience necessary to think in code.

B: The goal of my site is to provide this kind of insight, even if I don’t have as much time as I would prefer to blog about all the things I want to mention. You may still find something useful there.

C: See my answer to #1, #2, and #3 above.


L. Spiro

[Reactorcore]

Thank you so much for your replies, everyone.

@ Canvas: I'm doing this in C# while using the Unity3D engine.
The things you talk about are pretty much the SOLID principles I've read somewhere, which reinforces how important they are.


@ DevLiquidKnight: Alright, UML will be useful, but not until I know how to design the architecture in the first place, so those books you recommended will be the first step.


@ Zoomulator: Your answer was very helpful. This is exactly the kind of information I was asking for, especially this bit:

Doesn't have to be UML, just atleast graph it out on paper so you have a rough idea how things are connected that is clear to you (and the future you). Some people like going with the top-down approach, all the way down. I don't remember which book it was that described the process, but it went something like this:
Start with a general overview of the whole system. Then for each object, make a general overview of it that's more specific. Re-iterate until it'd be easier to code it than to describe it, and so code it.

Also I really like how the event driven system sounds and is exactly what I'd prefer to build. Can you give any pointers on how you start building such architecture?
Again, I'm doing this in C#, if it matters.


@ L. Spiro: While I do agree with you that experience is a great way to learn, I'd argue that a good preparing education is a even better. Even now, I could just go ahead and start cowboy coding blindly and get something working, but it will be a mess and not robust, which is vital to this project of mine, because its meant to last.

I'd rather spend time studying and understanding how to properly use the tools I've got and have good understanding of healthy coding principles before starting to build anything. Doing otherwise is pretty much the same thing as shooting yourself in the foot. It will be frustrating and the end result won't be good either.

Sure, you could refactor constantly if you choose to develop your game in this brute-force like manner, but in the end that will also take time and effort, which you could have used to study the subject properly in the first place. Thats my opinion on this.

Anyway, I find your blog really helpful and not just the links you posted too, you've got some other very neat posts there too like, this one and that one, so I'm going to spend a good amount of time reading your blog, so thank you for writing it.

Edited by Reactorcore, 04 July 2012 - 07:54 AM.

[Zoomulator]

I really like how the event driven system sounds and is exactly what I'd prefer to build. Can you give any pointers on how you start building such architecture?
Again, I'm doing this in C#, if it matters.

Well, I'm using C++ and I don't know what extra tools you get in C# at all, unfortunately. This article inspired me a lot for my current event system. What I've done most recently is to wrap an interface such as this around ØMQ, allowing me to fairly safely send complete objects as messages. Using ØMQ allows it to be either thread safe in-process messaging, inter-process or over TCP almost completely fluidly. ØMQ is blazing fast too and optimized to take some million requests a second on large servers but still really easy to use compared to handling classic connection sockets. There's C# api (and many others) but I can't vouch for it. It's also not all that common in games from what I understand.

The basic idea anyway, is to have listener objects registering to a dispatcher object. It's basically the observer pattern, but a bit more centralized. You register to certain 'global' events, rather than all events from a specific object. Any object wanting to send an event does so via the dispatcher. Fight the temptation of making it a singleton though.

Event systems have one downside, especially if you're using one big (or a couple*) central one(s) such as I do. It's not very performance optimized, since you've got a big middle hand between all objects that communicate via it. The flexibility added usually outweighs this problem imo and the more performance intensive algorithms are usually isolated in one of the modules. But keep in mind that they can be saturated if there's a lot going on in a real time game.

I'm using two dispatchers in my current project. One for strictly local application events, such as window, input and inter-module communication (I've got a server object running on it's own thread). The other one is for the game events which the rendering and network listens to.

There's also a few varieties of how and when to handle the messages. You can put messages into a queue and poll them when it's the objects turn to update. This is what I do with my ØMQ version. This means the queue has to be handled at regular intervals. A second and not very thread safe way is to make them call instantly. My first did so. The message handling took place inside the send method of the dispatcher, as it looked up and triggered the event handlers of the listeners. It's a matter of taste and need which you'll chose.

Since you're not familiar with the concept yet I'd recommend not to use ØMQ or threads for your first few projects. Make a simple 'instant' message dispatcher and tweak it until you're happy with what it's capable of doing. When you feel more comfortable with that, move on to the more advanced and flexible ones.

Edited by Zoomulator, 05 July 2012 - 05:42 AM.

[Reactorcore]

Event systems have one downside, especially if you're using one big (or a couple*) central one(s) such as I do. It's not very performance optimized, since you've got a big middle hand between all objects that communicate via it. The flexibility added usually outweighs this problem imo and the more performance intensive algorithms are usually isolated in one of the modules. But keep in mind that they can be saturated if there's a lot going on in a real time game.

This is something I was very curious of when I was reading out about delegates and events, turns out that yes there is an overhead when doing this. I don't know if I'll be using events for the entity system, but two areas where events seem to be very good for are the menu system, which one should be able to evoke anywhere, even during gameplay, and the other is the metalogic of the game that deals with win/loose conditions as well as other major events happening during gameplay.

Not sure about the whole ZeroMQ thing. If I understood right, its something you can use for networking in your game, either between 2 programs on the same machine or between 2 programs over different machines? My game will not have online multiplayer, so I'm not entirely sure if its for me.

[Zoomulator]

About performance: It still requires a very large amount of events before it's bogged down and as I said: it's not always the event system that needs to be fast. The logic gets a message, it does something that's probably pretty heavy relative to the actual event transmission and then it sends it's own event. The most performance will most likely still be required in the logic itself and the observer pattern will most likely remain one of the better options for that, since it's more direct. The best way is simply to stress test your event system if you're unsure and see how many calls to how many handlers you can pull off per second. If it were to happen that an event system would be saturated you can lessen the load by batching and revisiting the need for some events. It's likely you can stretch it quite far. All I'm saying, don't write it off until you've tested it for the current case.

I'm using events only as a glue between input handling, logic, networking, rendering and other systems. You can use it internally in the logic as well, but that could become a performance issue a lot faster. There's another issue of event systems: it can make the larger picture more difficult to follow and the order of execution between events may not be explicit which can cause determinism issues. This is especially true if used in the game logic because it tend to become quite intricate. Using it just to notify other systems keeps it rather simple.

An event system can also help if you plan on adding some sort of scripting. The scripting engine can be detached and communicate with the logic via events, rather than littering the logic with the scripting. Same with AI, which most likely will be using some scripting itself. Make higher level functions in the logic be accessible via events, and both GUI and scripting will be able to access them easily.

About ØMQ: it gives you a highly efficient queuing system. I'm mainly using it because it lets me have a thread safe messaging system. ØMQ's context is completely thread safe which makes it possible for different threads to pass events between them. If you keep the messaging system the only means of communication between threads, it practically removes the issues with race conditions and many other problems related to threads. It's not a holy grail of multithreading, but I find it fitting for my purposes and you might not. Main issue would be it's asynchronous nature, which isn't as efficient in a single threaded environment.

I see the possibility of networking as an added benefit. I lay out the structure of my game so that communicating with a remote client is virtually the same as communicating with the local neighboring thread client. It sends the same messages, only via a different pipe. ØMQ will also gladly take any number of channels to communicate, meaning an indefinite number of clients (network or threads or just objects) can be added with relative ease. I've heard claims of some mmo's using ØMQ and that it was quite sufficient, but I can't really back it up..That's enough of me selling ØMQ for now =P

I'm not making a real time game, which wouldn't be as simple as just 'hooking it up remotely' the way I put it. You have to do prediction algorithms and other jazzy stuff.. a good reason why network multiplayer is such a pain in most cases.

But as I said, it's probably a good thing to wait with ØMQ anyway but it's good to know that it's there.

[Reactorcore]

I've never heard of a queuing system in programming before, what would one use it for and why?

The game I'm making is a singleplayer-only real time action game and it is not scripted in any strict way, besides how you start and how you end. You are put in a world, given a character and a big goal, which how you complete it, is completely up to you using the environment and other stuff you have. So from that standpoint, I could guess a queue system would be important for a game that is story driven or very scripted in how it unfolds, so in my case it would be irrelevant, right?

Sorry if I sound stupid, I'm a bit of a newbie-in-the-process-of-learning when it comes to programming.

[Zoomulator]

In simple words, a message queue is where messages are stored until they're handled. Call it a buffer if you'd like. If you've ever used SDL, its events are put into a queue, which you pull the events from at a good time in your main loop. A message queue is required here because your program can't just stop in its tracks when ever SDL receives a new input and asks your program to handle it. Instead, you get the option to look at it later.

This is called asynchronous message handling. You fire off an event and it may be handled at what ever time the receiver thinks is a good time. Much networking works like this and things like Node.js make use of it to a great extent.

The opposite is synchronous message handling in which case something fires off the event and wont continue execution until the event is handled. No queue is required here, because the receiver will only handle one message because the sender wont be able to send more than one message at the time.

Apart from being essential for networking and multi-threading, a message queue can also be used if you want to send events that wont be handled until the next game turn or "tick". Of course, a message queue can be polled at less frequent intervals.. I don't have much say in that. But the most normal use would be for it to handle events each iteration of the game loop.

Edited by Zoomulator, 06 July 2012 - 02:42 PM.