Monthly Archive for July, 2010

Programs, Ideas, Decisions

Published on July 27, 2010 in opinionated rants and programming. Closed

If the ideas expressed here abuse otherwise well understood terms in vague and inconsistent ways or are just flat out wrong, please feel free to copy and paste this post into your word processor and change it to be more agreeable to you.

Actually that sounds too harsh like I don’t care what you think, which is not strictly true. What I mean is there are plenty of holes and vagaries here to warrant correction or disagreement and you shouldn’t let my wrongness get to you.

Programs are ideas not code.

Programming is arranging systems to express ideas. The quality of the result is determined by the clarity and understanding of the ideas that inform those decisions.

Sometimes a distinction is made between systems and application programming. The idea is that systems programming produces programs for use by programmers or other programs (such as operating systems, libraries and tools) and that applications are produced for users. I think this is a false distinction. All programs appear as abstract systems to their users, application is the act of using those systems. The work of a programmer is to take a set of more abstract systems, shaping and hiding the possibilities inherent in the base systems to produce a simpler, more concrete system closer to the users need.

Application of systems producing more systems. Its turtles all the way down.

Programming is irreducible, there is no silver bullet or tool that can remove the programming from programming. Good tools, libraries and languages only help to clarify the task of programming and remove obscurities. They may reduce the lines of code you write but do not reduce the act of programming.

Libraries and components that are completely configurable do not contribute to your program. Their use and configuration is an equivalent act of programming to working without them. Complete and perfect abstractions belong to mathematics, not programming.

Code can be a liability that stands in the way of our ideas as much as it is the only way to give them shape and life.

Programmers, Hubris, Technology, Game Design

Published on July 22, 2010 in games, opinionated rants and programming. 2 Comments

(in which I argue for and against hubris and a focus on technical nonsense in game design)

Programmers are famously victims of hubris, arrogance and pride. Many of the symptoms are common enough as to be well worn cliches amongst programmers such as the infamous NIH (not invented here) syndrome, that drives programmers to re-create all manner of wheels ad-nauseam under the delusion that their wheel will be better than the many others available.

So naturally when I first got an ipod touch and began working with the SDK I immediately started implementing my own sprite library for 2D graphics on top of OpenGL. It was not better or faster than any number of other 2D graphics libraries implemented on top of OpenGL. Well, it did do batched draw calls, interleaved vertex data and was essentially fill-rate limited, but um, I digress.

These foibles, as well as a natural tendency to get completely sidetracked on minor technical details, are supposedly the enemies of game design. We are supposed to not be limited by technical aspects, instead thinking of interaction models, themes, and gasp, maybe even fun (don’t worry, that last one’s obviously a joke).

Historically though, games have always been closely tied to their technology. The first computer game designers were by necessity programmers (they generally did the graphics too). Simply getting primitive computers to create something compelling as a game required someone who could draw a bit of magic directly out of the machine. As machines got more powerful there was so much new ground to cover, scrolling, animation, 3D and advanced rendering techniques as each game strove to be better than the last, constant technical innovation was an integral part of each new game.

Now is really the first time in history where game design can be untangled from technology. Artists can create games using technology like flash, allowing easy development and deployment. Modern consoles are powerful enough to allow middle-ware to be used as the basis of cross-platform games, avoiding deep technical integration with the computer all-together. Large games are built by teams in the hundreds, most producing art, scripts, level design, interaction design all separate from a small engine team who deal exclusively with the technical details.

But I’m not quite convinced.

I still have the nagging feeling that the best games are built closely intertwined with their tech. I don’t know if I can quite put my finger on why but I think it may be something like this. No matter what game you’re playing the machine never completely disappears (essentially a manifestation of the law of leaky abstractions). Since you can’t pretend the machine is not there, acknowledge it, embrace it. Let its limitations and details shape the game as it has for so many before. Not to suggest that any game must be a technical tour-de-force, coded in raw binary etched by hand directly on the metal. Rather that you should allow an understanding of the technology to permeate and flavour the game, because it will, whether you intend it to or not.

Or perhaps am I simply just an incurable programmer and a victim of hubris?