3D Game Development tips (especially game architecture)

Question

tl;dr version: What is the best advice (that you learned by experience and not from books) that you can give me, with regards to 3D game architecture? (as in, how to design and connect the components of a 3D game)

---

When it comes to programming, there is only so much you can learn from books. It seems to me, many of the things learned are learned from other people, or by experience. Even learning something in a classroom has its advantages over books; the professor might slip in a little tidbit of knowledge that he learned from his experience, and it can make all the difference.

I'm looking for those tidbits here.

Books on game development only go so far. There's a big difference about a book that explains the logic and syntax of a programming language, and a book that tries to tell you how to make a game. The latter doesn't work so well (at least for me); but the former is the whole reason I'm studying computer science.

I am going into my second year of college, and I'm 19 years old. I don't have experience, I have book knowledge. So I'm trying to piggyback off of you and your knowledge that you've gained from experience.

My current topic of interest is game architecture.

(or "engine design" if you prefer, though I'm not looking to create a everything-but-the-kitchen-sink game engine)

I recently asked a question, Data structures for message passing within a program? and it resulted in a long, excellent answer from haffax. To him, he was just rattling off his experience and the knowledge he's gained from it; to me, it gave me many new things to think about that I had never read in a book before, and haven't experienced for myself. Go check out the answer, and up it if you like it.

From it, I thought more about message passing within a program. I thought about how perhaps MVC is not a good fit for game architecture. His concepts of all game objects being equal and not a hierarchy, where instead you add "Features" to a game object, is something I've never heard before, and I really like it. And right at the beginning of the question he gave simple bits of advice:

Before starting to design any of the packages and classes, start with an analysis

...

And for motivation, I speak from experience here, don't think of your task as writing a game engine, write a game!

I want more answers like that.

What are the most important game architecture concepts and tricks that you've taken from your experience as a game developer? When you sit down to write a game, how do you organize things? Do you separate your view and your model, or do you intertwine them and refactor later? What do you want to say about the effectiveness of MVC as a game architecture pattern? How do you keep track of so many things (graphics, audio, file loading, collision, AI, network) and make them all work together to create a finished game? How do you use design patterns and preserve the object oriented-ness of your game? How do you write automated tests for your game?

I can come up with a million questions, but right now I just want to hear in general, whatever sticks out in your mind. What sort of experiences have you been through that changed your thinking? What is your philosophy when writing your games? How do you stay organized amidst the confusion and the massive-ness of the task of 3D game creation?

What game development tricks have you learned from experience?

Thank you for taking the time to read & respond!!

Answer 1

Premature optimisation is the root of all evil.

This cannot be understated. Focus on doing things right from an algorithmic / maintainablity POV, readably. Once things are running, you can profile to find bottlenecks, testing the optimised versions against your readable reference code; but resist the temptation to speculatively make low level optimisations that add risk / decrease robustness / sacrifice readability, or indeed before the high-level goalposts have stopped moving to make them at all.

Answer 2

Make damned sure you have a proper texture manager before you go about creating a 3D game. I made this folly, and it was hell in the end.

*Note from creating a "DOOM" clone for a final project in my graphics class...in JOGL.

Answer 3

If you're doing something solo, and even if you have a group, try to get a first iteration done as soon as possible. This isn't so much about 'seeing if the idea is any good', or proving the concept or anything; it's purely motivation.

If you develop a fantastic and perfect idea, and begin implementing at the lowest level up, it may be weeks/months/years before you get to first run your amazingly perfect game. Time Units in which it is easy to get distracted, to move on to other projects, or to infinitely change the specs for the current project. Having something in front of you that runs lets you say 'this is cool, but it would be better if it could do X'; and you now have a stronger motivation to implement X.

I say this mostly from hobbyist experience; so doesn't fully apply to 3D game architecture. Though, coincidentally, this very reason is why my current project (logic/backend for a 3D game) has been on hold these past few months. Curse my desire for both sleep and a paycheck.

Answer 4

1. The rest of my list maybe crap, but the most important thing is to just do it. You want experience making games, so make a game. Make your goal to complete a game, not just work on a game.

2. Start simple and make progressively more complex games. Simpler games are easier design and actually complete. The lessons you learn will help you design more complex systems. 'taint no shame in making 2D games or clones of existing games.

3. Follow the Solid priciples of object oriented design. You sound like you want to unit test. Solid priciples are key designing testable objects.

4. Only use design patterns to solve problems. For instance, you may be tempted to use a singleton for an object with only one instance. Having only one instance of an object is not a problem. Lets say you want to unit test your game logic without your display logic doing anything, then MVC solves your problem.

5. Do what works for you. I track my progress with note cards arranged as a todo list on my wall. For a single person project, todo lists work very well.

6. Become friends with art students.

7. Find or start game making club at your school. Work together to make simple games.

8. Old wizened authors tell you aspired authors that they have to write one millions words before they can write one worth reading. I think there's an analuge for designing games. I'm not old or wizened yet, but I say be prepared to design and complete ten games before you get praise from random strangers.

9. Use source control. I'm a big fan of Mercurial using the TortoiseHG client.

Answer 5

I like a lot of the answers so far and want to throw my two cents in too.

There are a lot of game makers out there that well you to make what you would find fun. If you hate puzzle games, don't make one. You will not enjoy the fruits of your labors and get tired of it. Many good tools and games were made this way.

Plan out what you want to do first. Many people start right in coding, but a little planning helps to save time later. This does not mean to not do prototypes or test something out - just be prepared to throw it all away. I am personally working on an iPhone game right now and it is an entirely different world from working in the .NET one that I normallly work in. But I planned out what I want to do and am working towards that (hope to be done in a couple weeks).

Plus then the plan that you have will tell you when you are done. That is something that many projects have a hard time with. "Can I make this better?", "If I tweak this other thing abit...", etc all delay getting your game done. All programs can be better. All have bugs here or there... Just know what you want to have ans stick to it. If you change your mind then look to see how that changes your plans.

Designing games and writing the game are definately two different things. One game I worked on had a professional comedy writer that was writing the storyline. He did a much better job than anyone else could have at coming up with the jokes and scenes that were part of the story of the game. If you are going to do it all yourself, that can work, but keep in mind that there is a difference for each part.

Don't be afraid to use someone else's game engine. There are a number of free game engines or graphic systems out there that you can use to start from. Writing a 3d game engine is something that takes a long time and takes many people to get done. Using a different game engine and just coding your parts is much simpler.

Answer 6

The following tips mostly apply to larger games where you have programmers, artists and designers all working on a game. They might be overkill for one person making a simple game on their own but as soon as you get to the point of having a team working on the game they start to be important.

• A feature is only as complete as the tools to use it. It's no good implementing some super sophisticated technique if your artists have to hand edit an undocumented text file to use it. You'll get better results out of a simple feature with a good tool that allows the artists to experiment and to iterate rapidly than out of a complex feature with no editor support.

• Related to the above, iteration times are key to good results. Always consider how quickly and painlessly the people building the game will be able to make tweaks and test them when designing a feature. If it is inherently slow to make changes (offline global illumination calculations for example) then try to provide low quality or localized previews that allow at least some amount of feedback with fast iterations.

• Prefer to keep complexity in the tools and pipeline and keep the runtime code simple. This is particularly important when targeting consoles or multiple platforms. If a complex chunk of code is only required when editing a level then keep it out of the game code. This means a smaller code footprint, easier porting and less testing.

• Design your code to be data driven. Anything that might need to be adjusted or tweaked should be a parameter that comes from data, not hard coded. This goes beyond simple things like avoiding constants and putting them in a data file and extends to allowing designers to set up complex gameplay conditions in scripts or using a visual scripting language. Designing your code around your data also tends to help when trying to multi-thread systems and take advantage of console hardware.

• One slight downside of data driven engines is that they can be hard to debug. Take this into consideration when designing your systems and put in extra functionality to help you understand what's going on when problems inevitably arise. You'll thank yourself later.

Answer 7

Eberly's book.

That is all.

Answer 8

Here's a couple of observations I can make based on two months of intensive studying, designing, and coding on the matter of game engine architecture alone:

• The 3D graphics engine is a small part of the overall game engine

  • Description: The graphics engine merely creates the visual representation of the game. The graphics engine's functionality should be encapsulated into the view component so that it will only receive update events from the game logic through the event manager. This way the game logic does not depend on the graphics engine, which means that the game logic can be detached and used in other systems eg. when porting to different platforms.

• The game engine is a small part of the overall game

  • Description: The game engine is a platform that allows game development but in itself the game engine does not do anything. The game is a construct that lives in the game logic, which is a component consisting of interacting entities. The game itself requires its own design which has nothing to do with the game engine.

• To do proper game development you should understand proper game architecture

  • Description: Without a proper architecture your game is likely to result in a procedural tangled mess that reeks of high coupling. This is what most game programming examples normally look like where the game loop does a million and one things.
  • Solution: Stop for a minute to think about how things should work as a whole before you start coding straight away.

Here's some example code from our game engine (to be released as open source when we have it ready enough):

def tick(self, deltaTime):
  """
  Advances the game forward one tick of length deltaTime (seconds).
  """

  if self.state == K_GAME_STATE_RUNNING:
    self.processMgr.updateProcesses(deltaTime)

# end tick()

This is the game loop (called tick) in the game engine we're currently developing. In it we merely run through all the active processes the game logic has. The processes themselves affect the state of the different game logic entities by sending different types of events through the event manager. We don't use direct method calls in the processes or game entities because we want to keep the code uncoupled in that respect.

• Have the goal of creating a game, not just an engine

  • Description: As previously stated, you don't have much to show or play around when all you have is an engine. The ultimate goal should always be to create a game.

• Optimize when there is a problem, but no sooner.

  • Description: When you find yourself optimizing something before there is a visible problem you are shooting yourself in the foot in terms of productivity. It is oh so easy to keep dabbling on a very concentrated problem and optimize the solution until perfection but this will only lead to lost time in the long run.
  • The solution: make a note about your suspicion and move on to something else that has a high ROI.

I'm still a beginner in game development however, but during this summer I've been involved in a project where our goal is to create a simple first-person adventure game for the purpose of teaching a practical introductory course in game development.

We've found the Game Coding Complete book by Mike McShaffry to be highly useful as an overall guide and as a reference for understanding how games should be architected to allow for an extensible and highly decoupled design.

I cannot recommend this book more. If game engine architecture is your forte, and any of those points above resonate with you I suggest you at least take a look at it. I have a feeling that you will like it a lot and learn tons from it.

Here's an excerpt from the book (Chapter 19, pg. 739):

"As I'm sure you are aware, Game Coding Complete is really an architecture book that paints broad strokes through a vast array of tools and technologies that make up professional computer gaming. One of the observations about the first edition of this book, and I'm sure of this one, is that the book doesn't cover each subject in rigorous detail, completely exposing every last bit. That was by design, not fiat."

"Sometimes the hardest part of writing code is knowing where to begin. Once you get started and build a suitable framework around a new system, your fingers fly across the keyboard until numbness takes them, and still you don't stop. My goal with this book and all the code therein was to give you some interesting tidbits, save you from nasty pitfalls, tell a few funny stories, and cover as much territory of game programming as I possibly could."

"I have also given you, my valued reader and colleague, a place to start."

My quest is to uncover the mysteries behind game engine architecture and utilize that knowledge to build awesome games :)

Hope this answer helps you in some way. I can continue with more of these points in my blog when I get around to write it.

Answer 9

3D game development is a whole different animal compared to traditional software development as I have learnt in the past year. I also own a copy of the Game Coding Complete book. I must say its a must have for anyone looking to building games. Most books on the market do a terrible job at teaching game programming.The current books either talk about some game engine or delve deeper into the API of some language. That said, here are a couple of things I think you will need to get familiar with.

Graphics Engine : This is the code base that draws everything on the screen and in this case you have got 2 options DirectX for Microsoft windows and OpenGL for every other platform out there. OpenGL Super Bible is a good resource for learning OpenGL. The book uses C as its language of implementation as OpengL APIs are C-based.

Physics Engine : If you are planning to have physics in your game, you will need to either code up a physics engine or use a 3rd party library, common ones are ODE Physics && Box2D.

Audio Engine : You will need some audio in the engine, I dont know of any good library for this.

Networking Engine : If you need networking for you game Raknet is a good library for that.

Windowing & Input : You need to handle input and windowing for your games too. SDL and SFML both have these in built to them.

All these libraries are in C/C++ but you can also go an easier path by using some ready made engines like SFML or SDL. Good luck on your journey.

Answer 10

The best advice I can give is to just write what you need at the time. Don't think too hard about it, otherwise it won't get done.

You can always refactor the useful bits after you've just written a game.

-Tom