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.

You always want processing. You may or may not need graphics. I saw you say you liked fighting games. You'll need a decent rig with some capable graphics.

You wanna dev?

First, yes you need a machine, a decent one. Do you want to build it? Yes , but if not then check these out. I suggest getting a workstations because they're built for productivity. However, they're expensive.

Also, I'm not sure you should commit to a desktop. Two words: Game Jams. You might want to take part in communities involved in game making games. For inspiration, mentorship and just overall fun. If you're not familiar, games jams are when developer enthusiasts get together and build a game over a period of time. The games tend to be simple and set around a theme for the event.

In which case, look at some cool laptops. The reason I suggest getting a gaming laptop is that it will have the graphic card you need, it doesn't need to be high end, just good enough to not be a toaster. Also gaming laptops tend to be more powerful.

So from a dev point of view, they're pretty solid. Personally, I prefer workstations. If you asked me, I would get a workstation with a video card, but those are very expensive and maybe when you master your craft you can drop some real cash on it. You're new. So don't spend too much, in case the entire thing doesn't jive with you. Worst case you get a decent gaming laptop to play MK at the coffee shop. (Don't laugh, I used to play Street Fighter at a coffee shop, it's a nice vibe!)

Also, I would also check out Meetup.com. Your city or area might have groups dedicated to building games and maybe you can learn with another person. From a professional point of view, there's a lot of value in learning to work with others.

So you got your hardware, now for software.

You will likely want to start building stuff. But you're going to need some baseline stuff.

So, I say go with Unity, long term. However you need to get to a place to understand unity. So... you're going to need to learn some coding. To at LEAST be comfortable with code. I say learn the basic and intermediate stuff first then jump into Unity. If you're feeling bold you could also do the advanced.

You will need only Visual Studio and make sure during the install you ask to include Unity.

Finally, you should read Clean Code. Write good clean code. Future you will thank you.

Now, you gotta be productive.

Set up time to do what you want to do. One or two hour blocks. Commit to them. Log that time. Also, get open office, or some other equivalent and start organizing your workflow. as a develop you need purpose in your tasks. So outline your tasks. Develop you "method" for working. Maybe you like self imposed crunch where you just throw on music and go. Maybe you prefer small bursts of productivity. Whatever it is, figure it out.

Journal your work. Go back and read it occasionally. Take non-digital notes on important stuff you learn. Writing helps with retention. You have two processes you need to flesh out.

• Your development process. How something gets built, tested and delivered.
  
• Your Creative process. How you come up with a game idea and flesh out if it's good.
  
  You're going to need to get a good sense of how to build a proof of concept. This will help you "feel out" your game's mechanics.
  
  Over time, you will need to explore more advanced idea in computer science like data structures and design patterns... but for now, focus on getting comfortable with code, debugging. Hell, even make a console app text adventure game. Start there. Then get more complexity. The idea here, is to take your time, be diligent and stick to it. Slow isn't bad, not completing is bad. So take your time and good luck!

You have a long journey ahead of you, but here goes :D

Beginner

C++ Primer: One of the better introductory books.

The C++ Standard Template Library: A Tutorial and Reference: Goes over the standard template library in fantastic detail, a must if you're going to be spending a lot of time writing C++.

The C++ Programming Language: Now that you have a good idea of how C++ is used, it's time to go over it again. TCPPL is written by the language's creator and is intended as an introductory book for experienced programmers. That said I think it's best read once you're already comfortable with the language so that you can full appreciate his nuggets of wisdom.


Intermediate

Modern C++ Design: Covers how to write reusable C++ code and common design patterns. You can definitely have started game programming by the time you read this book, however it's definitely something you should have on your reading list.

C++ Templates: Touches on some similar material as Modern C++ Design, but will help you get to grips with C++ Template programming and how to write reusable code.

Effective C++: Practical advise about C++ do's and dont's. Again, this isn't mandatory knowledge for gamedev, but it's advice is definitely invaluable.

Design Patterns: Teaches you commonly used design patterns. Especially useful if you're working as part of a team as it gives you a common set of names for design patterns.

Advanced

C++ Concurrency in Action: Don't be put off by the fact I've put this as an "advanced" topic, it's more that you will get more benefit out of knowing the other subjects first. Concurrency in C++11 is pretty easy and this book is a fantastic guide for learning how its done.

Graphics Programming

OpenGL: A surprisingly well written specification in that it's pretty easy to understand! While it's probably not the best resource for learning OpenGL, it's definitely worth looking at. [edit: Mix it in with Open.gl and arcsynthesis's tutorials for practical examples and you're off to a good start!]

OpenGL Superbible: The OpenGL superbible is one of the best ways to learn modern OpenGL. Sadly this isn't saying much, in fact the only other book appears to be the "Orange Book", however my sources indicate that is terrible. So you're just going to have suck it up and learn from the OGL Superbible![edit: in retrospect, just stick to free tutorials I've linked above. You'll learn more from them, and be less confused by what is 3rd party code supplied by the book. Substitute the "rendering" techniques you would learn from a 3d book with a good 3d math book and realtime rendering (links below)]


Essential Mathematics for Game Programmers or 3D Math Primer for Graphics and Game Development: 3D programming involves a lot of math, these books cover topics that OpenGL/DirectX books tend to rush over.

Realtime Rendering: A graphics library independent explanation of a number of modern graphical techniques, very useful with teaching you inventive ways to use your newly found 3d graphical talents!

It depends. A game design degree from a well-designed and well-connected course (USC and Carnegie Mellon are both well-set-up) can sometimes help, but more through the connections you'll make than the things you'll learn in the course. In general, though, I agree strongly with the people here advising you to learn a practical skill.

Someone looking to hire a junior designer (and please don't have any illusions that you'll be considered anything other than junior until you've shipped titles) will be looking at you through two lenses:

• Does this person have potential to be a good designer?
  
• Can I use this person right now for work I need done?
  For both questions to be answerable in the affirmative, you need to be able to demonstrate both that you know how to think like a designer (what choices were made to make a given game work, and why did those choices have the effect they had?), and that you know your way around a game engine. A designer who knows only how to write design docs won't be useful in the short-term, and probably won't be useful in the longer term either, because this person won't be able to prototype their work. Good design is an iterative process, and your ability to explore and respond to your work hinges on your ability to express it in the medium.
  
  Regardless of the degree you choose, my recommendation is that you pursue your own education aggressively. The game industry changes extremely fast, and your ability to teach yourself constantly is essential to your ability to keep up and stay relevant. To this end, I'd do two things:
  

1. Pick a game engine and learn it. Do the tutorials, learn how it runs, and make something worth playing in this engine. My recommendations here would be either Unity3d or Unreal. Both of these are solid choices for a few reasons: they're commonly used in the industry, so there's a high likelihood that someone on the hiring end would find your knowledge of the engine attractive, and they both do things in standard enough ways that if you learned either one, any other engine you approached would likely be structured similarly enough that you'd get what it's doing. Both of these engines allow you to get very deep into the sort of scripting designers regularly do (UnrealScript or C#). Most designers don't wind up needing C++, but it does happen on rare occasions. If you walk in the door with running software that's genuinely fun to play, you'll put yourself ahead of a huge chunk of the candidates in the field.
   
2. Learn how game designers think. There are three books I'd recommend for this, probably in this order:
   

• A Theory of Fun, by Raph Koster, as a good relatively lightweight introduction to design thinking.
  
• The Art of Game Design, by Jesse Schell - the best practical course in design thinking I've ever seen.
  
• Rules of Play, by Katie Salen and Eric Zimmerman - a foundation for most current game design thinking.
  There are other great books out there, but these three will set you off in the right direction. As a practical way to learn to apply this thinking, I'd recommend writing notes about the games you play from the perspectives taught in these books. Learn the theory by reading about it, recognize how it's working in the games you play by writing about it (even if just for yourself), and then try to apply this thinking to the game you're designing and building in the engine you're learning.
  
  Do these things, and you'll be an impressive candidate, and well on your way to becoming a good designer. At that point, the degree you choose really comes down to the specific areas in yourself you'd like to strengthen. I've worked with designers who earned degrees in architecture, film, english literature, philosophy, computer science, experimental music, and game design. Truthfully, few people will be swayed one way or another by the particular degree - they'll want to see your work and your ability to think. Above all, listen to those people here who are telling you to learn both sides of the coin - how to think about and write about design, and how to build running software - they're absolutely right that you need both.
  

Hey there, I'm a game designer working in AAA and I agree with /u/SuaveZombie that you'll probably be better off with a degree in CS. BUT... don't give up on wanting to be a designer!

 

You should realize that it's not giving up on your dream at all, in fact, it's great advice for how to reach that dream. A designer with an engineering background is going to have a lot more tools at their disposal than one who doesn't.

 

Design is way more than just coming up with a bunch of cool, big ideas. You need to be able to figure out all the details, communicate them clearly to your teammates, and evaluate how well they're working so you can figure out how to make something people will enjoy. In fact, working on a big game often feels like working on a bunch of small games that all connect.

Take your big game idea and start breaking it down into all the pieces that it will need to be complete. For example, GTA has systems for driving and shooting (among many other things). Look at each of those things as its own, smaller game. Even these "small" parts of GTA are actually pretty huge, so try to come up with something as small as possible. Like, super small. Smaller than you think it needs to be. Seriously! You'll eventually be able to make big stuff, but it's not the place to start. Oh, and don't worry if your first game(s) suck. They probably will, and that's fine! The good stuff you make later will be built on the corpses of the small, crappy games you made while you were learning.

 

If you're truly interested in design, you can learn a lot about usability, player psychology, and communication methods without having to shell out $17k for a degree. Same goes for coding (there are tons of free online resources), though a degree will help you get in the door at companies you might be interested in and help provide the structure to keep you going.

 

Here's some books I recommend. Some are specific to games and some aren't, but are relevant for anything where you're designing for someone besides yourself.

 

• Universal Principles of Design

• The Design of Everyday Things

• Rules of Play

• The Art of Game Design This and the one below are great books to start with.

• A Theory of Fun This is a great one to start with.

• Game Feel

• Depending on the type of game you're making, some info on level design would be useful too, but I don't have a specific book to recommend (I've found pieces of many books and articles to be useful). Go play through the developer commentary on Half-Life 2 or Portal for a fun way to get started.

 

Sounds like you're having a tough time, so do your best to keep a positive attitude and keep pushing yourself toward your goals. There's nothing to stop you from learning to make games and starting to make them on your own if that's what you really want to do.

Good luck, work hard!

Book suggestions? Now that's my jam.

Out of all the books i've read, here are my recommendations regarding game programming:

Eric Lengyel's Books (only one out so far). This is aimed at game engine development, but if the 2nd onward are as indepth as the first, they will be amazing fundamental knowledge. Also, they're not thick, and jam packed with information.

Game Programming Patterns. The only book that comes more recommended than this is the one right below it by Jesse Schell. This book is fantastic, but you should write one or two small games to really get the most out of this book. You can also read it online on his website free, but then you don't get a pic of him and his dog on the back cover.

Book of Lenses. This is your intro/intermediate dive into game design. There are a lot of game design books, if you only read one, it should be this one.

Gane AI By Example. This book is a hodgepodge of fantastic techniques and patterns by those in AAA. There are other books on the series (like Game AI Pro) which are similar, but in my opinion (at least when I read AI PRO 3), they're not as good. But more knowledge is never bad.

Truthfully, as I sit here looking over all my books, those are the only ones i'd consider mandatory for any seasoned developer. Of course plenty of developers get by without reading these books, but they likely pick up all the principles listed herein elsewhere, in bits and pieces, and would likely have benefited having read them early on.

Here are a few others that I do recommend but do NOT consider mandatory. Sorry, no links.

Unity in Action. Personally, I recommend this or a more interactive online course version (udemy.com/unitycourse) if you want to learn unity while having a resource hold your hand. Having read the book, taken the course, AND taken Unity's own tutorials on the matter, i'd order them in order from Course being best, book second, videos from unity third. But none of them are bad.

Game Engine Architecture. This is the king for those who want a very broad introduction to making a game engine. It comes highly recommended from nearly anyone who reads it, just so long as you understand it's from a AAA point of view. Game Code Complete is out of print and unlikely to be revisited, but it is similar. These are behemoths of books.

Realtime rendering. This is one I haven't read, but it comes very highly recommended. It is not an intro book, and is also over 1000 pages, so you want this along side a more introductory book like Fundamentals of computer graphics. Truth be told, both books are used in courses in university at the third and fourth year levels, so keep that in mind before diving in.

Clean code. Yeah yeah it has a java expectation, but I love it. It's small. Read it if you understand Java, and want to listen to one of the biggest preachers on how not to write spaghetti code.

Rimworld guy, Tynaan sylvester I believe, wrote a book called Designing Games. I enjoyed it, but IMO it doesn't hold a candle to Jesse Schell's book. Either way, the guy did write that book after working in AAA for many years, then went on to create one of the most successful sim games in years. But yeah, I enjoyed it.

Last but not least, here are some almost ENTIRELY USELESS but interesting diagrams of what some people think you should read or learn in our field:

https://github.com/miloyip/game-programmer

https://github.com/utilForever/game-developer-roadmap

https://github.com/P1xt/p1xt-guides/blob/master/game-programming.md

First of all, I wouldn't recommend learning game coding by looking at a codebase, the biggest reason being that all games are different and are using different techniques (obvious one being 2D vs 3D, but you have tons of differences between a FPS, a RTS, an open-world, etc).

I would recommend to find books or articles that explain why a certain technique is usefull, the coding language doesn't really matter, the technique itself is what is important (As you are saying it's for learning purposes and I don't think it's quite interesting to understand data-driven programming, cache optimization or 3D APIs optimization for C++ when you are first trying to understand a game structure).

I can recommend two really good books :

• https://www.amazon.com/Game-Coding-Complete-Fourth-McShaffry/dp/1133776574/
  
• https://www.amazon.com/Engine-Architecture-Second-Jason-Gregory/dp/1466560010/
  
  And website like Gamasutra have lots of good articles to look at. You can also look at HandMadeHero when Casey Muratori is explaining in details why he is doing what he will programming later on the show, his website is worth looking at too with some really good talks. Lot of good talks can be found at GDC, not all of them are free but a good portion are.
  
  If you still want to learn only from codebase :
  
  
• You have publicly available sourcecode engines (you can look at the Engine FAQ) with Unreal 4, CryEngine and Godot being really interesting.
  
• When looking for games code, you can have a look at Id Software repo for classical game code
  
• Dark Engine (Thief, etc) code base is glorious, specifically the renderer written by Sean Barrett is really good (even if it's not open-source, you can find it), Sean is also streaming his creation of a voxel based engine at his twitch channel
  
• HandMadeHero is also a good database whereas not technically open-source it's worth looking at and is (very well) presented and programmed by Casey Muratori.
  
  Happy game programming :)
  
  EDIT : Fix format
  
  EDIT 2 : Changed open source to publicly available sourcecode

I'm not sure what your background is, but if you haven't had any formal programming education, I believe we learned out of a book like this: https://www.amazon.com/dp/0201633612/?tag=stackoverfl08-20

One of the keys to good software is good design. Making a plan of action before you even start coding cuts back on the 'quick fix' solutions that make your code harder to work with later.

I don't think this is C# specific, but design is really something that is abstract from language specifics. If you're looking for something specific to the environment you're working in, I think material on best practice for the game engine you're using would be better. I have done application development with C# and C# scripts in Unity, and there are definitely differences in how I am able to make things interact, which impacts how I design my code.

I have two recommendations if you're wanting to expand your abilities in design:

1. UML Diagrams: You can model out all of the pieces, with their members, functions and interactions with each other. Doing this can help in prototyping a system, you can see the interactions and logically create classes and scripts around the model instead of bloating things as you run into problems along the way.
   
   
2. Documentation: This is key to the longevity of a project and saving time in bugfixes and expanding on software later. When you finish any snippet, leave comments explaining what you're doing. Use good variable names. I do consultant work on legacy code and it's amazing how people can write an entire application without comments, in one large Main file and with variable names that mean nothing. I was terrible about naming things 'temp' and what not when I first started out, and if you ever work with anyone else leave a project to sit for a few months to a few years, you and your colleagues will greatly appreciate documentation.
   
   As far as the book goes, I can't condone it, but there's probably PDFs out there. Sometimes it helps motivate to actually read through it if you've invested some money into it, though. I would recommend finding an old/used copy. An old version of the book should work just as well as an 'updated' version.
   
   You may also find it useful to look into Agile/Scrum. It's all about documenting your development, and helps to organize what's been done and what needs to be done, as well as give you an idea of how long things take, which helps later with estimations. All these things are skills that will come in handy later, if you decide to pursue software as a career. Plus, it's all good habits that help facilitate good, clean code.

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)

Don't be suckered by a "Game Design" program. There are VERY few good ones. Most of them....as in, 99% of them...are rip-offs.

Learn programming, 3D-modeling, or animation. Pick one that you're more interested in and then full-speed ahead. These will make you useful in more than just game development roles, thus helping you in the future when you have trouble landing a game dev job. At least you'll still be doing something you like in the meantime, and still building your skill in that area. Many really popular game designers have specialties outside of just "Design". Some are excellent programmers, some are artists, some have excellent business skills (really good at project management), and some are brilliant story-writers. Most game design positions are not entry-level, because you REALLY have to know what you are doing, before someone will trust you enough to let you touch the design. The only real way to prove that you are actually a good game designer is by having games to show off. That proves that you have some idea of the design process and know how to maintain a game from start to finish. This is HARD.

Some like to say that these degree programs for game design help them by giving them the incentive to push through and finish their stuff, otherwise, they might not have the motivation. Well, that's very problematic, because that means that you will not be the type of person who can finish a game. Game development requires you to be highly self-driven.

Most of what "Game Design" programs teach you can be learned by picking up a few game design books and making your own games (alot of them, too). Game design is learned by making games, not by having a professor tell you about it. You have enough mentors in the game development community already. They will always be there to critique what you do and give you tips on how to improve your work. Pick up a couple of books like The Art of Game Design and Designing Games. You can look at other books in whatever other area you want to master and just get started on making games. Turn off your console and just get started. Start small. Make very simple, basic games to start off with (B.A.S.I.C.). It's about learning the process first. Do that while reading a ton of highly-detailed game postmortems online. Just learn the process. THAT will be your real education.

And finally, start working your way up to putting together a portfolio. Portfolios speak much louder than a resume (although, a resume is still important). And that doesn't mean having a bunch of "Game Design docs". Games. Not docs. Games. Then build up your confidence and hook up with a team, so you can fight your way together to the end of making a complete game. (this may be one of the only valuable things that a game design program can provide you out of the box, i.e., a team that you are forced to work on a game with)

The single most important tool you will ever have is discipline. No degree will be able to top that. Give up the idea of being a hardcore gamer, because you are now going to need to become a VERY disciplined person. You're going to need it.

Finally: Don't forget to have fun. Good luck! :)

I think that's a hard enough question even when targeting the general population within that age group. So it can be difficult to find well researched and experientially backed up information even without the more specific target of children with autism. Though I'll also note (as someone with a degree of autism himself), depending on the individual's particular autistic attributes, the condition can actually be a strength for studying something such as game design. The focus on designing rules and working out all the implications for their effects on the gameplay experience can often be a natural fit for someone with autism. At least in my case, the key for effective learning was to grant me the time, space, and tools to explore a subject in my own idiosyncratic way, at which point I could soak up all sorts of knowledge and concepts.

As for concrete recommendations, the one that comes to my mind is to look outside of computers for at least part of your teaching material and activities. I wasn't expecting it initially, but while reading a variety of game design books to improve my own knowledge for making video games, I repeatedly encountered the recommendation to do as much of your early prototyping away from the computer as possible. That is, design board games, card games, sports-like games, party games, and so on. In many cases, you can pull ideas from a variety of game types to build hybrids that do a decent job of replicating the essence of certain video game mechanics, giving you a chance to evaluate how fun the concept is, and if it merits spending time to make a more in depth digital version.

Best of all, it can be free or very cheap, it requires no knowledge of coding, you can do it anywhere (though preferably with a good work table and some craft supplies and standard physical gaming equipment), and you can get results in just a few hours, or maybe even a few minutes depending on the concept. Anything using a standard deck of 52 cards is particularly simple to test, for example.

Two of the books I've already read that had sections helping me think in these terms were:

• Game Design Workshop: A Playcentric Approach to Creating Innovative Games
  
• Game Mechanics: Advanced Game Design
  
  Challenges for Game Designers is also on my backlog to read and looks very good for this sort of non-digital focus for learning skills that will ultimately be applicable to making digital games.

If you want to know specifically about Doom, then you want to read this and this

For collision detection in general, Real Time Collision Detection really is a great book and covers all of the data structures I mentioned. (Note about the upcoming 2nd edition)

https://www.gamedev.net/forums/forum/7-math-and-physics/ should have accumulated some good information over the years.

Personally, I focus on dense grids for constrained situations and AABB-trees for general solutions.

For example, a 2D game with a reasonable max level size can be handled easily with a dense grid. Just pick a bucket (grid square) size and make a big ole 2D array of linked lists pointers to collision nodes that touch each grid square. That sounds like a lot of memory. But, if you do the math, it's not much on modern machines. Linked lists are bad for cache, but you can make that better by having each node store 7 pointers to collisions + 1 pointer to the next node. At 8 bytes each, 8 pointers is 64 bytes which is 1 cache line. Don't malloc the nodes individually. Pre-alloc an array of them and keep the free nodes in a linked list using the node.next attribute.

For more flexible situations, having a hierarchy of axis-aligned bounding boxes tends to work as well as any other solution. By stuffing 4 or 8 boxes in each tree node you not only gain efficient use of cache lines, you also have the opportunity to arrange the data to make SSE SIMD intrinsics work out.

A fun trick is to separate static vs dynamic objects into their own trees, but then hook them back to together at the top. So, you can pre-bake a slow, carefully balanced tree for the static geo. But, leave one free slot in the top-most node of that tree. During the game, maintaining a dynamic tree is hard, so make compromises for update speed in the dynamic tree. But, once you have the dynamic tree, you can point the static tree's spare pointer at the dynamic tree and BAM, one unified tree!

You can also do stuff like this where you pre-calc a good BVH for each object individually, then insert those small, static trees into an overarching dynamic tree as the objects move around.

Fellow enterprise developer turned manager here. Me and my cohort are about to release our first title. It was developed using .NET/C#.

AMA. :)

I'll start with the questions you have above.

Assuming you already have a solid foundation in OOP, Design Patterns, some basic RDBMS, etc, you actually already have 60% of what you need. Code is code.

The other 40% depends on the type of game you are making. 2D? Basic algebra. 3D? Now it gets tougher on the math (though thankfully today's engines do most of the heavy lifting for you, but you still need to understand what is used for what).

Doing multi-player? Now networking is the tricky part because you are likely to use some sort of UDP communication layer and all the REST/SOAP you learned at work, while still useful for managing latency-agnostic stuff like player lists, matchmaking requests and such, won't cut it for real-time multi-player games. Writing solid "netcode" that delivers a great experience at 60+ FPS requires some creativity in managing perception (extrapolation and interpolation when latency is present) and fault-tolerant algorithms. It is no fun when you get a headshot in an FPS, see it happen, but your opponent runs away, apparently unscathed.

As far as graphics, I solved that one easily... I had a friend join my project who was the graphics guy. I provided the framework for doing the graphics and turned that area over to him. He went above and beyond though and learned shaders and added all sorts of special effects.

Meanwhile, I focused my energy on the game engine, networking layers, AWS cloud stuff, matchmaking and lots of behind the scenes stuff.

The other thing I did was read as much as possible about Game Design. I ordered a dozen books from Amazon, including my absolute favorite Designing Games by Tynan Sylvester, the developer of RimWorld (link: https://www.amazon.com/Designing-Games-Guide-Engineering-Experiences/dp/1449337937).

Hope that helps!

If you're planning on pursuing this as a career, there are tons of incredible opportunities for people experienced with lower-level 3D APIs. Making your own engine serves as a fantastic learning experience, and would be a huge investment in your future.

Below are some of my favorite books/resources right now that may help you along the way. These might not be immediately useful to you right now, depending on where you're at, but together they have more than enough knowledge for you to go far in 3D Computer Graphics.

• Game Engine Architecture touches at least a little on all of the knowledge necessary to build a bare-bones 3D engine. It goes over the components of modern 3D engines, and how they work. It even has introductory Linear Algebra and Object-Oriented programming concepts. I think this book is pretty approachable for beginners.
  
• The OpenGL SuperBible offers great insight and examples on using OpenGL optimally. Depending on when you start, however, you may want to consider a Vulkan book instead. I think this book is the best way to learn OpenGL as a beginner. There are plenty of free tutorials online on websites like learnopengl.com and open.gl as well.
  
• Real-Time Rendering is a fantastic book that dives deep into different algorithms and techniques for modern 3D rendering. It's pretty advanced, but it's a very well-known book and exposes very valuable information on complicated effects found in modern 3D engines.

SubLight

Build your ship, hire crew, and voyage across the stars... only there's no fancy warp drives, wormholes, or faster than light travel. You're tasked with managing your ship on the generations long trip between each star system, keeping them happy, healthy, and under control!

Play it in your browser!

Or download the Windows, OSX, or Linux versions!

This week was spent on a lot of behind the scenes stuff, namely the crew AI. I did a full write up of the new AI on IndieDB, full of fun graphs, but here's a brief excerpt:

>I knew what kind of actions I wanted my crew to do, from various hijinks like joy-riding the turbo-lift, to full out cannibalism when starving! I figured the AI I was looking for was similar to "The Sims", "SimCity", or "Roller Coaster Tycoon". After glancing through the glossary of Artificial Intelligence for Games, I found mentions of "The Sims", and after some investigation, got exactly what I was looking for, Goal-Oriented Behavior.

>In brief, the crew have a limited number of Goals they are trying to satisfy, through Actions made available by modules on the ship. For my crew, or "Simunauts" as I've called them, they have these goals:


>* Eat

• Heal
  
• Sleep
  
• Urinate
  
• Relax
  
• Shower
  
• Entertain
  
• Socialize
  
• Work
  
  >Each of these goals have an associated value that increases over time and through interacting with the ship. A hungry "Simunaut" may hit up the cafeteria module to lower their Eat goal at the cost of increasing their Urinate goal.
  
  >Here's a fun list of some basic actions available to the crew and you can see how important these goals are over time from this graph.
  
  New:
  
  
• Completely overhauled crew AI using new Goal-Oriented Behaviour system
  
• Parts now contain certain actions that they make accessible to the crew
  
• The current happiness of your population is now displayed in the form of a smiley face in the top left corner
  
• Important events, like the crew resorting to cannibalism, are displayed briefly onscreen
  
• Added a new song by Ian Earle!
  
  Known Issues:
  
  
• Some of the stats for the ship building scene are broken due to the new AI logic, those will be implemented again next week!
  
  What's coming next week:
  
  
• A new UI for the Ship Builder
  
• New parts: Knick Knack Storage, Orion Pulsed Propulsion Drive, Radex Protection Platter
  
• Detailed breakup of crew needs (so you can tell they're hungry before eating everyone).
  
• Another original music track from SubLight's musician, Ian Earle a.k.a OogalaBoogala
  
• More??? Suggest what you'd like to see in the comments!
  
  Thanks again so much for taking a look at this weeks alpha build of SubLight! Can't wait to hear your feedback and leave some for others!
  
  As always, you can follow us at these fine locations:
  
  SubLight on IndieDB | Twitter @Spacew00t | LunraGames.com

The correct answer to:

Q. Should I learn C or C++ first?

Is:

A. Yes.

WARNING: Highly Opinionated Analysis of C vs C++

I see a lot of people recommending one way but no one offering an analysis of BOTH the Pro's & Con's.

I've been using C++ since ~1990. I've briefly worked on a PS3 C++ compiler when I worked for Sony. I've seen 2 major problems over the years with C++ programmers:

1. People don't exercise discipline and restraint in K.I.S.S.

They use (and abuse) every language feature because they can. There is this tendency to over-engineer even the simplest things. Take a look at this complete clusterfuck of CRC in the Boost library.

1109 lines of over-engineered C++ crap for a simple CRC32 function instead of a mere 25 lines of code!?!?! The C version would:

• do the same thing,
  
• be simpler to write, and
  
• be simpler to debug, and
  
• more importantly solve the problem at hand, not abstracted to the point of being over-engineered.
  
  The trade-off would be is that it is less flexible, but WHEN was the last time you needed to use a custom CRC polynomial!?!? One would instead use a different algorithm such as MD5, SHA, etc. that:
  
  
• has better better error-rate detection,
  
• less collisions,
  
• is multi-core.
  
  This excellent SO on hashing is but one example of focusing on the big picture.
  
  2. People lack a basic understanding of the cost let alone the implementation of C++ expressions.
  
  I've seen people stick a virtual function inside an inner loop and wonder why their performance is crap. I've seen people fail to grasp a basic understanding of pointers. I've seen people not understand memory management and how to guarantee zero memory leaks. I've seen people spend more time on writing an "über" template and waste hours debugging that instead of just writing something in 1/10 of the time and move on.
  
  IMO, due to the bloated, over-excessive verbose nature of C++ it is for these reason that I strongly recommend a beginner learn C first and then learn C++. You'll have a better understanding of why C++ is designed the way it is, what the design trade-offs are/were, what C++ hacks are, and how to best use the languages to their potential.
  
  However, this is ignoring the benefits and disadvantages of the Pro's/Con's of why one would learn C++ or C first.
  
  

  Learn C++ first
  

  
  

• C++ Pro
  
• C++ really is a better C then C in so many ways, too numerous to enumerate
  
• In the ways it is worse the smart people / companies use a sub-set of the language: Ubisoft avoid Templates, Exception Handling, and Run-Time Type Identification. When even a C++ committee member admits he writes in a sub-set of C++ himself you know the language is b-l-o-a-t-e-d.
  
• You won't have to unlearn certain "bad habits" of C
  
• Your skills will up-to-date
  
• Your code will be textually smaller (See note about Con)
  
• Job Security -- that is half joking, half serious. Seriously.
  
• You can enjoy the time exploring the different nooks and crannies of the language. You will see a different way to solve the same old problems. This can be both good and bad.
  
• Eventually you'll be able to enjoy deep technical C++ comedy such as Hitler on C++
  
• OOP (Object Orientated Programming) makes it almost easy to quickly write bigger scale programs
  
• Is multi-paradigm: Procedural, OOP, Functional, Generic. You have the freedom to pick and choose the parts of the language that fits your needs.
  
• For every problem you're trying to solve there is probably language support. Threads, and Atomics are finally part of the language.
  
  
• C++ Con
  
• You won't understand some of the C idioms used in practice
  
• The language is HUGE -- it will take you a decade to properly learn the language
  
• Debugging C++ is a PITA
  
• While people write crap code in any language, it is harder to read bad C++ code then C code.
  
• Compiler Support for the latest standards is a constantly moving target. Translation: Microsoft's Visual C++ has traditionally had crap support for the latest C and C++ standards. The good news is that MSVC 2015 finally supports a nice section of the language.
  
• While C++ can be textually smaller, one's code can easily be "bloated" if not careful (such as templates and partial template specialization)
  
• You really won't understand the run-time costs, nor be motivated to understand the underlying assembly language generated, by a "simple" C++ expression.
  
• Expect L-O-N-G compile times for any significant code base unless you use a "Bulk / Unity" build (you compile one .cpp file that includes EVERYTHING)
  
• It will be hard to resist over-engineering, over-complicating even the most basic tasks
  
• iostreams is a complete clusterfuck. Even the C++ committee recognizes there are many problems with C++ iostreams but sadly nothing is being done towards performance at the cost of type safety.
  
• It is far easier to blow your cache. Even Bjarne Stroustrup, the language designer, until 2012 didn't have a clue in understanding why Doubly Linked Lists were so slow compared to Arrays. HINT: The L1 Cache usage is critical for performance sensitive code.
  
• People tend to over-use the OOP paradigm even when they shouldn't. People make dogma and religion of "Design Patterns", failing to think if the model applies or not.
  
• The OOP paradigm is slow and bloated compared to Data-Orientated-Design. See Sony's Pitfalls of Object Orientated Programming
  
• Reflection STILL isn't standardized -- everyone has their own "home grown" approach. Maybe in C++17 ?
  
  
  

  Learn C first
  

  
  

• C Pro
  
• The language is tiny and easy to learn. Learn C the Hard Way is a great tutorial.
  
• No operator overloading
  
• No function overloading
  
• No lambas
  
• Has no reflection
  
• Has no exceptions
  
• Has no RTTI (Run-Time Type Identification)
  
• Has no STL (Standard Template Library)
  
• You will have a better understanding of the run-time "cost" or performance of code instead of a single line hiding "hidden" behaviour.
  
• You'll be a better programmer for understanding more of the lower-level implementation. If you don't know how to write itoa() or atoi() you're a noob programmer.
  
• You'll be forced to keep things simple
  
• You'll understand how to implement OOP in a non-OOP-native language, and better appreciate C++'s syntax sugar of OOP.
  
• You'll appreciate how C++ templates solve some but not all "textual replacement" problems and why #define macro's suck for debugging.
  
• Is ubiquitous, runs everywhere, and easy to get a C compiler for everything under the sun. Matz's Ruby Interpreter (MRI) was written in C, the Java VM was originally implemented in C, Perl is implemented in C, Linux is written in C. Anything popular and older then 10 years was probably written in C.
  
• Variables must be placed at top of a brace {
  
  
• C Con
  
• Compared to C++, you'll hate how primitive the language is such as typedefs for structs, no local functions, const is only "half" useful in C -- it can't be used in array declarations (See: http://stackoverflow.com/questions/5248571/is-there-const-in-c ), etc.
  
• No operator overloading
  
• No function overloading
  
• No lambas
  
• Has no reflection
  
• Has no exceptions
  
• Has no RTTI (Run-Time Type Identification)
  
• Has no STL (Standard Template Library)
  
• Simple algorithms can be tedious to write
  
• Variables must be placed at top of a brace {
  
  With that said there are numerous C++ books I would recommend to ALL C++ programmers. They are sorted from beginner to expert:
  
  
• The Design and Evolution of C++, Bjarne Stroustrup -- another ancient but fundamental to understanding all the kludges in C++
  
• The C++ Programming Language, 4th Edition <-- "Mandatory"
  
• ALL the books by Scott Meyer
  
• Effective Modern C++: 42 Specific Ways to Improve Your Use of C++11 and C++14
  
• Effective C++: 55 Specific Ways to Improve Your Programs and Designs (3rd Edition)
  
• Effective STL: 50 Specific Ways to Improve Your Use of the Standard Template Library -- ancient but good
  
• Modern C++ Design: Generic Programming and Design Patterns Applied by Andrei Alexandrescu -- another ancient but it blew the doors open for C++ Meta-Programming. IT is interesting that he hates C++ -- he now works on the D language.
  
  If you can get only one book, get the The C++ Programming Language.
  
  Even though Bruce's book is ancient he keeps it simple and is a fun easy read. Remember this is before C++98 where the language is much simpler.
  
  
• Thinking in C++, Bruce Eckel
  
  You can find it online for free
  
  Lastly, just because you can, doesn't imply you should. Use balanced C++ and you'll be fine.

You may want to narrow that down a bit, but okay, here are some highlights, with amazon links to help disambiguate.

• Game Programming Gems series -- (8 books currently) Lots of snippets and articles contributed from developers across the game industry.
  http://www.amazon.com/Game-Programming-Gems-Adam-Lake/dp/1584507020/
  
  
  
• Game Engine Architecture by Jason Gregory -- Great intro to the details of how game engines are built. It's a good balance for detail and readability for a beginner. Even for someone just using engines such as UDK or Unity3d I would recommend this to understand what is going on under the hood.
  www.amazon.com/Game-Engine-Architecture-Jason-Gregory/dp/1568814135/
  
  
  
• 3D Game Engine Design -- More technical and detailed descripting of designing and developing a game engine, but not as noob friendly as Game Engine Architecture
  http://www.amazon.com/Game-Engine-Design-Second-Edition/dp/0122290631/
  
  
  
• 3D Game Engine Architecture -- Follow up to 3D Game Engine Design that goes in to lower level detail and general updates.
  http://www.amazon.com/Game-Engine-Architecture-Engineering-Applications/dp/012229064X/
  
  
  
• Artificial Intelligence for Games by Millington / Funge -- I believe this is the current "must read" for game AI. The only book I've seen that goes in to Behavior Trees and other modern concepts.
  http://www.amazon.com/Artificial-Intelligence-Games-Second-Edition/dp/0123747317/
  
  
  
• AI Programming Wisdom series -- 4 books, like Game Programming Gems but for AI. Not a must have but I'd recommend them. They seem to be out of print though, so good luck finding them.
  http://www.amazon.com/AI-Game-Programming-Wisdom-CD-ROM/dp/1584500778/
  
  
  
• Real Time Rendering -- One of the better books on rendering. I'm not a big render guy but this is the book that everyone recommends to me.
  http://www.amazon.com/Real-Time-Rendering-Third-Edition-Akenine-Moller/
  
  
  
• Real Time Cameras -- THE book on how to implement cameras well, written by THE guy when it comes to video game camera systems.
  http://www.amazon.com/Real-Time-Cameras-Mark-Haigh-Hutchinson/dp/0123116341/
  
  
  
• Code Complete -- The only book not game related I'm listing, it's basic stuff to help you learn to write better code. There are parts that I (and many others) disagree with but in general it's a lot of good advice.
  http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/
  
  
  There are many others, but looking at my shelf these are the big ones that stick out for recommendations.

A good starting point is to identify what you want to do exactly. Find your focus on what you plan on attempting, then think smaller. Most first projects are very ambitious (while good) can lead to you making something not worth your time, headaches and just frustration.

However with that being said, here’s a few ideas to help get you started. If you want to just jump in and get your hands dirty and start working on a visual level you can try these programs:

• Game Maker / Studio GameMaker
  
• RPG Maker RPG Maker
  
  More Advanced:
  
  
• Flash Adobe
  
• Unity Unity
  
  ---
  Alternatively in conjunction of playing more games in your lifestyle, I would highly recommend you start to read blog posts, writings and articles on game design, theories and practices as well what industry leaders are talking about. While most people who love and have a passion for games watch game reviews, you’re going to want to focus onto sites like:
  
  
• GameDev.net Gamedev
  
• Gamasutra Gamasutra
  
  ---
  A book you may want to consider picking up:
  
  
• Rules of play Amazon link
  ---
  Back to your original topic about programming. While doing all of these so you understand what it takes to make a game, how a game shapes or how a game can be fun its time to start learning the important type. Which is the programming side. Now before you continue, programming isn’t always for everyone, but don’t let that discourage you. You may find while programming you love it, you may find you don’t like it. Programming is a tool which you can add to your arsenal of design and implementation and its smart to grasp the basics if you plan to get into game development even if you find yourself not savvy in it.
  The game makers I listed above each have a language that works with them. For example Game Maker has GML which is its primary language. RPG Maker has RUBY as a base and they use RGGS3 (I think that’s the current revision). Flash uses a scripting/programming language known as ActionScript 2 or 3 depending on what your accomplishing. Unity 3d uses C# and Mono, Javascript and I think another language but don’t quote me on that.
  Since you want to start from scratch the only advice I can give you is this. Don’t give up. Keep persistant. I would recommend that you start at an entry language that helps break down a lot of the tedious tasks and makes it more adaptable towards learning such as Python.
  Some resources:
  
  
• CodecademyCodeCademy
  
• Learn Python the Hard Way Learn Python the Hard Way
  
• Invent with Python Invent with Python
  
  I hope to see questions popping up as your understanding the basics of Game Design and game creation. It is always good to see people entering the field and tragic when people give up. Remember, start small. Do not expect to make a Minecraft clone within the first few days of learning a programming language, you need to practice and start small. Chances are your first few games are going to be clones of Snake / Pong / Tic Tac Toe etc. These are learning tools to help you understand how its created, the logic behind it and building/stepping blocks into a solid foundation.
  Don’t give up and start learning everything you can. Apply yourself and keep moving forward and you will do just fine. Welcome to the club!
  

I'd put them in this order: Experience, Knowledge, Portfolio, College

Nothing beats experience, and with it will come the knowledge. But it always helps to spend your free time reading, too. There's tons you can learn from books that will slip by you, even after decades of experience.

Then, a portfolio of your previous work is always more telling than a piece of paper saying you managed not to party yourself into a failing grade. (I'm a little salty about college.)

Game Patterns are going to be your most important thing to know if you want to get on the coding/development side. There's a book by Robert Nystrum - who worked for EA, and hangs out here on Reddit - that is one of my favorite books on programming patterns to date (and the patterns are not limited to game design). I would strongly recommend this as a starting point for any game dev.

Scrum is fine and dandy if you're working on a small team, but I wouldn't focus too heavily on it, especially not if you intend to work alone. Even if you're going to work on a small team, Scrum is a development lifecycle that you can learn in 6 minutes by looking at a chart. Don't worry about it.

The language of your choice is going to primarily be driven by what platform you're designing for, and what kind of game. Working on a AAA title? You're probably going to be in C++. Working on a game for Facebook? Probably going to be in Flash. Working on a game for cell phones? Probably going to be in Java. Looking to make a simple DirectX (windows only) game? Probably going to be in .NET.

As for anything else (assets / scripting / etc.) this will come with time. I would strongly recommend you start with a very, very simple do-it-yourself game (think Tetris). Even if it's a clone of another game. (But don't clone Tetris. They LOVE to sue people.) Minesweeper is always a good one to start with (being a strictly event driven game, you can whip up a fully functioning mine sweeper in an afternoon).

Then move on to another simplistic 2D game. (I feel like everyone should start by making an Arkanoid clone, though I've also helped people make simple 2D racing games and such.) Finally, move on to making something a bit more complex that would be worthy of your portfolio, without trying to jump into the next great MMO.

And who knows, maybe even one of your tech demos can make you filthy rich. (We all dream of being the next "Notch" with Minesweeper I meant "Minecraft"...)


Edit: I also left out the possibility of using a game engine for your development. Unity is popular, but there are more game engines out there than you can shake a stick at.

Personally, and this is strictly personal preference, I prefer the flexibility given by rolling my own code. Game engines can cut your development time by YEARS, but then you're forced to find, and work around any quirks or limitations the engines have (and they all have them). I find that so unbelievably frustrating to run into a wall like this that I'd rather take the extra eons to roll my own. (But then, I've never managed to release a completed commercial title, so there's that.)

Eh. It's a fine method, it's not the only method and I'd probably advise using multiple categorization systems to look at your game. Yes they mention that it's only one of many but I don't think they really highlighted that particular point enough.

You can find many different patterns in game design if you look - but games are not really made of such discrete parts.

So yeah look at the planning, improvising and practice involved in your game. But also look at the different challenges it provides, or any of a hundred different lenses.

Game design taxonomies each present themselves as the way to look at games, but they're each just a way of looking at games and you should use a variety of different points of view when analyzing or otherwise working on your design.

But because I liked the video: my game Honor Bound is heavy on improvisation, and practice - but that practice is only to support the planning you will do.

In Honor Bound you play rock paper scissors but you choose a Class that has Abilities that may encourage you to use one move over another. Also you can tell your opponent what move you're about to play - you can psyche them out or gain a damage bonus for telling the truth.

There's a lot of improvising against your opponent's strategy. Previous experience (practice) will inform you how each Class is played and you will plan around that at the start. However this will always go back to improvising against how your particular opponent is mixing things up to try and psyche you out.

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.

Thanks a lot! I actually have that first book bookmarked but I forgot to put it on the list.

I'm leaning closer and closer to purchasing a copy of The Art of Game Design: A Book of Lenses and it's one I'm actually really curious about.

On Game Physics Pearls - I peeked into the first few pages and it looks like something that I will pick up once I have a bit of experience in that area...does that sound about right or would you say it could cater to beginners fairly well?

Game Physics seems like it may be a bit more beginner-friendly but you are right about it not being a tutorial, which is kind of important for me at this step. I'm definitely bookmarking this until I know a bit more on the subject, though. I'll be taking a Physics course next September so it may be a good time to look at it after that!

Real-Time Shadows looks very interesting but I'm unsure to the difficulty level of it to a beginner. It sounds like I need to brush up on my math after three years of not using it very often at all.

Thanks a lot for the suggestions!

*I'll be taking a course on Linear Algebra here in the coming semesters, but that book does sound like a good introduction along with how it works within 3D programming. I'll keep a look-out on that for a while; do you think it would be very worthwhile to read that before something like Real-Time Rendering?

I'll start off with some titles that might not be so apparent:

Unexpected Fundamentals

These 2 books provide much needed information about making reusable patterns and objects. These are life saving things! They are not language dependent. You need to know how to do these patterns, and it shouldn't be too hard to figure out how to implement them in your chosen language.

• Design Patterns: Elements of Reusable Object-Oriented Software
  
  
• Game Programming Paterns
  
   
  
  Good General book
  
  
• Effective C++: 55 Specific Ways to Improve Your Programs and Designs
  
   
  
  This book is great if you're going to make a browser based game
  
  
• HTML5 Canvas Cookbook
  
   
  
  General Knowledge books
  
  
• Pro HTML5 Games (Expert's Voice in Web Development)
  
   
  
  Provide a working moveable 3D model with C++ and DirectX, Very cool.
  
  
• Character Animation With Direct3D
  
   
  
  More general game base building
  
  
• Game Engine Architecture, Second Edition
  
  
• Programming Game AI By Example
  
   
  
  Working product results books, little if any modification needed
  
  Releasing in a couple months (hopefully) 2 Very good books using C++ to develop by.
  
  
• Introduction to 3D Game Programming with DirectX 12
  
  
• Introduction to 3D Game Programming with DirectX 11
  
   
  
  Not presented in the best manner but still noteworthy:
  
  
• DirectX 11.1 Game Programming
  
   
  
  I used to love XNA...but now it's not feasible for commercial development. If you're a beginner to game design...starting out with XNA might actually be useful. It's easy to pickup and put out a working product. XNA is C#
  
   
  
  
• Learning XNA 4.0: Game Development for the PC, Xbox 360, and Windows Phone 7
  
  
• XNA Game Studio 4.0 Programming: Developing for Windows Phone 7 and Xbox 360
  
  
• XNA 4.0 Game Development by Example: Beginners Guide
  
  
• Beginning XNA 3.0 Game Programming: From Novice to Professional (Expert's Voice in XNA)
  
  
• XNA 3.0 Game Programming Recipes: A Problem-Solution Approach (Expert's Voice in XNA)
  
  
• Building XNA 2.0 Games: A Practical Guide for Independent Game Development (Books for Professionals by Professionals)
  
   
  
  Working product books, modification needed to make run on current systems
  
  
  Provides a working FPS game in C++ on DirectX 9. Good for some starting out knowledge for an FPS
  
  
• Programming Mutliplayer FPS Direct X
  
   
  
  Good for 3D Terrain rendering in DX9...however much of this is outdated...some concepts still apply, and it's not the worst idea to see a working example.
  
  
• Real-Time 3D Terrain Engines Using C++ and DirectX9 (Charles River Media Game Development)
  
   
  
  TLDR: Click links starting at top, buy, read, profit

Are you looking for how to make games? Not just programming, but actually make them? I have some suggestions, but they often aren't about programming. There is a million books about programming, but finding those that talk about the ideas and ways to successively improve is a better point to start from.

• The Art of Game Design: A Book of Lenses
  
• Game Design Workshop: A Playcentric Approach to Creating Innovative Games
  
• Kobold Guide to Board Game Design
  
  Making video games is easy. Put the pitchfork down and let me explain. Anyone can open unity and load some assets and call it a game. Making good games is difficult, and even if you are not looking at card/board games, you should be prepared to test your game on paper. It is easier to make iterative improvement if you can look for mechanical and mathematical issues by scrawling some notes on paper cards.
  
  For a book that covers both programming and game design, I also suggest this one.
  
  These books will cover the psychology, the pitfalls, etc that come with making a game. You do not need a class to make a game portfolio. You can often get things done faster by a book, because it's goal is to teach as you read, not set a timer for 15 weeks. It can assume you will do it over 26 weeks or more if the book is huge.
  
  Anyway, this is a much larger reply than I intended. Hopefully these are informative. If nothing else, they are significantly cheaper than a class.

Alright, in that case it sounds like you can benefit from 'the general advice':

1. Make a 'vertical slice' of the game as early as possible. Networking, animation, scene loading, GUI, etc. This will ensure that every major library and tool you need gets in there early, and you workaround the conflicts between them before it becomes a burden to insert a new one. One of the big mistakes on one an early projects was to leave the entire GUI to the last minute, but because that 'conflicts' with general user input it was a huge chore to workaround certain issues after a lot of the user input code was in place.
   
   
2. Trello is a handy tool for managing tasks, but I'm sure there are other perfectly good alternatives. Despite what you use, update your task list often and make sure you break things down into bite-size chunks that can be accomplished within between an hour or an entire day. That way you're always making progress and keeping your motivation up as that list gets shorter (although it will inevitably keep getting bigger as you break things down more, or remember things you forgot originally)
   
   
3. If its taking forever and motivation is going down the tubes, cut features. Don't debate, don't haggle, just start cutting features to trim down the workload and get yourself back on track.
   
   
4. Source control. Use it. Git with Bitbucket, or TortoiseSVN and VisualSVN Server Manager are my go-to solutions. It's both a log of your activity and your only saviour when things go wrong.
   
   
5. Don't be afraid to tell people about your project, and never tell yourself someone is going to steal your idea, because you need as much feedback as you can get. And the earlier the better. My wife asked me why I'm so cavalier about telling people about my current project even though I'm only a couple of weeks into it, and its because everyone has their own project that they believe in, and when I mention my project to someone they're more likely to give advice on how to make mine better, or more like their own project (unconsciously giving away their own 'secret sauce' recipe), than they are to steal it and build out a competing product. People will only bother stealing an idea that's already been proven to work.
   
   
6. Read books on game development and clean coding practices (if you haven't already). You'll be amazed what great lessons people are willing to impart for next to nothing, or even free (like I'm doing for you right now, incidentally). Two of my favourites are Game Coding Complete and Clean Code - A Handbook of Agile Software Craftsmanship.

C++ has been around for exactly 30, what i mean by that is that it's still widely used in production until this day, and doesn't look like it's gonna change any time soon. it's more then any other language out there, with C as an exception. I'm not sure C# would be valid in 10 or 20 years, but C++ would.

Your best resource for learning C++ would be good books. Like i mentioned, i highly recommend The C++ Programming Language, 4th Edition, it's updated and very complete reference to the language. there's also Effective C++ - it's not for beginners.

There's right, you won't find too much resources about C++ at first glance, but you will if you will dig a bit deeper.

Here's few sites that you should use:

• C++ reference
  
• The C++ Resources Network
  
• Boost
  
  You also might find some useful stuff and links in the Google+ C++ Community
  
  
  Other people and myself have mentioned learning C++ is not easy, partly is because the lake of documentation on the web. but once you know the language well, you will enjoy it's benefits. It's not for everyone though. I also recommend looking into new technologies like emscripten, it allows to compile C++ code into JavaScript, understand the implications of that, and maybe you will also have my POV.

There are lots of books that purport to do something like this, but the field is so varied in terms of tools and styles, it's kind of a fool's errand. One merely ends up writing a, Here's How I Did-It/Would-Have-Done It.

One book I like that is very comprehensive when it comes to game design is The Art of Game Design. It does try to address the practical matters of making a game, but that's not its primary focus.

One book I would recommend for finishing is The Game Jam Survival Guide and just doing a game jam like ludum dare. A game jam is a great way to get experience finishing a game, and time is so tightly constrained that it forces a very different, scope-limited mindset. The ideal is never, ever attainable and yet some really creative, amazing games do come out of these jams.

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.

I think your major problem here is that you want the "why not"s instead of the "why"s. A good programmer can look at a chunk of code and determine "why" the programmer is doing certain things. These pre-extising code blocks that people refer to are given because you should be able to read through it and interpret what's going on and why. The questions you most likely ask at the "interpreting" stage isn't "why" but instead "why that way and not this way?"

Really, when it comes down to it, the answer as to that question for a lot of things in engine programming (or just programming in general) is that it's what the lead designer or lead programmer thought was the best idea.

For instance: How do you want to store your array of tiles? As integers representing tile indexes in a tile set? As separate Tile class instances in a vector array containing vector arrays of Tile instances? As a hashmap indexed using characters to grab a tile? etc. There's a million ways to handle each and every part of an engine, it all comes down to what design patterns and what theories you think are the best for what you need your engine to do.

I suggest reading up on some of the design patterns in here (actual link in the sidebar) and here. They're a great way to start understanding the multitudes of ways of handling different ideas in your engine! Reading up on pre-existing theory or seeing pre-existing pseudo-code is fine and dandy, but sometimes you have to reinvent the wheel. Sometimes, for the most part you can follow a lot of design patterns that already exist.

P.S. For a great tutorial on loading tile maps and working with them in your game, lazyfoo's got you covered (it's in C++ but can easily be adapted for other languages) Here

This is really cool! Thank you.

>A common question is whether the book is still relevant. After all it's over ten years old

I find that some old(ish) books can really hold some great significance, for example: Effective C++ and Clean code have both given me some brilliant tips on making better code. I'm also readingWrite Great Code. If you have any more books i'd love to see them :) Thank you, again.

First Advice! Don't listen to high school guidance counsellors.

You require certain high school courses to qualify for College or University programs. What you want (ideally) is a 3 Year University Bachelor's Degree in Computer Science with a Minor in Game Development. Figure out which schools you're interested in and what they require for admissions to their programs.

You're probably hoping to start making games now though, so I'll give you some advice on that.

Try to get a copy of this book: http://gameenginebook.com/

It's kind of a heavy book, both figuratively and literally, but it'll teach you everything about how a video game works. Even if you're not going to be building this or that part of a game, it's important to know how it all works and fits together.

This YouTube Channel Extra Credits has a lot of great video articles on game design and development, and links to other channels.

You can find a ton of guides on YouTube for computer programming, game design, 3D modelling, music, etc. The key word to search for is Tutorial.

Once you've learned how to program computers, you should read this book to learn how to program computers well: Design Patterns: Elements of Reusable Object-Oriented Software

It's a pretty old book, but that's because nobody has had reason to update it; it's just that good. That said, a smart fellow released a free web-based followup book for Game Developers here: http://gameprogrammingpatterns.com/

If you want to focus on Game Design I'm a big fan of Raph Koster so here's his book too: http://www.theoryoffun.com/

I guess the rest is up to you. Any specific questions?

If your goal is to practice code and just have fun, slinging low level game logic is really satisfying. (obviously if your goal was to actually make a game, or to make an actual usable/popular engine, you'd want to heed all the usual warnings)

Have you made a game at all before? I think a big part of making an engine is knowing a lot about what NOT to do. Especially early on (e.g. the first few YEARS of gamedev) there's a lot of learning the hard way. Make the core gameplay for some game, get frustrated because it's becoming a pile of spaghetti code, have a moment of enlightenment about better design, then start over from scratch. You'd probably be able to follow a "build your own game engine" book, but the lessons and reasons wouldn't really sink in without that personal experience.

Probably because of the above, many successful game engines simply start as a regular game. Good code gets reused, bad code gets refactored to make a second game. Repeat this often enough and you have sturdy, proven code that's evolved into an engine. Instead of trying to plan for infinite possibilities in the future, create what's actually needed for the next game (while attempting to not break the previous games). This has been working well for me so far.

But, feel free to jump directly into engine-making if it sounds awesome to you. It's still on my to-read list, but this book has pretty good reviews and might be up your alley.

I'm like you, I'm a programmer not a designer. I often times will get stuck because I feel the need to iterate on an idea over and over until it's perfect, but by that time I'm bored of it and I move on to something else. Unfortunately, there is no real way to know if a design is good until you've made something you can interact with. This is something that occurs quite frequently in the professional game design world as well. So, my solution has been to force myself to implement my initial designs so I can play it. Then, and only then, will I allow myself to iterate on the design.

Also, my base metric for a game is "Would I play this game?" If the answer is yes, then I make it. Chances are if I like it, others will as well.

Also, I would say pick up a copy of The Art of Game Design. It breaks down the different aspects of games and explains them in great detail. Some examples are the balance between skill and luck, storytelling, risk and return, etc.

I would love to add Level up by Scott Rogers (https://www.amazon.com/Level-Guide-Great-Video-Design/dp/1118877160) to the mix. I'm​ also writing for video games on indie scale tho.

Scott Rogers book is also about level design and that's important part of story telling in video game medium. For most, a lot of text is going to be dismissed by a lot of players so lot of the storytelling is good to come from somewhere else. Visuals, level design, character design etc. You need to learn from the start a good script format that is easy to understand for you and someone else reading. You can find a lot of formation online and even BBC scripts to read if you want from http://www.bbc.co.uk/writersroom/

Fundamentals like many here has stated are good place to start. Story crafting, plot devices and analysing your favourite games, movies I and TV series. Maybe check http://tvtropes.org/ and find your favourite game protagonist and read up what tropes writers used on them and how it shows.

Games as a story telling device are mix of visuals, plain text and user interaction and that mix is what makes a story in a video game. That's why a lot of video games have not so immersive story as script writers are tend to bring to the mix later in the development when level design has maybe been set in stone and coded.

I assume you want to make a story script for a game. I would recommend learning a formation for a basic film script or use celtx.com straight away because it's easier for you to get into scene thinking and also for your future co-workers. Celtx.com is free script writing tool, you should look up. (https://www.celtx.com/index.html)

And also read all comments above about learning fundamentals and skills to analyze the story arcs and storytelling. To write you must first read.

Writing an engine isn't a trivial task. I don't mean to put you down or make you feel bad but it kind of sounds like you don't totally understand what a game engine does.

If you do want to write an engine, I would suggest starting with the renderer and expanding your understanding from there. The features of your engine depend upon what kind of game features you want to support. Particles? Visual effects? 3D sounds? Dynamic Resource management? and all of that behind the gameplay code.

Just get a square to show up on the screen. While you're working on that, check out a few books on game engine programming. There are a ton on amazon. This one is really good:

http://www.amazon.com/Engine-Architecture-Second-Jason-Gregory/dp/1466560010/ref=sr_1_1?ie=UTF8&qid=1453134607&sr=8-1&keywords=game+engine+architecture

If you need some more help getting started let me know! Engine programming is fun and rewarding but building one from scratch can be a monumental task.

I wasn't very confident, I actually pushed out the Kickstarter kind of fast because I didn't want to come out just as or after Spacebase DF-9 was announced.

There was no initial following. First PR move I made was actually a test - I put the first look video (https://www.youtube.com/watch?v=vV6wyeZ7458) up on Reddit and elsewhere and tried to gauge the response. When the response was very strong, I moved forward with Kickstarter a few weeks later. For KS, I was confident enough to put the goal at 20k; that's about it. I was pretty sure I could hit that number. Of course the game did 13x that amount, but this was very much not anticipated :P

Basically, I think PR works the same as game design. Develop the pitch, test it on people, see what they respond to, emphasize that, replace the rest, repeat until every part of the pitch hits really well. I'd been refining the RimWorld pitch for about 5 months on friends, family, and acquaintances just by explaining it and watching their facial expressions as I mentioned different points. By the time of the KS I knew (not thought) that every point worked - DF-like, sci fi colony, western theme, Firefly/dune inspiration. I'd cut the parts that didn't work, like the good/evil colony idea.

RW also had a nearly unheard-of advantage on Kickstarter, which was that it worked and was already fun (which I was confident of, again, because I had run lots of controlled playtests and refined the game for about 5 months by then). Got lots of traffic from people who came from YouTube vids of people playing the journalist-only pre-pre-alpha.

<ShamelessPlug>I've written much more at length on game design in general in my book: http://www.amazon.com/gp/product/1449337937 </ShamelessPlug>

I highly recommend Real-Time Collision Detection.

This next book might not apply to your field directly, but I believe it is a good idea to be at the very least aware of what it discusses, and it is a very excellent book on its subject: The Art of Game Design: A Book of Lenses

I recommend this book as more of a reference than a tutorial; it will allow you to quickly brush up on those areas of math and physics which you will need while writing (or perhaps working with) a physics engine. I don't recommend attempting to learn the subjects through this book alone though. Game Physics

Reading 3D Math primer for Graphics and Game Development is how I learned linear algebra, although I plan on studying the subject from a textbook when I get the opportunity. I keep the book close for easy reference of the math related to 3D rendering (such as the projection and view matrices), although if you get this book you will want to read the errata document on its website. There may be better books to teach this stuff now, so please don't jump on it too hastily.

A couple books I do not own, but plan to correct that as soon as I can:
Game Physics Pearls and Real-Time Shadows

If I think of any others, I will edit this comment.

There is actually a lot of good reading about level design out there. I can't remember all of the books/articles off hand, but I'll see if I can throw some links together.

Edit:
This one had a lot of good theory and concepts

Great book. If you are going to spend some money to buy a book, get this.

Also, I would recommend playing through games with good level design and breaking down each design choice. Getting a few overhead maps helps too. Start with old games, because their levels/art is often more simple and easier to pick apart. Then move up in generations to get a feel for how people tackle more complicated scenes and designs.

I am not sure what aspect you are interested in. The set dressing or the actual level design, but there are some differences between the too.

I found "Level Up! The guide to great video game design" to be an interesting book that describes on what you should aim for in your game mechanics, enemies and such. Plus pretty easy to read, both in length and content.

I haven't read this other one, but I've heard Rules of play is a pretty good one too.

Another great source are youtube channels. My personal favorite is Extra Credits. I'm just about to get into the industry so it might be worth keeping that in mind ^^"

Since some other people are trying to be cute, start with this wikipedia page here: https://en.wikipedia.org/wiki/Software_design .

I don't know of any online tutorials for the process of game development, but I am aware of a book named Software Engineering for Game Developers which goes over the process, step-by-step, of designing, outlining, and implementing the software part of a game. Note that this is one of the most dry, boring books on games I have ever read, but it's not about game design, it's about game development, and outlining software requirements is not a topic many people get excited about.

Basically, they go through the process of creating a requirements document which is a glorified to-do list of everything that the game needs to do, dividing those specific requirements into "stripes" which are different levels of completeness of your game, and then from there deciding on the best way to chop up the concepts into objects. The book is a monster 1000 page beast, but if you're serious about needing a step-by-step process, you won't get better than this.

My suggestion (if you don't purchase or, ah, otherwise obtain a pdf of the book) would be to simply start with this glorified To-do list that lists every feature your program should have in version 1. Then write up all the subfeatures that those features will require. Then divide all these items into groups where it makes sense and make each group an object (or object hierarchy). Do some research and see what parts might already exist, such as rendering, graphing, input, GUI, or serialization libraries, and incorporate them into the design. If you don't know what, exactly, goes into a game, try looking up a book such as Game Engine Architecture which will outline all the different parts that a game engine needs.

Then write the program.

Note where your design was insufficient or flawed, and don't worry about keeping the list intact--add or remove items as needed. Wash, rinse, repeat: the more you practice this on new programs, the easier it will be as you gain experience with what needs to be written out and what can be ad-libbed. The more advanced tools (such as UML et al) will be useful later, when you have more complex projects with more moving parts, that need to be explained to other programmers.

Until then just stick with lists.

I find tutorials to be decent for learning how to perform simple tasks which don't require much variation or novel problem solving. As it turns out, making games is pretty much the exact opposite of that. I know from experience that it can be frustrating to find information on stuff like architecture and system design for games, but a lot of that is pretty much tribal knowledge, learned by professionals on the job or by hobbyists as they make projects.

I recommend reading articles on Gamasutra for more advanced topics, and I also recommend the book Game Engine Architecture by Jason Gregory. I think really the best thing you can do is try to do a more complicated project and as you run into problems you have trouble solving on your own, then research that specific topic. It's worth trying to solve the problem on your own first though, as while it may involve reinventing the wheel somewhat, it's also the best way to learn.

Well it sounds like its time to start prototyping and analyzing what does and doesn't meet your documents/requirements. Getting these out should motivate your team and make you feel a bit more confident in what to do next.

As far as looking for resources, there are quite a few out there. I really recommend checking out The Art of Game Design by Jesse Schell, it's one of the most practical books on game design (a lot like Raph Koster's are way more theoretical). I'd also check out gamasutra for a great design-focused community, there's a lot of resources there that can help you out.

Also, don't worry if everything falls apart. Game design is a lot of work and people can tend to be pretty flaky about it. That's why I've tried to learn every aspect of development so I don't have to depend on others.

Although I agree with the others and good coding pillars are important. C# can be incredibly easy to learn and as such it's great for beginners to start with. Focus small and build up from there. I would write simple console apps understanding the core concepts before you move into actual gamedev coding. Without a strong fundamental grasp of how C# works you'll end up rewriting code in your game later on as you learn new things. You might spend a good chunk of time doing something a very tedious way only to discover that there is a much easier way later on. Also as others have said code agnostic coding pillars are very important. Some good books:
https://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612
http://gameprogrammingpatterns.com/contents.html

Understanding how to structure your code is very important.

Well, when talking about code maintainability it's not the same thing.

It's clear that both of you do not understand the concept of clean code. That's why you guys think that there is some language barrier that does not exist since you guys do not know what concept I'm talking about.

There is some stuff that's very valuable for every programmer to read and I recommend for you guys.

Clean Code

Working Effectively with Legacy Code

The SOLID principles

Those are very good books, give it a try and you might thank me later.

Have a nice day to you too Inukai!

You know, a fantastic book is Programming Game AI By Example. It's fantastic for learning about AI, but the author also put a lot of effort into the code, so you can learn a lot about general game design from it as well. Well worth the price. http://www.amazon.com/Programming-Game-Example-Mat-Buckland/dp/1556220782 . You can download the code samples from the author's website to see what I mean. It is only 2D, so it won't help you with collision detection and some of the more 3D specific topics, but the core of the engine can be applied to anything.

One thing that is really important is to realize that there's no silver bullet. Every design decision has its benefits and its trade offs. It's easy to fall into the trap of overthinking your design, especially for personal projects - it is more beneficial for you to try to write it and have to rewrite it because of a bad design decision than to spend months trying to come up with the perfect architecture. That's not to say that you should ignore design, but rather that once you think you have a good idea, try it out, experiment, see what works and what doesn't. If you focus on having a modular design to your software, you'll find that rewrites get easier and easier.

Sounds like a fun idea! Some friends and I have been getting together and designing and playing our own games lately for our weekly gaming nights. I'll try and recruit them as well. :)

There's this great book called "Challenges for Game Designers" that might be fun, if you're looking for more inspiration. (though what you've got already is fantastic.) Each chapter in the book discusses a different game design problem, (pacing, puzzles, randomness, etc.) and there are challenges at the end of each section where you create a tabletop game, or at least a design document, detailing how you would make a game that addresses the problem. Anyway, love that book and wanted to mention it, ;-P

Looking forward to seeing where this goes!

I don't know enough to answer you without knowing I'm not completely wrong but I can point you in the right direction.

I recently purchased Game Coding Complete http://www.amazon.com/Game-Coding-Complete-Fourth-Edition/dp/1133776574/ref=sr_1_1?ie=UTF8&qid=1334788077&sr=8-1
and it describes a model very similar to what you're talking about (separation of game and rendering). I can't recommend this book enough, I'm only 5 chapters in and I'm already loving it. The fourth edition is freshly updated as well.

Here's the source code from book http://code.google.com/p/gamecode4/ Maybe you can answer your own question by reading it (its C++ / directx)

Sorry if you have no interest in buying a book but what you described fit the book fairly well, Good luck!

Ah, I could see that. If you grab a calc book you should be able to get lighting etc. And the rest is all linear algebra. There are a lot of really good books on the topic, but one that's really good for graphics beginners is frank Luna's, "introduction to 3d game programming" series. It doesn't matter if you're using glad or directx (you should), its a great math primer for the first few chapters. This is also a great book: http://www.amazon.com/gp/aw/d/1568817231/ref=redir_mdp_mobile

If you are going the book route, I have a few suggestions for you!

Not sure if he's a reader? Check out Challenges for Game Designers Basically a collection of game problems to solve, flexing those 'be creative within a bounded scenario' muscles that a lot of big dreamers don't have enough experience with.

Another solid choice is this one,
100 Things Every Designer Needs to Know About People (Voices That Matter). In general it's talking about layouts/formatting, but super solid read for our industry as well.

Both of these are light and fun reads. If you think they might be interested in something heavier, I can post some in that vein as well.

I agree with some points made by q00u but not all of them... my input.

I was just having a conversation with a friend of mine who likes to program. But he's really just cutting and pasting things and never really really understanding what's going on. He can't solve the basic problems that come up when coding.

Get this book:
3D Math Primer for Graphics and Game Development
http://www.amazon.com/Primer-Graphics-Development-Wordware-Library/dp/1556229119

Everyone says, "why make your own engine when you can get one for free". I made my own engine (a couple of times). Making my own engine gave me a tremendous understanding of Vectors, Matrix transformations, etc. that now using Unity3D (which I really enjoy) I'm super fast at using it as a result. You will never understand what a vector cross product is or the magic of quaternions if all you do is type transform.whatever.whatever and hope for the best in a game engine.

So go ahead and make your own engine. After you've done it a couple times, THEN seek out a pre-made one.

He's absolutely right about the New Years Eve resolution thing. Studies show the good feeling you get from telling people what your doing/going to do is just as good as the actual doing it. So people tell more and do less.

It is really common you hear "I'm an ideas guy" but what would really help is someone who knows how to get people together, organize ideas, how to collaborate etc. Knowing websites (like trello.com) and others to organize thoughts.

Signup for Trello.com (or something else) and write down ALL OF YOUR IDEAS, never begin a sentence with "this might be a stupid idea" or "this might not"... just write down everything you come up with.

The guy who made Angry Birds had 30 failures first. START TODAY and get those failures out of the way so in a year or so you can make something brilliant.

Finally... maybe we need a new subreddit called "GameDevNoob" or something?

Since you mentioned Rimworld: Tynan, the creator of Rimworld has a gamasutra post and a book about how he designs games. (Spoiler: It's all about the story experienced by the player).

I can tell you about the thought process for my colony simulator:

1. I want to have a prototype as fast as possible, so the system should be as simple as possible.
   
2. The focus of the game are the colonists, their personality and their emotions when something good or bad happens.
   
   Therefore I only have a couple (~10) resources that are not even items on the map, but are simply counted in the UI, like in a strategy game. If you're looking for inspiration, you can download it for free on the website.
   
   For your game, I think you could first think about what the focus is in your game. Do you want the player to spend more time managing resources, handling colonists, building stuff, or defending the colony? Then plan around your focus. Hope this helps you :)

Need more information. Is this a hobby? Are you trying to program a game or are you trying to design a game? And just FYI, programming is hard... programming a game is the hardest. There are many movie parts to game programming. Just be aware of that.

If you're a hobbyist and you want to learn how to make digital games, start with an easy to learn programming language like Processing. http://processing.org/

If you want to design games then pick up this book http://www.amazon.com/Rules-Play-Game-Design-Fundamentals/dp/0262240459

If you want to jump into 3d, try out http://unity3d.com/. I recommend programming in C#.

If you're a hobbyist, you don't need to delve in super deep and use complicated tools. Processing is very friendly and was designed for graphic oriented designers to learn how to program. Unity3d makes it very easy to make 3d games with specialized IDE and interface.

I've been doing a lot of research lately on the best books in programming in general to start a blog about each one and their importance to an inspiring developer. These are two of the books which will help you greatly getting started on designing your first game.

The first book is completely about design patterns, you will need to learn about these as creating software in general requires knowledge of how specific design patterns work and when you should use those patterns. The second book in the list is a complete guide to creating a small sample game, albeit not in libgdx, it should provide you with enough material to get you started.

• Design Patterns
  
• Game Code Complete
  
  I also recommend the Game Programming Patterns and Game Engine Architecture books which were stated in a previous comment. I have both these books as well as the Game Code Complete book and will be buying the Design Patterns book I mentioned as it is the most highly recommended book for any developer.

Well for game design, I cannot overstate the impact that the book The Art of Game Design has. It lists where to start building a game, how to find mechanics, how to deal with chance and map building, what the players expect, how to engage the player, how to use audio correctly and many many more. Go check it out, if you are already familiar with programming, the more the better. But to be a great game designer takes much more - and a lot of it can be found in the book.

Happy creating :)

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.

The books posted are great for 3D rendering.

However, you're a flash developer and I'm concerned about your proficiency level with C++. If you're meh at C++, then I recommend that you write some sample C++ code to get the hang of C++ before you dive into implementing 3d mathematics and rendering.

Some resources for C++:
http://www.amazon.com/C-Pointers-Dynamic-Memory-Management/dp/0471049980

Although the best way to get good at C++ is to just code in C++! :)

Also you need a strong foundation in 3D math before getting to the rendering:
http://www.amazon.com/Primer-Graphics-Development-Wordware-Library/dp/1556229119

To be clear: are you interested in game programming, or game design? (I say this because the other post said you were interested in engineering, and I'm not sure that guy knew what he was talking about) While the two do go hand-in-hand, what discipline you will be practicing is very important to be aware of. If you are interested in game design (theory behind making games, regardless of whether or not they're electronic) then some books you'd be interested in would be Jesse Schell's The Art of Game Design, reinforced by exercises from Challenges for Game Designers.

If you are interested in game programming, that would require some introductory programming knowledge before diving into it, and there are others who would know where to find books for that, like on the sidebar of /r/learnprogramming. I would not recommend diving into a game engine without some basic programming knowledge unless you use an engine like GameMaker (but even that is just putting it off to a degree).

Looks like a great book, I'll have to check it out!

In case you're interested (and didn't already know), here's the price history for your own book. Amazon's prices are all constantly fluctuating, or at least 90% of them are, and algorithms must make 99.999% of those decisions. Sites like Camelcamelcamel allow us consumers to make the best choices despite that...

Edit: just noticed the price change that presumably flagged the guys at @GeekDailyDeal was actually an increase by a few cents, though it's still cheaper than for a long time

If you are looking toward application development(games or otherwise) I'd suggest looking at more practical beginning programming books, don't even worry too much about making a game yet or building complex algorithms. I've found the Head First series fairly good in the past, so maybe try out https://www.amazon.com/Head-First-Java-Kathy-Sierra/dp/0596009208

Once you get your head around basic application development a bit more, I would highly suggest learning design patterns and can fully recommend the Head First book on that topic.
https://www.amazon.com/Head-First-Design-Patterns-Brain-Friendly/dp/0596007124
You can follow that up with the Game specific book on patterns, https://www.amazon.com/Game-Programming-Patterns-Robert-Nystrom/dp/0990582906

With all of that you should have enough to start asking more pointed questions and being able to Google up useful answers and tutorials that will get you on the road to building games.

Edit: That said, if you are looking at doing to extensive AI programming, specializing in engine design or other systems type development, start looking for books on the topic that interests you most. It's pretty easy to Google up book lists on these kinds of topics, and from there you can cross reference recommendations and should be able pick out ones that will help you get started.

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.

On YouTube Brackeys channel looks really useful: short, no-nonsense videos.
Additionally, you can find true gems of wisdom on GDC.

I'd also like to recommend a book about game design (in general): Level Up! -- The Guide to Great Video Game Design by Scott Rogers.

I personally love Programming Game AI By Example. It gives lots of very usable examples in an entertaining and understandable way. It's pretty friendly for beginners and even offers a game math primer at the start of the book. However the examples still have a lot of meat to them and thoroughly explains some important AI concepts like state machines and pathfinding.

Here's some stuff to check out..

Challenges for Game Designers- https://www.amazon.com/Challenges-Game-Designers-Brenda-Brathwaite/dp/158450580X/ref=sr_1_1?ie=UTF8&qid=1469790243&sr=8-1&keywords=challenges+for+game+designers - A good overview and tool for learning various gameplay mechanics..

Level Up: the Guide to Great Video Game Design - https://www.amazon.com/Level-Guide-Great-Video-Design/dp/1118877160/ref=sr_1_1?ie=UTF8&qid=1469790273&sr=8-1&keywords=level+up+video+game+design - A nice overview of game design in general, which is good to know even if you're only pursuing level design at the moment

Game Maker's Toolkit - https://www.youtube.com/user/McBacon1337/videos - A really good series on game and level design

Reverse Design Series - http://thegamedesignforum.com/books/books.html - Books that deconstruct games in order to learn from them.. I'm going through the Super Mario World one right now and learning some nice things from it..

Some Reddit posts..

https://www.reddit.com/r/gamedesign/comments/35rvec/puzzle_design_how_i_do_it/ - I found this helpful back when I first read it.. o.o;

https://www.reddit.com/r/gamedev/comments/4remqy/a_fast_and_simple_method_for_writing_compelling/ - Nice stuff to keep in mind when designing story flow in levels..

Deviating a bit here.. but..

https://www.reddit.com/r/gamedev/comments/23oxp6/build_a_bad_guy_workshop_designing_enemies_for/ - A nice breakdown of enemy types in mostly 2D platform style games.. but a good reference

https://www.reddit.com/r/gamedev/comments/3p3z05/game_feel_why_your_death_animation_sucks/ - Some game feel videos

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.

An artist. :P

No but seriously, here are some things I'd love to be gifted as an indie game dev (if I didn't have them already):

• Rules of Play. It's maybe getting a little harder to find at a reasonable price, but is a wonderful resource. Some people pan it as a beginner textbook, but as a 10-year game dev veteran I still go back to it occasionally and it reminds me about fundamentals I've let slip over the years. Worth every penny.
  
• Envisioning Information. Not directly game dev related, but it's a definitive resource for the kinds of visual design problems we have to solve every day (and that so, so many game devs simply don't know anything about, sadly).
  
• The Design of Everyday Things. You can probably get this in paperback for super cheap. It's old, and it's about industrial design, but more importantly it's usability. The core principles in this book should be the backbone of any game designer's education.
  
• Got an excellent card/board game shop in the area? Gift certificate the fuck out of the bitch. (Video game devs loooove tabletop games. Yes, we're even bigger nerds than you thought.)

Rules of Play is an amazing book, it's a shame you haven't read it. Its one big drawback is that it focuses very little on video games in particular and goes in-depth on what separates games from non-games, and how various kinds of games are constructed.

It may not be useful to someone looking to get their hands dirty and start throwing Flash at the Internet, but it's a very good "big picture" book when you want to know more about the philosophy and mindset of building games. How to encourage behaviors, how to subtly direct play so your players don't get lost or confused, how and why you give feedback via play mechanics, and things like that.

I've been working on games for quite a long while so I picked it up here and there.

I haven't gone through this particular series myself, but I've browsed through it and his (thebennybox - everything he makes is high quality) series on creating a software renderer, and they are fantastic!

https://www.youtube.com/watch?v=ss3AnSxJ2X8&list=PLEETnX-uPtBXP_B2yupUKlflXBznWIlL5

This is by far my favorite book:

https://www.amazon.com/Engine-Architecture-Second-Jason-Gregory/dp/1466560010

I'd recommend thebennybox's video series first, the book may not be quite as beginner-friendly.

Based on the roadmap link posted elsewhere in the thread:

https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-837-computer-graphics-fall-2012/

https://www.edx.org/course/computer-graphics-uc-san-diegox-cse167x-2

From personal knowledge, I'd also check out Udacity's course:

https://www.udacity.com/course/interactive-3d-graphics--cs291

and maybe Coursera's (personally did not care for it, but might as well list it):

https://www.coursera.org/learn/interactive-computer-graphics

As for architecture, I haven't really seen any great lectures on doing this. I'd recommend checking out the book of the same name to get a high level overview of the features larger engines consider, and perhaps check out the source of some larger engines to get the best idea.

The Starcraft Broodwar API has source code for a bunch of bots from the annual competition at AIIDE. You can find them here. They use a variety of techniques that will help you set you in the right direction.

I'd recommend this book too if you're interested in AI. It's the most comprehensive survey of the most common techniques used in the industry today.

Good luck!

Artificial Intelligence for Games is a great book. Additionally, the various volumes of the AI Game Programming Wisdom series have some great examples.

​

Get a book or two (& free app from book of lenses itunes store or play store

Hit up your local book store and library to get a good look at what's available, explore all sections frequently.

Learn some art

Buy assets.

Here's some sexy stuff.

Get a Git to keep your goods on.

Hands on, in person, training is way behind the times as far as education is concerned.

Get Unity Certifiied.

Get Live Training

Check with your library they may off Lynda.com for free.

Get a big android tablet to build games for and show off at the office.

Join Meetup.com and look for local game developer groups.

Check the closest community college for game design class, if not see how much basic drawing, life drawing and basic design principles cost, if it's more than $500, try meetup.com and youtube/lynda or udemy or coursera to cover those experiences.

Use the force,

I bought this book solely for its section on quaternions (very well explained), but the rest of it is pretty good too. It covers a wide range of maths needed in 3D graphics and explains them well.

Most of its content isn't relevant to 2D, but I'd say it's a worthwhile purchase in the long run.

Although it is indeed impossible to cater to everyone's needs, I think there are many cravings shared by all of us.

Anyway, giving it a bit more thought, I think that instead of "addiction", the term "engagement" might suit you as well (since both end up getting the player hooked to your game but from different reasons) and even in a happier way so to speak.

In that case, analyzing your design through tools like the MDA and many of the lenses might help you.

There isn't a completely language agnostic book out there like you'd find with say Code Complete, but there are two books that fit your description but neither is really a beginner text.

 

Game Coding Complete

and

Game Programming Patterns, much of which is available on his website.



Once you get a bit more (ok, a lot more experienced), Game Engine Architecture is another great read.

 

Other than those 3 books, almost everything else is technology or language specific... like Learning Unity 5 or Learning Inverse Kinematics for __, etc.

 

While you are just starting out however, you should consider the beginners guide on Gamefromscratch, followed by various tutorial series or game engine overviews, as you aren't at the point where you really need to buy a book yet.

Also Effective C++, because it's full of gotchas and important but subtle language features that are ideal for interview questions. A lot of it will be too advanced for a jr. level interview, but you should read it anyway because it's a great book.

Two books (and you can google talks by the authors).

Jesse Schelle - a book explicitly based on pattern languages (from Alexander's A Pattern Language)
https://www.amazon.com/Art-Game-Design-Book-Lenses/dp/0123694965

Richard Bartle - how do design virtual worlds / types of players / motivations / etc.
https://www.amazon.com/Designing-Virtual-Worlds-Richard-Bartle/dp/0131018167/ref=sr_1_1?keywords=bartle+designing+online+worlds&qid=1554913435&s=books&sr=1-1-spell

Both have given talks, etc. etc. etc. that are online, but both books are superb.

I can provide lots more to look at but those pretty much bracket what you are asking for and both authors are VERY knowledgeable.

Bartle was the co-author of the first shared world game, for example.

Game Engine Architecture is a pretty good overview of how to put a game engine together in general, from tools to graphics to game-play systems. You can pretty easily take what's in it and use it to make a 2D game. (3D math is also useful in 2D!)

Edit: Game Coding Complete (https://www.amazon.com/Game-Coding-Complete-Fourth-McShaffry/dp/1133776574/ref=sr_1_1?ie=UTF8&qid=1484886864&sr=8-1&keywords=game+coding+complete) was also a decent read, though not nearly as in-depth as Game Engine Architecture.

That is a great book with a math primer and continued coverage as you get deeper into the specifics of collision detection. I also own this which does a better job teaching plain math relevant to game dev and is agnostic about whether it applies to collision, physics, or rendering:

http://www.amazon.com/Mathematics-Programming-Computer-Graphics-Third/dp/1435458869/

I highly recommend it. It's well ordered and well written. It is the quality you'd expect from something you pay for and will save you time with its completeness and clarity.

This is exactly what I was thinking when reading this. As someone who has been coding and doing code reviews for 20+ years, comments almost always lie eventually. They are an extra point of maintenance and most people don't maintain them when changing code.

As for long functions, your functions should really be doing one thing. A long function is a smell that tells me it is probably doing too much. The more you get into the habit of keeping things small, the more you realize how much easier it is to reason about the code you're writing and reading.

This book by Uncle Bob Martin is pretty great. Am I telling you to change your style? No. But like the person above me, I am imploring you to read more on the subject and come to your own determination.

"I've never tried graphics programming (OpenGL or otherwise), but sure... this post looks intriguing"

[Opens the link]

"Looks like a well written and informative tutorial, but I don't know most of the stuff he's writing about"

[Goes down the rabbit hole of OpenGL information]

"Damn it, now I HAVE to learn OpenGL from the start. Been looking for an excuse to brush up on my C++ skills anyways."

[Bookmarks the webpage]

"I wonder I need to brush up on my math skills also? Oh well, guess I'll cross that bridge when I come to it"

[Thinks of that book I bought that's collecting dust on the bookshelf]

:)

The 2nd edition came out in 2014. It's good for an overview of commonly useful systems and what production teams need from them. It doesn't go into great detail. [EDIT] d'oh I was slow.

Real-time Rendering has a 4th Edition coming out soon with more up-to-date info.

Given your experience, it sounds like your math's probably strong, but if you want review Eric Lengyel has a new book out that I heard is good: https://www.amazon.com/Foundations-Game-Engine-Development-Mathematics/dp/0985811749

For AI:

Game AI By Example is an older one that provides a decent baseline if you're not very familiar with game AI: https://www.amazon.com/Programming-Example-Wordware-Developers-Library/dp/1556220782

And a lot of more recent info and course material is on at http://aigamedev.com/ which I guess has turned into https://nucl.ai/

Also some of the old Game Programming Gems have random chapters on AI techniques.

Also go look at the popular engines, do their AI tutorials, then try to look at the code. The Behave plugin for Unity does behavior trees, and UE4 has a behavior tree system you can read about.

Behavior trees aren't the newest thing though, look at the talk catalogue for the GDC 2018 AI Summit.

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!

Hey so I don't know gamedev's opinion on the book Level up!, But that's the first book about game design that I got when I started and it helped me understand a lot about the process of game design.

It is a very frustrating but very rewarding process. In the end when people try your game and you see them have a blast, that is the best feeling ever.

This book should have everything you need. It's accessible, quite funny at times, but has a good introduction to everything from finite state machines and communication (what boxhacker described), to pathfinding and goal seeking behavior. What's best is that they have sample c++ code on their website you can look through.

If you write your code in a meaningful, clean and understandable way itself, comments are almost useless and, in many cases, a source of misunderstanding and mistakes (especially working with other people). If you add too many comments, you need to update them with every single change you make to the code to keep them useful, which is an extra maintenance cost.

Suggestions:

• Name your variables and methods properly, sometimes people name things with cryptic and short names hard to understand.
  
• Use refactoring techniques, design patterns (when appropriate) and SOLID principles to make code clean, familiar, easy to maintain and extend.
  
  After 10 years of experience as a programmer working on different teams, my opinion is the fewer comments, the better.
  
  I recommend you this book, a classic: https://www.amazon.es/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

Level Up by Scott Rogers is great! I've had my tattered copy for years and it's by far one of the best game dev books I've read. He also goes over a lot more things than level design, so I'd highly recommend it.

The Art of Game Design is a fantastic book focused on exposing all of the different ways to look at game design and all the different options and approaches you can explore. I highly recommend it.

As for me, I look at why a core mechanic works in an existing game break it down into the most abstract components. Like Punchout is about learning timing and sequence recognition. Reacting quickly to an enemy's "tell" makes me feel powerful, and not knowing the "tell" makes me want to explore and try things out and challenge my intuition. So apply it to something else, what else requires reflexes and discovering enemy patterns? I unno... Ping pong? Ping pong requires finess and I want a discreet Turing nature to the success of my volleys, can I simplify the controls? What about that game where I put my hand on top of yours and you have to slap my hand before I pull them away? Whack-a-mole requires reflex but the pattern is random, can I change that?

Just break down games into the smallest components and know that that is something that can be explored and try mixing things up

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.

If you like books, I've been reading this one lately Programming Game AI by Example:
http://www.amazon.com/Programming-Game-Example-Mat-Buckland/dp/1556220782

I'm really enjoying it and it has a tonne of useful information. Read some of the pages on the Amazon site and see if it sounds interesting for you.

I would start with the book Real-Time Rendering. It's pretty much the book on graphics programming. I don't think there's a single graphics programmer at my company who doesn't own a copy.

I'd combine that with the code samples that come with the DirectX SDK. I personally found the DX10 samples to be better learning material than the DX11 samples (which tended to be less beginner-oriented). Your mileage may vary.

Finally, if you have access to an existing code base, a great way to learn things is to just start modifying existing shaders. This frees you from needing to deal with the API calls, etc and lets you get right to learning how shaders work.

That book is sort of an applied version of the "Design Patterns" book by the "Gang of Four" that is frequently mentioned by the author. The "Design Patterns" book is an excellent reference book to have on hand that I would recommend to any developer. I have both books and of all my programming books (and I have a lot of them) they are probably my two favorites out of the bunch.

I found the 3D Math Primer for Graphics and Game Development super useful as a general introduction and reference for a lot of the mathematical concepts used in game development.

Not really specific for any libraries, but always useful to have good mathematical grounding to build on.

I've decided that for my summer project before starting university I'm going to make a game with hopes that it will be somewhat similar to the kingdom hearts series.


As a 3D artist I have a lot of work cut out for me, especially considering I have about 3 and a half months to do this. I hope to do it all using just UE4, 3DS Max and Photoshop, being solo the whole time. Now I just need to go back through my old work to refresh some key aspects to game design and read this book again.


Wish me luck!

I haven't really made anything that's screenshot worthy yet. I'm almost done with the world editor so when I get that done I'll finally be able to show off some stuff.

As far as tutorials your probably not going to find anything that's specific to 2d. I mostly do 3d graphics programming so most of my shader knowledge comes from doing that, almost anything you do in 3d translates pretty easily to 2d.

Here are some good books I've read on shaders:

• Real-Time Rendering
  
• Graphics Shaders: Theory and Practice
  
• OpenGL 4.0 Shading Language Cookbook

https://www.amazon.com/Challenges-Game-Designers-Brenda-Brathwaite/dp/158450580X

Can't recommend this book highly enough, but to be honest you need to be in a group of people to get the most out of it. I basically built my introductory game design class on it. Great introduction and practice for game design.

Have you read Jesse Schell's Art of Game Design book? It's a great read for game designers if you don't have it as a reference.

In it, he gives you some good lenses to look through that encompasses almost every game design decision you should be making for your game. I am positive there is a lens in the book that you can look through for your game that addresses your unwillingness to bend reality to accommodate intriguing game ideas. Remember your audience isn't yourself or your own personal tastes, if something doesn't make sense for you, maybe prototype the idea and playtest it with some folks and then judge whether the idea is indeed enhancing the game experience, if so it shouldn't matter much if it makes sense to you or reality or not.

+1 for Challenges for Game Designers, that book is great!

Designing Games was also another one that I found was pretty good.

Read books. It might be boring, but a lot more informational than watching a youtube video.

If you already know how to program in another (preferably OOP) language there's The C++ Programming Language or C++ Primer if you want to learn C++11 (not to be confused with C++ Primer Plus, which is a different book 'series')

If you don't know how to program and you want to learn C++ for game development there's Beginning C++ Game Programming, which starts at the beginning (variables are one of the first things explained). After that book you should read up Introduction to Algorithms to make sure you're not writing horrible inefficient programs. Then there's Design Patterns: Elements of Reusable Object-Oriented Software to teach you more about certain patterns used in programs design (needed when using Ogre3D for example. Ogre3D was 90% magic to me until I read about Design Patterns. :p As alternative to DP:EoROOS there's Head First Design Patterns, but it's Java-centric which is a whole other beast than C++.

After those books there's this Stackoverflow thread. Read the first answer (the gigantic list of books). The thread used to be a ton of comments (with the most votes comments on top), but all anwers got copied to the first comment, so it's all sorted on votes. Code Complete (2nd edition) was the most upvoted one, The Pragmatic Programmer was the 2nd most upvoted one, etc.

Then there's this Stackoverflow thread, which is more C++ centric.

I hope this helps :)

My best award on the subject goes to:

https://www.amazon.com/Game-Mechanics-Advanced-Design-Voices/dp/0321820274

Otherwise, I like how the balance is described in

https://www.amazon.com/Designing-Games-Guide-Engineering-Experiences/dp/1449337937/ref=sr_1_1?s=books&ie=UTF8&qid=1492365738&sr=1-1&keywords=designing+games

and

https://www.amazon.com/Art-Game-Design-Lenses-Second/dp/1466598646/ref=sr_1_1?s=books&ie=UTF8&qid=1492365764&sr=1-1&keywords=art+of+game+design

I also highly recommend for game developers lacking in math skills to check out 3D Math Primer for Graphics and Game Development. Unlike this book that is often recommended, I feel it does a better job for people who don't have a formal education in advanced mathematics or Computer Science who are interested in math directly relating to game development.

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.

I found Level Up! by Scott Rogers to be a good book to recommend for people thinking about becoming a dev. Nice, funny writing style that doesn't get too technical.

Mathematics for 3D Game Programming and Computer Graphics is supposed to be the best, from a few recommendations.

I can't tell you how good it is myself, it's still on my "to read" list. I have had a look at the contents pages and a quick flick through though, and I can say that it contains pretty much everything I learnt in my Computer Graphics MSc, and a ton of other stuff.

Have to add another recommendation for The Art of Game Design by Jesse Schell. A Theory of Fun for Game Design by Raph Koster is also a very good, accessible read (and heavily illustrated, which is always nice!)

Finally, Rules of Play: Game Design Fundamentals is good for a more exhaustive, technical look at game design theories.

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

I'm on a mobile so can't give you the in-depth comment that I want to yet, but for now 2 books spring to mind. A theory of fun for game design, and, the art of game design: a book of lenses. The latter option was especially helpful for me when I found myself in your position.

edit: added links, formatting

My top three books are:


https://www.amazon.com/Art-Game-Design-Book-Lenses/dp/0123694965

https://www.amazon.com/David-Perry-Game-Design-Brainstorming/dp/1584506687

(more like an index of game design terms, ideal for brainstorming)

https://www.amazon.com/Game-Programming-Patterns-Robert-Nystrom/dp/0990582906

(more related to programming, but can give you a great insight how games should be structured, which can inform some design decisions)

Looks like a good reading. Thanks for the suggestions, this book is next after I finish The Art of Game Design both of which, I think, will help me a lot to see and plan the 'big picture' before I start a project.

I read this one and thought it was pretty good. It's pretty simple and gets across the points fairly well and didn't feel overwhelming like some other books on the subject.

> I ended up rewriting almost 50% of my codebase half way through the project because of refactoring, or because of deleting features.

Nothing wrong with that. In fact, most projects will go through this and "live" for a long time as you clean up your style, understand the project as a whole better, etc.

Check out Clean Code - an excellent book on this topic.

Time and motivation. That's the essence of it.

Also you are going to need to study some 2D math (and 3D if you plan on making a 3D game). Trigonometry, vectors, etc. Those are bread and butter stuff when making games.

Before starting to write a single line of code read about game design. This is by far the most recommended book.

If you have any intention of selling your game you will also need professional art and sound. Don't underestimate this.

Finally marketing a game is as important as the game itself. There are cases when a game sells by itself, but it's so rare it's like winning the lottery. Don't count on that.

Oh, one last thing, don't start working on the first idea that comes to your mind unless it's for practice. Research the market before embarking on a year long project. There are hundreds of failed retro platformers, zelda like rpgs, etc.

Challenges for game designers is excellent. The real meat of the book is the set of excercises and projects, with a lot of excellent information and discussion to back it up.

Not directly related to game design, but these days nobody has an excuse not to have read the art of war. There are many free versions of it out there, including an audiobook. Check its wiki page!

You're very good at ASSERTING your point of view without backing anything you're saying up. Sadly, you'll have plenty of company in video games with a destructively ignorant point of view like yours. Eventually that will change as video games mature as a medium.

Your "guesses" as to my personal life are incorrect, irrelevant, and mean-spirited. Nice.

If you ever change your mind and decide to open up to the world of game design, I would recommend that you read "The Art of Game Design" by Jesse Schell for a really great introduction to the basics.

I am pretty similar to you in that I have a weak math foundation while being a computer scientist. For me it was just simply a lack of taking classes that I now feel I should have taken. Over the years since college I have been picking up random things as a pro and hobbyist. Here was something major I did to pick up 3D math quick (2-3 weeks):

3D Math Primer. I read through this, and implemented everything that I could in code. I created a Generic and highly param-based (i.e. n-dimensional) C# math library that has classes for Vector, Matrix, Complex Numbers, Quaternions, as well as a bunch of general math functions. (edit: Don't just read that book and expect to pull everything off, you should find yourself tearing through wikipedia entries for vector/matrix/etc and google results to get those classes packed full of cool methods, but that book was the root of everything relevant to my library).

I highly recommend this approach for programmers that feel they're lacking in math as it is fast, it works, and you end up with a math library that's probably better than anything readily available to you that you can use in your games.

I should also mention that the more you read in this field of CS (physics books for gamers, rendering books, etc), the more you'll get used to esoteric looking math equations.

Not specifically game-related, but the great classic Design Patterns: Elements of Reusable Object-Oriented Software is really well written, and it's patterns are as applicable to game design as they are for anything else.

You do say you're an experienced programmer though, so you may already know many of the basic general design patterns in there (or you may have read the book even).

You should read these two books, The Art of Game Design and Reality is Broken. They're both a pretty good window into what makes games fun in a psychological way.

Here are two websites if you need help job searching. Gamedevmap and orcahq.

The best thing you can do right now is build up a portfolio, go to game conference and network, and read game design books like the art of game design by Jesse Schell.

3D Math Primer for Graphics and Game Development is really good and covers everything I've ever needed it to. The examples are fun and easy to read/follow.

https://www.amazon.ca/Math-Primer-Graphics-Game-Development/dp/1568817231

Well, the OpenGL superbible is very OpenGL centric (hence the name), but it sounds like you perhaps need to understand some basics on the underlying math. The 3D Math Primer for Graphics and Game Development is a pretty easy to read book on math specifically for game development. Covers most of the stuff you'll need to know. There are other math books on that subject, but they tend to be a bit more difficult to digest, but that's just my opinion.

if your talking about game programming, i just got Killer Game Programming in Java from O'Reilly, it's a pretty good start.

However, if you're talking about game development, as in how to actually think of a game, i suggest The Art of Game Design by Jesse Schell. Very good book IMO.

For those that code in C++, I highly recommend the book "Effective C++".

There are a ton of good books out there that teach you how to write maintainable, well designed code, and I recommend doing some reading, especially if you're an indie developer or haven't taken upper level Computer Science courses.

Looks awesome!

This book is amazing. It goes through all the basics of the math you need.

This book Programming Game AI By Example comes highly recommended by me.

It contains all of the above along with an example 2D topdown style deathmatch game with bots to give you a clear understanding of the most common topics in Game AI. It's also one of the more practically focused books, rather than theory focused.

For basic Ludic principles, you will probably want to read Rules of Play at least.

Software isn't important (yet - you will be led to that by your programming), being able to draw isn't important though it can make things easier when you are on your own (you will need for sure to know how to use Photoshop or Gimp), actually making things and working out what is fun is important. For that, I'd recommend, while you are learning the basics of programming, making card games and board games. Then, once you have some programming basics, try and make a computer game - either an implementation of one of your physical games or to try making your own versions of classic games (lightbikes, pacman, breakout, rtype, pretty much every game made before 1985 that isn't Elite can be made by a beginner). You can also try focusing on making something classic but playing with one element of the gameplay and seeing where that takes you.

I don't want to spam since I posted a Reddit today on the topic, but our new tutorial was designed specifically for a noob. It's 3D, but the majority of info translates to 3D development.

http://www.garagegames.com/fps

If you want to be a designer, grab Jesse Schell's book ( http://www.amazon.com/Art-Game-Design-book-lenses/dp/0123694965/ref=sr_1_1?ie=UTF8&qid=1321479907&sr=8-1) and make a bunch of board games and play them with your friends. You'll learn how to design more quickly if you take the tech challenges out of the equation.

Blaaaaargh quit focusing ideas! Start writing code! Playtest!

/r/gamedev is a heuristic process. You can't just plan out everything and expect to make game from thinking alone. You have to code and then playtest.

https://www.youtube.com/watch?v=RYXInr3N5UQ&t=3s

This talk is "Going with the grain", comparing gamedev to cutting wood. It helps to go with the grain of what your medium (computer, input methods) are good at. Work with yourself.

Try treating your game as an intelligent artifact eg. https://www.amazon.com/Things-That-Make-Smart-Attributes/dp/0201626950/ . Let your programming be a dialogue with it and see what it wants to say.

If you're still having trouble and feeling stuck in "idea mode", put the programming aside and try "Challenges for Game Designers: non-digital exercises for video game designers" https://www.amazon.com/Challenges-Game-Designers-Brenda-Brathwaite/dp/158450580X/ making board games built around mechanics like "Exploration" or "Randomness" or "Deduction".

TL;DR Execution is everything so start writing code and play your game.

I usually tell people to check out these tutorials: https://www.youtube.com/fuseman. He's https://www.reddit.com/user/Fuseman/ on the Reddits. VR is a heck of a lot of fun to play around in. Get yourself a Vive and do every single one of those tutorials. By the time you're done, you'll have enough knowledge to make your own game.

The other piece of advice is to learn some math. This book has been particularly helpful to me.

The last couple of weeks in Zombox development:

(tl;dr: brand new zombie AI with lots of bells and whistles, tweaked ammo display and you can no longer hit things through walls)

• The zombie AI was completely re-written. After I was inspired by examples in the book Programming Game AI By Example, I decided to go with a behavioural hiearchy approach, rather than my old system which relied on a complex FSM in the form of a large if-then tree.
  
• In the old zombie AI system, zombies knew the player's position at all times, and their only goal was to find the player and attack him. In the new system, the zombies' behaviour is more realistic -- they have limited knowledge of their surroundings, and react to sensory input to gain new information. Zombies generally idle or wander, and will not attack the player unless they see him. If they hear a noise (like the player firing a gun, or hitting something with a blunt weapon), they will seek the source of the sound, and either continue wandering if they find nothing, or attack the source if they can see it and it's human. This sight/sound based system is nice because it allows you to do things like distract zombies with a sound while you escape in the opposite direction, or sneak up behind zombies to attack.
  
• Zombie flocking has been improved. Zombies will no longer randomly walk through walls, or walk through the player, or walk through each other. Also, when attacking they will aim to surround the target, rather than simply attack from one side.
  
• If a zombie finds that a door is in the way of its path (ie, if it chases a target into a building and the target closes the door, or it hears a sound inside a building), it will attempt to break the door down to get inside.
  
• In non-AI related news, the weapon ammo system has been improved to show the ammo counters for weapons in the active item slots up top, and when a weapon's ammo is depleted, the active item icon for that weapon will blink red.
  
• Props and zombies can no longer be hit through walls or other objects.
  
  Here are some screens showing the debug info I use to help me visualize the new AI system. White lines show new A* paths that are calculated. Green lines point to the next node on a zombie's path when the zombies is following a sound. Magenta/Cyan lines point to a zombie's active target (cyan = close, magenta = far). Red lines show the next node on a zombie's path when the zombie is chasing a target (although zombies are allowed to veer off their path when the target is directly in range). Yellow lines point to a new sound that a zombie has heard.
  
  
• One, Two, Three, Four, Five
  
  Animations:
  
  
• here's a gif showing some zombies chasing the player into a building, and attempting to break down the door to get inside.
  
• here's another gif showing that same thing happening, in a different scenario
  
• here's a gif (sped up 200%) showing some of the improved swarming
  
• here's a gif showing the active item icon ammo improvements
  
  As for New Year's resolutions...my short term goal is to implement Jump Point Search into my A* algorithm. My long term goals involve adding human NPCs, the underground subway system, the structure-building system, mini-quests, more zombie types including zombie animals, and releasing the game in May.
  
  More info: Devblog, Youtube, Twitter

Tynan Sylvester also wrote my favorite book on game design, which touches on emergence quite a bit. He has a simple, but good definition: "Emergence is when simple mechanics interact to create complex situations." Title is appropriate, Designing Games: A Guide to Engineering Experiences

https://www.amazon.com/Designing-Games-Guide-Engineering-Experiences/dp/1449337937/

I tend to agree with u/eepoo, mainly with the inexperience part. I don't think getting a team and making a game is as simple as a white bored sesh and trying to determine common traits of your fav games. Sound like a bucket of nightmare!

If you haven't already, check out The Art Of Game Design: A Book Of Lenses. Or even download the app of the same title, which is a little trimmed version with all the bullet points.

At least get your inexperienced guys to get the app for a crash course game design.


Url for the book, posting from phone and can't figure how to hyper link.

http://www.amazon.com/gp/aw/d/0123694965?pc_redir=1414060587&robot_redir=1

All that said, I am curious to know how the meeting does go? I may just eat my hat :-)

I recommend this book on AI highly to anyone who ever asks. The content is all relevant, the writing is easy to follow, and the code samples are explained and well written.

He touches on state machines, light gamey physics, fuzzy logic, graph searches (A* among others), and has two complete games included (a soccer game, and a top down shooter with bots) as examples. I've read it multiple times and pick something new out everytime.

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?

> To simply invert the direction of a vector it takes me hours to figure out which formula to use.

Do you mean like

v' = v*-1

A vector is simply a displacement of scalars. Can just use basic algebra on it.

I learned most of the math I use in games from: https://www.amazon.com/Primer-Graphics-Development-Wordware-Library/dp/1556229119
There are later editions that you can get for varying prices, but I'm not sure what that does to the price point. This book goes way more in depth than I needed to be able to use a game engine's math or be able to write my own simple vectors, matrices, quaternions, or simple physics stuff.

The really important thing is to get a strong understanding of how to use vectors and quaternions - and depending on the library/engine, matrices.

Read books, read through repos on github, and most importantly: write your own!

I recommend Game Engine Architecture if you want a very broad but extremely useful reference guide.

Practical D3D Rendering and Computation
Distills the API quite well and explains a lot of pitfalls with creating buffers and the pipeline usage. I'm working on just reading it so I'm familiar with D3D 11+ even though I don't use it day to day.

Real-time Rendering 3rd edition

Another fantastic reference for graphics with a more theoretical look at things, explains TONS of modern techniques and even older ones such as rasterization on CPU, etc.