Amit Patel's Red Blob Games and Game Programming Pages

[mouser]

DC member App103 found this fantastic collection of articles and links by Amit Patel on game Programming.

He discusses pathfinding, procedural world generation, AI coding, and a huge range of wonderful topics.  Very nicely organized and presented.

I’ve been helping people make games since 1990. I wrote games earlier in life, with Solar Realms Elite being the most well known, then worked on an environmental simulation game called BlobCity, then took a break for over a decade. The recent rise of indie, mobile, tablet, social, and web games have made me interested in game development again. My current passion is using interactivity on the web for learning, especially learning game algorithms. With modern web browsers, there’s no need for explanations to follow the formats used in magazines, technical papers, and books. We can combine learning by reading, learning by watching, and learning by doing.

http://www.redblobgames.com/

[TaoPhoenix]

There's a bit of a spinoff topic here:

"With modern web browsers, there’s no need for explanations to follow the formats used in magazines, technical papers, and books. We can combine learning by reading, learning by watching, and learning by doing."

I DO believe there's a need for "magazines, technical papers, and books".  I cut that quote pretty hard - I'm not sure if he's only talking about the "comp game" industry or going broader to "learning theory".

I'm moving into the topic that the types of info in a "manual" isn't the same info-theory-wise as all the stuff he was saying. We're skipping the DeadTreePaper vs PDF discussion here. Manuals are about telling you stuff like "Oh, yeah, right, this year you have to unclick the boxes 1,7 and 14 to get this year's return to file or it won't work at all, and if you miss boxes 13 and 14 it screws the client and you have no idea why at a ten second look".

So, we need manuals. Pop articles on the web don't cover that.

[TaoPhoenix]

Very briefly let's go into this snippet:

"In choosing a technique for AI in your games, keep it as simple as possible. If you know the answer, put the answer into the program. If you know how to compute the answer, put the algorithm for computing it into the program. "

In my view, if the "answer" is that easy, the game has failed. Simple example I'll mention is that Brokken on one of the old (SDK?) games for the (badly programmed) character Brokken was a quick "9-foot-stab" to victory, an AI would "report that". So we have some serious bad news "True Scotsman" problems with what we think "AI" is.

http://en.wikipedia.org/wiki/No_true_Scotsman
Remember, all this forgets the low level robotic crap. This is algorithms.

Being a McDonalds    3rd level worker ... isn't that hard.
Being a Duanereade  3rd level worker ... isn't that hard.

We keep trying to make "AI" some kind of moving target that takes higher and higher levels of various training or intelligence or both to meet. But just spend a day with a McDonalds worker. *Maybe* they'll miss a couple of beautiful intuitive optimizations to increase sales by $88 that day, but the basic job is a snap.

It's coming.

[Deozaan]

I've found Amit Patel's works many times over the years and referred to them when trying to learn more about game programming. Very useful resource!

[ewemoa]

Perhaps folks have seen it already, but came across "Pathfinding for Tower Defense" today.

Found the interactive maps to be of interest.

[mouser]

great find, thanks for sharing