Tuesday, August 19, 2014

Make games, by making them.

RULE 1: don't get hung up on doing it the right way:

Its massively more important to be able to see the game live (with a terrible codebase that needs to be rewritten) than it is that you don't have to re-write. This is because usually, the design changes enough that re-writing was inevitable anyway.

RULE 2: do not design the game based on what you can do technically.

Design the game, and demand things be tried out. Hack them in regardless of how "not quite how it should be done" it is. It's important to try out ideas before you invest too much time in them, and it's important to not avoid things because you see "doing it right" as being too difficult.

Following these rules, you quickly move from being someone who finishes well defined projects on time and on budget, to being a developer that can flesh out design ideas and mark them as "explored". That's the core difference of business and games. In games, the design document cannot be up front, and we use code to prove the design wrong, before moving on to the next iteration. We also never finish on time. (unless you are either a god of game development, or aren't actually doing something all that innovative)

Tuesday, March 11, 2014

Why engine programmers are the best.

I've been a game-play programmer, a tool-chain programmer, an engine programmer, and a network game programmer. I've used multiple languages during development of games, shipped products using three languages, and am still learning new ones now. I'd consider myself a rounded developer, but most of all, I still think of myself as a graphics and engine programmer that can do other stuff. The reason? It's what I feel I am best at. And another reason not to play it down could be that a lot of people think highly of engine programmers.

But why? Why are engine programmers the best?

In my opinion, the reason why people see engine programmers as the best could be down to results. Engine programmers - and graphics programmers - often get given impossible missions, then somehow manage to pull it off. They get asked to reduce resource usage, then get told the ratio, something like "Hey, you know we allocate about 1GB for resources, well, we want an iPhone version, and we need to get it down to 50MB", or "This game looks great on the XBox and the PS3, but can you make it look just as good on the Wii?" These are obviously things that are impossible. These are things that engine programmers normally see as challenges. Once the stage is set, these programmers will make strange movements, cut resources by half, or in four, will reorder the rendering, will adjust the way the system works to squeeze out the last bytes and cycles. Generally they are seen as gods and heroes because they don't just do the impossible, but they do it repeatedly.

Well deserving of their praise are the engine programmers, for they are the bringers of savings, the enablers of features, the gods of getting it done, and the princes of performance over politics.

But they have it easy. They have the benefit of a restricted set of inputs, outputs, and they are allowed to do things any way they like, as their how, their implementation, is not seen by the user. There are other branches of development that are much more scary; often those developers don't get the praise they deserve.

Game-play programmers have to work with a constantly evolving design. Game-play code often starts out very clean and the design of the game is often reflected in the code. As the design changes, those changes bend the code into the mess we learn to hate. This constant evolution can leave the code base in a bad state, building up technical debt, ultimately leading to a horrible mess of code that does what the game-play programmer expects, but only in the situations they had thought of. Bugs creep in everywhere, slow down the development of the game, and usually someone is blamed for bad coding practice when all they were doing really was just trying to keep up with the engine programmers.

Then there is the User interface programmer, who usually has to work with UI frameworks, because style must be consistent, even if the interaction with the framework is not. Linking callbacks to states, and states to visuals, and visuals to input possibilities. UI has to show state when it changes, such as toasts, health bars, dialogue, and modal dialogues. They are in charge of making sure you see the achievement or trophy, without distracting you from the game. They have to work with constantly moving data (the game's state is always in flux) and moving output format (usually a high level designer will make sweeping changes that affects how the data is transformed into the on screen representation, and then complain when told it will take more than one day to put in an extra column on a scoreboard). The UI programmer faces the same challenges as the game-play programmer, the same crazy design changes, but without the kudos of it being part of the game. Can you name one famous UI developer?

Then we get to the dirtiest of programming jobs: the network programmer. Like an engine programmer, they have to do the impossible. They have to link up multiple machines, keeping the latency down while managing to keep everything synchronised, working with the same or similar crazy race conditions you face in multi-threaded code. They have to change everyone else's code so it doesn't reference other entities by pointers, doesn't waste space or bandwidth, or take a too long a time to figure out what needs to be sent in the first place. These gods of high latency shared state are obviously doing something extremely complex, but you don't often see much being said about them. Maybe that's because they are too busy fixing bugs that you just introduced by changing something in the player state based on an unsynchronised global variable. Sure, maybe you can name one network game developer, but do they have any hair left?

Oh, I guess there is always the guy that does all of those things at once, but indie game developers get a lot of kudos. So at least there is that. Still, I think most people would like the easy life of doing the impossible, to a slow moving specification, with obvious visible results. Most people would probably like to be the engine or graphics programmer. Because they are the best.