From a comment on Cliffski's blog:

The blog post was talking about overcomplication in games like Hearts of Iron, games which push micromanagement to a level that is totally ludicrous.

There are a lot of guys out there who WANT to have to micromanage things like tank repair down to the rivet.
They’re called grognards. There are fewer and fewer of them every year, I think, because tabletop wargaming of the old rivetcounting style is a dying hobby. But they’re out there. I’ve seen them.
There is a reason the HOI guys make HOI. They wouldn’t do it if they didn’t like it themselves. They wouldn’t do it if people didn’t buy it.
The popcap market is huge but unbelievably saturated. The rivetcounting market is a small niche market but is underserved. People in that market buy every title that comes out, and will pay $30 or so for them.
The FPS analogy is ARMA II vs COD. COD games will always serve a larger market, but that means that the market is dominated by big fish. Milsim games don’t appeal to so many people but the competition is much lower.

In my opinion, games need to be deep at the same time that they're accessible.  But there are people who enjoy the crazy complexity of HOI.  They were the people who played the TOTALLY ABSURD tabletop WWII wargames that required two teams of twelve players and took 1200 hours to complete.  That sort of person.

They are out there.

Quick and Dirty Collision Detection

Just a quick note regarding collision detection.

In bullet hell shooters, or any sort of plausible physics-based game, you're going to be doing collision detection.  The naive way of doing this is doing circle-circle (or sphere-sphere) distance detection for each object onscreen colliding with each other object.

This works fine for small numbers of objects.  Where you are going to start running into performance problems with this sort of game is going to be in collision detection, if you want all objects to be collidable with all other objects. 

So for 1000 objects onscreen, you'd be looking at ~1 million collision calculations per tick. In my experience, "naive" collision detection starts running into problems at around 300 objects.

The reason for this is because collisions are exponential.  For each new object, it has to be collided with all other objects in the system. 

So then you get into different sorts of ways to whittle down the collision number, including "binning" or dividing the screen up into N squares, ideally somewhat larger than the individual object's collision box. However, even if you just divide it up into quadrants, that will usually work just fine for any type of sane collision algorithm. There are edge conditions on the borders of the boxes but they are just not noticeable.

Here's a really simple way of binning. Give each object a quadrant, zero through three. When the object moves, its screen quadrant gets updated. On collision check, check first if the two objects' screen quadrants are the same. If not, don't bother doing the collision check. In one way, this seems inefficient because you're only cutting the problem up in four. If you use more bins, you will be able to push more collisions, but then the binning code gets a fair bit more complicated. The advantage the quadrants have is that you have fine-grained collisions the vast majority of the time.

There is going to be a point where this no longer matters, when we can collide eg. 1680x1024 pixels against each other in real time, using the naive approach.  That seems impossible-- a million squared distance calculations-- but it's not a moving target so eventually the doubling rate of computer speed will surpass it.  If we ever get there.


Obviously, in the shot from Geometry Wars below, they're not colliding the particles (sparks) with anything.  But they could.  If they were doing a naive collision, action like this would be unplayably slow.  But with binning, you could actually do that sort of collision if you wanted to.  Modern computers have huge power, but exponential growth will always bring them to their knees at some point.

Game Development Has its Own Rules

A piece of advice: game development isn't necessarily like other forms of programming. It's sort of a beast unto itself, and since it's for entertainment, it doesn't need to impress Stanford University computer science professors with its elegance. If you can't think of an elegant way to do something, just do it brute force. If it causes speed problems, worry about it later.

An example would be having a different set of lists for each object type, and then a different list altogether for particles, instead of having them all thrown into one big list. It might not seem like the most elegant way of doing things but it might simplify things for one reason or another, and it will get the job done and you will be able to ship the product.