dtgreene: I've done that, albeit a long time ago; the game was in BASIC, which does not have pointers (unless you count PEEK and POKE, but those weren't practical for accessing structured data).
A better comparison might be to compare it to dynamic memory allocation, which uses pointers and has its share of bug classes (use after free, double free, memory leaks, etc.). Some games need it (Civilization and Morrowind come to mind), while others could easily do without (something like Shovel Knight could probably be implemented without it, for example).
ColJohnMatrix: I was talking about games intended to be sold commercially, not merely some text game or some introductory programming you did. I think you have some misguided ideas about pointers.
The example holds because even without dynamic memory allocation, you still access pointers, EG - in the screen buffer in DOS for mode 13h at 0xA0000000. You'll need to access that in some fashion via pointers to do anything with it. Dynamic memory is merely another level of it.
In my experience, most of those bug classes, while it's true they exist, shouldn't be the issues they're made out to be with a healthy dose of defensive programming. I don't think Shovel Knight could be implemented without them, unless you're going to make a horrendous design having everything static and doing all manner of things you simply should just not do. It's not a portion of the language you can just decide to selectively not use. It's a specific tool that really needs to be employed on the sorts of problems that come up commonly in games and system software. You'd have to go to a language blatently without them to avoid them in the sphere of game programming.
BASIC abstracts all this away; to write to the screen, you use commands dedicated for that purpose, and the interpreter does checking to make sure you don't overstep the screen bounds.
Also, Akalabeth and the original version of Ultima 1 were originally written in BASIC.
The thing is, in a game like Shovel Knight, about the only thing I could think of that might need dynamic allocation is sprites (including things like enemies and bullets); if you limit the number of sprites on screen at once, you only need to allocate a fixed amount of menory to store them. (With that said, it *is* possible to get bugs as a result of the allocation of such sprite slots; Super Mario World has bugs of this type, like one that make it possible to eat a Chuck, causing strange things, including arbitrary code execution, to happen.)
Remember that old consoles have very limited amounts of RAM; the NES has only 2 kilobytes of ram, and the Atai 2600, only 128 *bytes*. When you have so little RAM, you can't just allocate as much memory as you need; you need to be careful about memory usage. Garbage collection is also not particularly feasible at this point, either. Also, remember that you don't have a BIOS or C library (so you don't have anything like malloc() unless you implement it yourself).
Early video game consoles are, in effect, embedded systems.