Reddit mentions of Game Engine Architecture

To expand on what /u/LordNed said...

Your project is too big for a first project. Aim smaller than you think you should. Start with something like pong or tic tac toe, make that work, then do something slightly bigger.

I hate to break it to you, but most of what you learned in school is not going to be applicable to gamedev, and worse, you'll likely have a lot of bad habits you'll need to unlearn. The state of CS education in general is... terrible.

To answer a few of your questions:

1. GLUT is outdated and terrible at this point. GLFW is a good choice. I personally find SDL a mess, but I've been told SDL2 isn't so bad. If you're directly writing your own rendering code, openGL is the way to go for that. BUT, you should strongly consider looking at existing game engines and libraries. There are a ton of them out there, ranging from full engines like UE4, Unity3D, and OGRE, to basic 2D rendering engines like cocos2d-x, and many in between.
   
   
2. VisualStudio is the best debugger you're going to find, and learning how to debug well is one of the most important things you can learn. A lot of people are not fans of it's text editor and intellesense, so not everyone likes using it as their IDE.
   
   
3. Game Engine Architecture is the best book I've found on the subject and is great as both an introduction to those new to game development, or as a booster for those wanting to be more than a junior programmer. I recommend this book for anyone getting started in game development. I recommend this book even if you're not writing engine tech, just to understand what is going on (and it covers more than just low level engine stuff). (I have more recommendations, but you should really start with this book)
   
   
4. Shaders are a deep rabbit hole. When you eventually get to the point of needing to consider this, start simple. Always start simple with everything. I wouldn't recommend digging in to this type of thing unless you're doing it just because you feel like spending time learning and playing with shaders.
   
   Start simple!

For more by Jason Gregory, he wrote the excellent Game Engine Architecture which covers a few of these bits in detail as well.

Not sure I like the no producer thing personally. Isn't their job to make sure you can just get on with the skilled job you are being paid for while they take care of (read: delegate to minions...) the day-to-day generic tasks that would otherwise bog you down?

I'd recommend Game Engine Architecture.

However I wouldn't worry so much about messing up. If this is a solo project then it's a great learning experience precisely because you have room to learn from your own mistakes-I know there's a classic programming quote which sums this up perfectly but I can't recall it just now.

Things change. Expect to refactor your code and rework your design later, and aim to make it easy on yourself when that happens rather than having a perfect but inflexible solution first time.

Hi PizzaPartify,
I believe that different companies/teams will place emphasis on different skills. When I was helping to hire software engineers for EA's motion capture studio, I liked to see candidates who showed a strong aptitude for engineering code to be maintainable. For me, this meant a familiarity with design patterns and software development processes (like Test Driven Development or Extreme Programming). In my department, much of our code was in C++ and Python. However, other departments would use languages like Java, C# or ActionScript - depending on the project.

It would be helpful to know what role you are applying to.

To answer your specific questions:

1. If you're already familiar with C++, I would highly recommend reading Effective C++ by Scott Meyers (http://www.amazon.ca/Effective-Specific-Improve-Programs-Designs/dp/0321334876). Every C++ developer should read this.
   
   Regardless of the language you're working in, I would also recommend Design Patterns by the gang of four (http://www.amazon.ca/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612).
   
   A game-specific recommendation is Game Engine Architecture by Jason Gregory (http://www.amazon.ca/Game-Engine-Architecture-Jason-Gregory/dp/1568814135). It doesn't matter if you intend to write an engine or not, it is immensely helpful to understand how they work.
   
   I own all of the Game Programming Gems books but use them more as a reference library. The books above will be more helpful right now.
   
   
2. I worked with Unity only briefly to prototype a game, so I can't really comment here.
   
   
3. This is tricky. I think you will need to find a passion project in C++ so that you will just naturally learn more about the language. And speaking of passion: you need to really want the job you are applying for. I have seen qualified developers miss out on jobs because you could tell they were just looking for anything (rather than really being enthusiastic about the position).
   
   I hope that helps.

You're conclusions, and some of your facts, are wrong.

I literally write game engines for a living, I know about everything you just tried to explain, and it has nothing to do with my point. A 3d version of Factorio (e.g. from scratch see edit 2) could have the same number of game updates regardless of how expensive rendering is because they would be on separate threads. Even Unity and Unreal have separate rendering threads, it's been this way for 5+ years.

Vulkan, DX12, and Metal all enable multi-threaded rendering, because older APIs would only allow a single thread to submit commands at a time. But they have nothing to do with the division of rendering and game logic into separate threads.

Edit: I own a copy of a Game Engine Book from 8 years ago that called one render thread, one game logic thread, standard industry practice.

Edit 2: Also, this FFF explains how they do have many different threads, for example, updating game logic and rendering at the same time.

Here's my general advice as someone in the AAA field as a programmer doing it for many years.

1 -----------------

If possible, think of your game in modular bits and primarily concentrate on the programming aspects. Block in the visuals with placeholder art if you need to, but a game with good design and mechanics doesn't need fantastic art to be fun (unless your game is animation driven or atmospheric like Dark Souls).

If you break your code into modular bits, you can tackle each part piecemeal and it's a lot more fun to work on. "This week, I feel like making a great input system. Next week, I'll focus on a data-driven AI engine", and so on.

2 -----------------

Keep things realistic. Understand what you can achieve and don't attempt to make a game that can do absolutely everything. Unless you actually want to spend decades making your game, you need to focus on actually finishing the game at a certain point... maybe. If your game follows the dwarf fortress model of being a perpetually unfinished game that you're always working on, that's also fun. Understand what you're getting into though if you go that route.

3 -----------------

Despite what you may think, ideas are not terribly original. It's all about execution. There's TOOOONS of indie games that are extremely successful and use an idea I had been thinking about. Unlike me though, they actually made the game and had the design sense to give it the production value necessary to sell well.

4 -----------------

If you're hungry to make something now, don't lose a hold of that. Keep learning in your spare time. Buy programming books off amazon to supplement your coding ability. I wasted too many years in university playing video games and not enough time learning to be a better programmer. A good high level starting book that can help give you an understanding of the overall picture is this: [Game Engine Architecture by Jason Gregory] (http://www.amazon.com/Game-Engine-Architecture-Jason-Gregory/dp/1568814135)

Just as you need to learn construction before you can build a house, you need to learn how to program properly before you can make a game. Keep focused and try to shorten the years you need to spend learning by reading books.

5 -----------------

most important unless you're working with a large team, don't worry about having perfect code the first time through. No matter what you do, it's not going to be correct. Try to do it to the best of your ability, but if you worry too much about clean code, you'll suffer from "perfection paralysis" and ultimately end up not finishing anything. This was another one of my mistakes when I was younger and I still catch myself doing it nowadays on occasion. Sometimes making mistakes is the only way to learn.

Don't be afraid to do things the wrong way first.

edit: grammar, added a link to a great book (no, I'm not the author)

https://www.amazon.co.uk/Game-Engine-Architecture-Jason-Gregory/dp/1568814135

https://gameprogrammingpatterns.com/

http://www.amazon.com/Game-Engine-Architecture-Jason-Gregory/dp/1568814135

Game Engine Architecture is a great book for learning about engine design.

I haven't read it, but I've heard good things about Jason Gregory's Game Engine Architecture.

People talk about prototyping games a lot. Like, you have an idea so you build out a simple example so you can play it and see if it's fun on a basic level.

But what they don't really talk about, is prototyping code. It's hard to figure out how things fit together in a meaningful way if you don't already know the coding conventions or patterns that can help you build them.

As a self taught programmer whose work includes a good deal of coding now, I've gotten a lot of use out of building out small 'hello world' type examples of more complicated code structures.

Imagine you're trying to build a skyscraper, you wouldn't just try and build it straight out of your head, you'd follow a kind of miniaturized version of it, a blueprint. So that's what you should do as a programmer, make blueprints. Don't just make blueprints for your whole game, make blueprints for even the smallest sections of it if you don't feel like you completely understand it.

My wife is a senior-level project manager for a really large construction firm and her projects typically cost somewhere in the range of $500 million. When she's on the job-site supervising a part of the build, she doesn't refer to the blueprint for the whole project, she uses the blueprint for that specific part of the job. So if you're having trouble figuring out how to properly break a python game out into modules, don't look at coding examples of full games because you'll just find it overwhelming. Look for simple examples of python imports and module structure. But more importantly, build small examples of how that works using those examples to make sure it works how you're expecting.

Think of the game you want to make, and form some basic ideas about how it should fit together. Read up on programming patterns, game engine architecture, or artificial intelligence for games and whatever other topics interest you about game design. Make small code projects prototyping concepts that are interesting. I have a project folder on my computer that is filled with small examples of programming patterns, complicated data structures, skeletal game structures, and anything else that can serve as a blueprint for building something else.

So if you're reading and come across Entity Component Systems (ECS), and you think that theoretically sounds like a good way to build your game, don't start by trying to build a game using ECS. Build a prototype of an ECS pattern. Something really simple and instructive of how you would do it for a larger project, a blueprint.

For example, this is the actual code I wrote when I was prototyping one of my favorite patterns, the Service Locator.

class Service:
_audio = None
_graphics = None

@staticmethod
def playermoved():
if Service._audio:
Service._audio.play_footsteps()
if Service._graphics:
Service._graphics.animate_player()

class Audio:
def play_footsteps(self):
print("Pitter Patter")

class Graphics:
def animate_player(self):
print("Look at the player move")

audio_system = Audio()
graphics_system = Graphics()

Service._audio = audio_system
Service._graphics = graphics_system

Service.playermoved()

And if you read the description, you'll see that this example doesn't really fully articulate the pattern as described. But that's okay, because the point of the code blueprint is to experiment with implementing concepts in a way that works for you.

.FBX is one of the most used formats in the industry, what usually happens is the artists output their work into .FBX files and either the engine loads it directly, or will convert it to a proprietary format that's most efficient for their engine. Unfortunately information on .FBX is not publicly available so you have to use their SDK.
http://usa.autodesk.com/adsk/servlet/pc/item?siteID=123112&id=10775847
http://docs.autodesk.com/FBX/2014/ENU/FBX-SDK-Documentation/

.OBJ is not a suitable format for animation it's only good for defining meshes and materials. A very good library that removes all the hassle of format loading is Assimp: http://www.assimp.org/

Lastly, animation formats don't store individual vertex positions, it will store matrix transformations. It's worth looking into how animation is done, I don't have any links but I would recommend looking at the following books:

https://www.amazon.co.uk/d/Books/Game-Engine-Architecture-Jason-Gregory/1568814135

https://www.amazon.co.uk/Game-Coding-Complete-Mike-McShaffry/dp/1133776574

CD/CR is:

• Collision Detection
  
• Collision Response
  
  Are you asking about World-Entity or Entity-Entity collisions?
  
  CD/CR is usually done in UpdatePhysics() inside the Game-Loop
  
  

• For each entity
  
• Calculate Forces
  
• Update position, velocity, etc.
  
• Test against World collision volumes / hulls / tiles / mesh
  
• Test against other Entities -- do CR
  
  There is no "single" answer - you can do it either way:
  
  
• Level_DoPhysics( vector< Entities> entities, deltaTime );
  
• Entity_DoPhysics( Level level, deltaTime );
  
  You'll probably want to batch up processing entities, and split them into a before and after phase:
  
  
• Current Frame
  
• Next Frame
  
  Other search terms are: Broad Phase vs Narrow Phase
  
  There are a couple of books you'll want to look at
  
  
• Real Time Collision Detection
  
• Game Physics
  
• Game Engine Architecture
  
  Edit: Added deltaTime to DoPhysics()

In terms of "tying it all together" I recommend this book - http://www.amazon.com/Game-Engine-Architecture-Jason-Gregory/dp/1568814135

It covers game engines in a pretty general way, a light overview of every part and what role it plays in the whole. If you're having trouble figuring out architectural questions like what a game loop should look like, this book will help a lot imo, maybe faster than source diving in other roguelikes.


Outside of resources like that, I'd suggest just starting even simpler than a game loop. Draw a field of '.' to the console. Draw an @ on top of that. Make the @ move. One thing at a time, and your game loop will build itself.

I've found Jason Gregory's Game Engine Architecture a great read, was recommended to me by the program director of a game development masters program.

I kind of sounds like you're whining.

go to /r/gamedev

If you know how to program effectively and you want to do something solo. Learn how to Art. If you know how to Art, learn better programming skills.

here's some of my favorite book recommendations

Programming:

Game Coding Complete

The fucking bible as far as books on game development goes. Made by one of the senior developers on the Ultima series. Seriously. Good book.


Game Engine Architecture

Also a really good book, teaches you more about usability beyond yourself if you ever find time or reason to expand your team.

Art:

Drawing on the Right side of the brain This is a very good text for getting you out of your comfort zone and into the mindset you need to have to do good art. This book won't teach you how to make good art, practice will, but its a good first step.

I'd also start looking around, take a look at Blender, we have a great community at /r/Blender and start learning how to do modelling, theres some great tutorials on the gamedev subreddit, as well as a number of classes on Programming and one on Game Concept art at University of Reddit.

Now get up off your ass and start building a game. Pixel. By. Pixel.

and if you have any questions, shoot me a pm, I'd be glad to help!

/u/rampion already made a great recommendation of Charles Petzold's Code that I highly recommend. Another great one is Tao Te Programming which is barely a book (in terms of length), but is available for free online.

I also really loved Game Engine Architecture but obviously that's pretty niche. I have more and will do my best to add them later

Jason Gregory - 3D Game Engine Architecture is a great book although it does focus on C++, but the majority of the content is language independent and more concerned with architecture rather than implementation details.

And as noted before, Real-Time Rendering is a must-have.

Well worth the money: http://www.amazon.com/Game-Engine-Architecture-Jason-Gregory/dp/1568814135

Take a look at this book, it's very well written and covers very wide range of game-engine aspects: Game Engine Architecture by Jason Gregory:

http://www.amazon.co.uk/Game-Engine-Architecture-Jason-Gregory/dp/1568814135

http://books.google.com/books?id=LJ20tsePKk4C&lpg=PP1&ots=pW7UHKb70s&dq=Game%20Engine%20Architecture&pg=PP1#v=onepage&q&f=false

The common advice given to those new to game programming that want to develop an engine is to simply make games. Through the process of making a game you'll come across code that can be reused, and refactoring this code into a generic form will allow you to build up a library of useful snippets/classes/what-have-you and eventually an engine.


However, if you're curious about game engine architecture, there's a great book by Jason Gregory, Jeff Lander and Matt Whiting called Game Engine Architecture which describes the components that make up an engine and illustrate some design choices.

To be honest, I would recommend a low level functional book over a C# or C++ specific book that teaches you APIs. Most of the language/API specific books get hung up on details, work arounds and such rather than focusing on what is really important.
The mathematics of 3D programming or so was really really useful - it shows algorithms and goes into why certain algorithms are fast/slow and give good/bad results.

If you want API/C++ stuff, I'd go with
http://www.amazon.com/Game-Engine-Architecture-Jason-Gregory/dp/1568814135/ref=pd_bxgy_b_text_z

Very well written and goes into debugging and such as well.

Check out Game Programming Patterns, it contains lots of examples of how to write code with a good structure.

Game Engine Architecture is also very useful, but much more theoretical and heavy, but it explains nicely most of aspects of game engines and gives you a lot of ideas of how to approach different problems.

Don't halt your progress by just reading these books and starting only afterwards: they'll take a long time to finish. Start with basic things, for example Game Loop chapter. Make a simple, but good loop and start building things. Just get something playable on the screen first.

By the time you do it, you'll have some problematic code which you'll need to fix. For example, you may not be satisfied with how closely tied some things are. At that point you'll read about event queues and will find solution to a lot of problems.

And that goes for everything. You don't just start with perfect architecture, but with some experience you'll get an idea about what works and what doesn't. Some people write the same spaghetti for a long time and don't improve, but if you learn some good concepts, it's very unlikely that you'll ever return to worse practices.

And it's also very important to not follow bad coding practices: globals are mostly bad, spaghetti code also should be avoided. Don't write big functions, don't write big classes. Don't just hope that the code will become better just randomly. Having huge functions and lots of global variables everywhere makes it much harder to improve and refactor your code.

Feel free to PM me with questions about how to make your code structure better. I'm very interested in the topic and will be happy to help.

P. S. If you haven't read Effective C++ and Effective Modern C++, you really should. It's a great way to improve your code considerably.

I just got a copy of
Jason Gregory - Game Engine Architecture
http://www.amazon.com/dp/1568814135

There is the obligatory few chapters on "how to compile C++ with Visual Studio". I'm an experienced programmer and am just skipping that.

But the amount of depth across a broad range of core game concepts is really impressive. You can tell the author has worked on real production software and is wanting to share his hard-earned wisdom, starting with the important bits rather than the noob bits. For example, there's a great chapter on vectors and matrices, and great chapters on 3D rendering and lighting. A lot of books seem to stop there. But it's not baby talk, it assumes you have a decent high school math background, and for that reason there's room for chapters on many more topics.

A lot of it relates to 3D but 2D is often mentioned. A lot of it relates to C++. The reason is that that's the language used to get the most performance out of consoles and PC games.

This may or may not be what you're looking for, but if it is, I highly recommend it.

Some people do, but remember also, game engines are hugely complex pieces of code that aren't for the feint of heart. This book shows a good portion of what can go into it.

Remember also that engines such as Unreal, Unity, etc. allows you to actually make a game without worrying too much about the lower level systems. More time spent actually making the game vs planning low-level systems = fun

Not necessarily source code, but Game Engine Architecture is practically the Bible when it comes to this topic.

There's already a lot of great answers, so I won't go over all that again, but if you're interested in writing an engine, this is the book I used as reference material when I wrote mine: https://www.amazon.com/Game-Engine-Architecture-Jason-Gregory/dp/1568814135

Other than Real Time Rendering which /u/horsman has mentioned above, I would also recommend:

• Game Engine Architecture.
  
  ===
  
  As for learning math, I find it's easier for me to learn math while working on a project. Pick up a good vector / matrix math book, and write a software renderer. You'll get up to scratch with the necessary math in no time once you've put it to practical use.
  
  
• One Intro to Software Rendering
  
• Software Rendering School - Series of six articles
  
• cbloom's TLC article
  
  ==
  
  As for a list of awesome sites, just take a look here: http://www.realtimerendering.com/portal.html

It seems like you're on the right path. I started working with major engines like unity and UDK. In addition I started writing small game clones (Pong, Pac Man, Asteroids) in C++ using DirectX. Once I was comfortable with all that I started working on my own flexible/reusable engine and writing my own tools. Using Unity and UDK gave me a good idea of what sort of features I needed to support and helped me develop comprehensive use cases. The whole point is that it is really an individual process. I don't have a degree, just been developing in C++ for the past 15 years. Tons of good literature out there too! http://gameprogrammingpatterns.com/ http://www.amazon.com/Game-Coding-Complete-Fourth-Edition/dp/1133776574 http://www.amazon.com/Game-Engine-Architecture-Jason-Gregory/dp/1568814135. Those are some of the resources I found particularly helpful.

Jason Gregory's Game Engine Architecture is basically the de facto standard.

Consider starting with something general like Game Engine Architecture.

It's platform agnostic, so you can follow it using whatever.

Read OpenGL tutorials on the side and use something like SFML, SDL or GLFW to handle input / window management / context creation / etc.

Get a few books on the subject, they are a great resource to get you familiar with the parts that go into making a full engine.

http://www.amazon.co.uk/Game-Coding-Complete-Mike-McShaffry/dp/1133776574/ref=sr_1_1?ie=UTF8&qid=1370533326&sr=8-1&keywords=game+coding+complete

http://www.amazon.co.uk/Game-Engine-Architecture-Jeff-Lander/dp/1568814135/ref=sr_1_1?s=books&ie=UTF8&qid=1370533364&sr=1-1&keywords=game+engine+architecture

http://www.amazon.co.uk/Game-Engine-Architecture-Engineering-Applications/dp/012229064X/ref=wl_it_dp_o_pd_S_nC?ie=UTF8&colid=3D6S8DHCZFLJF&coliid=I301TVJ1BKHNZ8

Game Engine Architecture provides an excellent overview of how game engines work, from the ground up, in a way that's fairly accessible—that is, I understood most of what I was reading despite not having any experience programming at that level.

Also good:

Real Time Rendering

Real Time Collision Detection

I would go with <a href="http://www.amazon.com/Game-Engine-Architecture-Jason-Gregory/dp/1568814135/ref=pd_sim_b_2">this one</a>
It does not focus on collision algorithms and graphics basics, instead goes right into message architectures, entity systems and so on. It's my favourite game dev book and I regularly look into it as a reference.

You need to learn architecture. For this do NAND2Tetris and get some used architecture textbooks from the computer engineering department.

Caches are a big deal. People forget they exist, but you're going to need that knowledge in embedded. DMA's, or even normal memory reads, might only be coherant with some cache levels. That sentence should make you gag.

It gets worse when you start to think about concurrency; which you should, frequently, because it isn't the 90s anymore.

Get used to debugging. A lot. Learn practices that make that easier. I mean both learning archaic shit like ddd and writing unit tests, following best practices, etc. In embedded you're going to be violating best practices often, but it is important that this teaches you "... so the rest of my code is as clean as possible" than "... what's one more sin next to so many?".

Most architectures are the same nowadays but the GPU is a notable exception (though less and less each generation). Learn CUDA - use Udacity's course on the subject.

What every programmer should know about memory.

Start writing projects in C++. Go ahead and become a real C++ nerd. constexpr everything you can. You don't need other languages except maybe barebones Python, Bash, and the Turing complete language known as the Preprocessor. You'll learn ~what you really need to know of C from C++.

Get very familiar with 'Godbolt'.

Write for maximal performance. This is a dying art. You'll have a competitive advantage if you're good at it. If you don't become filled with rage by the word "premature" you're not optimizing enough.

Profile your damn code!

Profile your damn code, but with a different link this time!

Know your latency numbers.

Make SIMD a part of your daily life. You might not always have vectorization, but this is the easiest way to show you're capable of exploiting hardware features.

Computer graphics people are relatively well-respected by the embedded software community, and there is a lot of overlap as they use similar skills. Taking a detour through graphics is a good idea even if you don't plan to work in graphics. It's fun, too!

One way or the other you have to find a relevant application domain and solve problems in it... if not graphics try: video game programming, GPGPU, robotics, control systems, computer vision, animation, networking, VR/AR, and a bunch more.

Do not put VHDL or Verilog on your resume without first being sure you're masochistic enough.

Learn to start being very choosy in what advice you listen to. Most people solve problems under a totally different set of constraints, and what they'll preach until the sun burns out might be pants-on-head stupid for you.

You might already have picked up some of those funny ideas from being a web dev, so be on the watch for that.

The book Game Engine Architecture has a lot of real world wisdom from a much more relevant view, so read it.

Also, most people are taught in a way that is not really beneficial to an aspiring embedded SWE (e.g. Java schools). Most people have to learn that type of stuff as they mature as a programmer... hence the requirements. You can be hired into these types of positions right out of university, but you have to show a knack or focused interest in it.

And to be frank, it is just plain harder than web dev or slapping CRUD apps together, so fewer fresh grads would be able to do the work well even if they followed the 'right' path in university.

You can get some experience by writing on an embedded platform, but unless you want to probably shouldn't. The principles I am describing are more important.

Do one or two solid projects. Not dozens. Not perfect. Not amazing. Just one or two simple-but-pretty-good things in your portfolio, that show that you are not just a web dev or Java School Student.

Get relevant work experience as early as possible. Relevant means same skills, not same application domain.

Remember, it being hard isn't a bad thing. It is a barrier to entry that once you cross becomes a competitive advantage. The harder it is, the greater the advantage. Always double down on the hard technical skills.

Game Engine:

Game Engine Architecture by Jason Gregory, best you can get.

Game Coding Complete by Mike McShaffry. The book goes over the whole of making a game from start to finish, so it's a great way to learn the interaction the engine has with the gameplay code. Though, I admit I also am not a particular fan of his coding style, but have found ways around it. The boost library adds some complexity that makes the code more terse. The 4th edition made a point of not using it after many met with some difficulty with it in the 3rd edition. The book also uses DXUT to abstract the DirectX functionality necessary to render things on screen. Although that is one approach, I found that getting DXUT set up properly can be somewhat of a pain, and the abstraction hides really interesting details about the whole task of 3D rendering. You have a strong background in graphics, so you will probably be better served by more direct access to the DirectX API calls. This leads into my suggestion for Introduction to 3D Game Programming with DirectX10 (or DirectX11).



C++:

C++ Pocket Reference by Kyle Loudon
I remember reading that it takes years if not decades to become a master at C++. You have a lot of C++ experience, so you might be better served by a small reference book than a large textbook. I like having this around to reference the features that I use less often. Example:

namespace
{
//code here
}

is an unnamed namespace, which is a preferred method for declaring functions or variables with file scope. You don't see this too often in sample textbook code, but it will crop up from time to time in samples from other programmers on the web. It's $10 or so, and I find it faster and handier than standard online documentation.



Math:

You have a solid graphics background, but just in case you need good references for math:
3D Math Primer
Mathematics for 3D Game Programming

Also, really advanced lighting techniques stretch into the field of Multivariate Calculus. Calculus: Early Transcendentals Chapters >= 11 fall in that field.



Rendering:

Introduction to 3D Game Programming with DirectX10 by Frank. D. Luna.
You should probably get the DirectX11 version when it is available, not because it's newer, not because DirectX10 is obsolete (it's not yet), but because the new DirectX11 book has a chapter on animation. The directX 10 book sorely lacks it. But your solid graphics background may make this obsolete for you.

3D Game Engine Architecture (with Wild Magic) by David H. Eberly is a good book with a lot of parallels to Game Engine Architecture, but focuses much more on the 3D rendering portion of the engine, so you get a better depth of knowledge for rendering in the context of a game engine. I haven't had a chance to read much of this one, so I can't be sure of how useful it is just yet. I also haven't had the pleasure of obtaining its sister book 3D Game Engine Design.

Given your strong graphics background, you will probably want to go past the basics and get to the really nifty stuff. Real-Time Rendering, Third Edition by Tomas Akenine-Moller, Eric Haines, Naty Hoffman is a good book of the more advanced techniques, so you might look there for material to push your graphics knowledge boundaries.



Software Engineering:

I don't have a good book to suggest for this topic, so hopefully another redditor will follow up on this.

If you haven't already, be sure to read about software engineering. It teaches you how to design a process for development, the stages involved, effective methodologies for making and tracking progress, and all sorts of information on things that make programming and software development easier. Not all of it will be useful if you are a one man team, because software engineering is a discipline created around teams, but much of it still applies and will help you stay on track, know when you've been derailed, and help you make decisions that get you back on. Also, patterns. Patterns are great.

Note: I would not suggest Software Engineering for Game Developers. It's an ok book, but I've seen better, the structure doesn't seem to flow well (for me at least), and it seems to be missing some important topics, like user stories, Rational Unified Process, or Feature-Driven Development (I think Mojang does this, but I don't know for sure). Maybe those topics aren't very important for game development directly, but I've always found user stories to be useful.

Software Engineering in general will prove to be a useful field when you are developing your engine, and even more so if you have a team. Take a look at This article to get small taste of what Software Engineering is about.


Why so many books?
Game Engines are a collection of different systems and subsystems used in making games. Each system has its own background, perspective, concepts, and can be referred to from multiple angles. I like Game Engine Architecture's structure for showing an engine as a whole. Luna's DirectX10 book has a better Timer class. The DirectX book also has better explanations of the low-level rendering processes than Coding Complete or Engine Architecture. Engine Architecture and Game Coding Complete touch on Software Engineering, but not in great depth, which is important for team development. So I find that Game Coding Complete and Game Engine Architecture are your go to books, but in some cases only provide a surface layer understanding of some system, which isn't enough to implement your own engine on. The other books are listed here because I feel they provide a valuable supplement and more in depth explanations that will be useful when developing your engine.

tldr: What Valken and SpooderW said.

On the topic of XNA, anyone know a good XNA book? I have XNA Unleashed 3.0, but it's somewhat out of date to the new XNA 4.0. The best looking up-to-date one seems to be Learning XNA 4.0: Game Development for the PC, Xbox 360, and Windows Phone 7 . I have the 3.0 version of this book, and it's well done.

*****
Source: Doing an Independent Study in Game Engine Development. I asked this same question months ago, did my research, got most of the books listed here, and omitted ones that didn't have much usefulness. Thought I would share my research, hope you find it useful.

There are books. Almost all of them suck. The only one that is any decent is mostly all theory so you will have to figure out the implementation details on your own:
http://www.amazon.com/Game-Engine-Architecture-Jason-Gregory/dp/1568814135/ref=sr_1_1?ie=UTF8&qid=1321484581&sr=8-1

The problem is that a game engine very large and complex and often needs to be built with a particular game type in mind. There is a reason all of the UDK games look like UDK games.

Ask yourself this: Do you want to build an engine or a game? You are unlikely to do both in any reasonable amount of time (multiple years). Perhaps you can scale back your design's grand vision of an open world game to something more manageable with an off-the-shelf engine like UDK or Unity rather than build an engine.

there is a chapter in http://www.amazon.com/gp/aw/d/1568814135?pc_redir=1410689459&robot_redir=1 that talks about game objects and components that should help you get your mind on the right track.

That's not what I meant, sorry if I came off that way. My point is, you can read all the books you want -- but if you don't supplement it with code you write, they're just concepts. Even if you're not writing code, you still should be looking at pseudocode or example code to see how it's implemented. Talking about something is easy -- programming it is hard. What people say when they say to design first, they mean to lay out your program, your APIs, and everything else ahead of time. This is part of professional software development. In order to get to that step though, you're going to have to program. You don't recognize good OO or game design by just reading a book.


Regardless, for a good OO-book, check out:
http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612

For a good book on game engine design, check out:
http://www.amazon.com/Game-Engine-Architecture-Jason-Gregory/dp/1568814135

If you want just game design and setup, there are more than enough resources at /r/gamedev.

Also, make sure to supplement everything with code you yourself write, or else nothing will stick.

If you're inexperienced, I'd recommend reading this book. It covers a lot of areas with a professional perspective. It doesn't go that much into details, but the bibliography of that book can be explored for further reading.

XNA takes care of most engine requirements for you, I believe, but you'd probably still get some value from reading the book I'm currently working my way through: Game Engine Architecture (Amazon link)

It gives a decent level of information about most components of a game engine, showing the alternative implementations that most engines tend to choose between. It's not overloaded with source code, but that's not the point of the book. It will allow you to understand what XNA (or other engines) may be doing under the hood, so that you can better know how to make use of it.

http://www.amazon.com/Game-Engine-Architecture-Jason-Gregory/dp/1568814135 Amazing book, after I checked it out from the library I decided I needed it. Nearly every example has a real life implementation, tons of code examples.

So basically, what I do is I work for a large company that has almost no understanding of software.

Said company makes a lot of equipment that for various reasons is hard to provide hands on training for (sorry if I'm being a bit vague here, but I rant about work a lot on Reddit to blow off steam so I don't want to identify myself too much) so what I do is I recreate those things in VR (or sometimes AR depending on what better meets the needs).

By doing this, we have products that can be pulled up on demand, configured however we need, processes can be done in a way that mimics a hands on experience, and a lot of the logistical problems get removed. The end result is better quality training for workers, and a massively reduced cost as we eliminate time delays and travel overhead.

What we primarily work in is Unity. You do not need a game dev specific education to do game dev, but there are a few concepts that are used heavily in game dev that aren't used nearly as much in other areas.

Naturally, algorithms and data structures are still king. Efficiency is everything in game dev because you often can't just throw more servers at something to scale. You have to take your clients hardware into account as well. Poorer performance means your customers need better hardware, and that starts to limit your market. In my case, since I build everything for internal use, I get to basically specify the hardware they use, which makes this a lot more pleasant, it's analogous to making something for a console that's going to be exclusive to just one platform.

The most used data structures are often different as well. I would say that what I use is probably 90% lists, 5% dictionaries, 5% graphs, though the graph portion tends to make up the backbone of everything so it's extremely important.

Other than that, runtimes of algorithms are very important. For the stuff I do, we try to maintain 120fps for our headsets. So that means we need to handle all of the processing and rendering in each frame in 8.33ms.

Even mediocre code can typically execute in that time, and the real bottlenecks are on the CPU load side of things like lighting calculations and collisions, which more often than not fall on the artists unless you're doing graphics programming.

Math wise, there's typically a small amount of linear algebra if you have to deal with 4x4 matrices, but otherwise most of what you deal with tends to be things like vectors, normalization, dot product, and so on. If your university offers a class on 3d math it would be worth taking. If they don't, memorize this book and you're set https://www.amazon.com/Game-Engine-Architecture-Jason-Gregory/dp/1568814135

Unity and Unreal are the two biggest game engines, both of them use a component based system. So reading up a bit on good component based design patterns is a good idea as well. There are other game engines out there, and those may or may not use components. But, component design is going to be the future.

If you want to know anything else, just ask.

http://www.amazon.com/Game-Engine-Architecture-Jason-Gregory/dp/1568814135/ref=sr_1_1?ie=UTF8&qid=1317500883&sr=8-1

This book is awesome. It's like...a game arch bible.

Things I would recommend and learned during my first two years in Game Development (I'm a gamedeveloper student) is that you should understand the way of how an engine works. How does the gameloop work? What should I put in my constructor? How should I create a new class? Should I use some kind of Design Pattern or do I need a simple class to something else totally unrelated to another object.

What you should do is try to get into Object Oriented Programming or try Component Based Programming (like in Uinty). There are some engines you can take a look at that use some of those simple ideas.

You should learn C++ if you want to get in serious Game Development though. There are a lot of decent books on this topic.

If you want to learn a bit on the standard things of an engine so you get a decent idea how it is build and how you build upon one. you should read this book.

I see there are a lot of answers already but if you want to ask me something else you can always send me a PM and I'd be happy to help you out!

I haven't got all that far into it yet, but from what I've read it's pretty much exactly what it promises to be. It's a little expensive for sure, but I've found it useful so far.

I'd suggest taking a look at the 'Look Inside' feature on Amazon for a better idea of what the book offers.

You could check out this book.

If I recall correctly, the code is written in C++ but if you know Java reasonably well you shouldn't have too many problems translating the C++ code to Java.

I only read the first chapter in this book so I can't really comment on it, but a lot of people recommend it.