Copycattery

It's a great way to learn.

I have on many occasions advised people to copy existing games, so they can learn various mechanics. You should build Tetris, so you know how to make a game in general -- it's a pretty basic game, most of the hard part is all the ancillary stuff like scoring and options and menus and whatnot. Then you should build Space Invaders, so you have to track shots and whether they hit something, along with the deteriorating barrier blocks. Then you should build Breakout, which has some basic physics, and then Asteroids which has slightly more complex physics and movement that wraps around the sides of the screen.

I've done all those, but I have never built Pac-Man... which introduces enemy AI to the mix... or Super Mario Bros, which introduces scrolling levels and platforming. I'd recommend building those to anyone making games. But I, myself, have not done them. This is mostly because I am not interested in making these particular kinds of games, but also because I have learned the elements of those games outside of their context -- I have put enemy AI in several games, and I have built multiple scrolling platformer levels just as a test to see if I had a good idea for a platformer.

Invariably, I have not, and my platformer idea is stupid and boring. I chalk this up to not really liking or caring about platformers. It's hard to come up with a good idea for a kind of game you don't like. It seems like you could do it, because you go "I would like this game if..." but then you run into the reality that as a player you do not actually know what you would like.

You'd think that being a game designer and developer would make you better at this, but it actually just makes you better at saying "no, I'm almost certainly wrong" without making you any better at knowing what would be right. The big takeaway for me has been "stop trying to make games you don't like into games you do." It's way faster and easier to just play (or make) a different game.

Which leaves me, as a designer and developer, leaning into the idea of making variations on games I already love by tweaking and torquing different systems. I love horde survival roguelites. Always have. Even back in the days of Berzerk, which wasn't much of a horde, and then Robotron 2084 which absolutely was.

So making a horde survival roguelite is just tacking the "roguelite" part onto a game i already liked all the way in the beginning. 

The thing is, once you've made a few complete games, you stop needing to copy entire games. You start copying systems and elements and ideas. The horde survival genre is composed entirely of a player avatar that can move and fight, and an ongoing supply of enemies that can move and fight, and those are actually the same thing: it's just that one of them hooks up "move and fight" to player controls, and the other one hooks them to an automated process. 

So you don't need to build a whole bunch of stuff. You just build "move and fight" and hook it up to some animated sprites. And if you do it properly, the next time you need "move and fight," you just grab it out of a previous game and you're done. As you build more and more games with more and more systems, making a new game becomes less about implementing from scratch and more about snapping the systems together like Lego bricks. 

So I'm primarily interested in building more reusable systems, so I can have a sort of personal framework for making lots of games, rather than just a little collection of games that aren't modular enough to pull apart and rearrange. And I find these by poking around inside other people's games. That, I think to myself, is a mechanic I could pull out and add into something of my own in the future. 

The goal, in the end, is to be able to prototype new games VERY QUICKLY. So I can test more games and try more games and ultimately release more games.