Indie game developement and polishing

Video games are among the most complex softwares to design and implement. They deal with graphics, database, UI and so on. Yet programming them is very accessible: there are books, forums and frameworks for game programming in nearly any language. All recommend using rapid prototyping, and player-centric game design requires a design -> code -> test -> redesign loop as short as possible. After a few iterations in the loop, game development can get very messy if the code has not been organized into components. Software components are embodiments of the software engineering principles of encapsulation, abstraction and modularity (Taylor et al. p69). In other words, building a game from early prototype to end-product requires modularity (and therefore components). More generally, modularity is the key to adding and editing features in rapid prototyping and agile software development processes.

But looking at game repositories such as pygame, it seems the myriad of small projects it contains seem to pay no attention at all to modularity. I think they may have started all right, but as development progressed, the code got tangled without them noticing it. Locating themselves in the development process became more and more difficult. In the end, their project does not have any distinct component, they have three 500-line files named "main", "game" and "classes". Each of these files contains more or less the whole game and does not have any comment. The game is certainly working, but it is ugly and buggy and does not give a good experience to the player.

Braid is the opposite. It has been polished to provide a unique experience to the player. Images taken from the Gamasutra article about The Art Of Braid: Creating A Visual Identity For An Unusual Game.

Reknown game developers such as Chris Hecker ranted about unfinished games. Hecker gave the example of games (or rather game design proofs-of-concept?) developed in less than 20 hours. Cactus, the main indie developer targeted by Hecker, explained that his mentality was to make games available for others to be inspired by. Other indie developers of growing fame such as Mathew Galant disagreed cautiously: nobody can create a masterpiece without first making a hundred crude sketches, and It's better to get those ideas out there, even if they're flawed and incomplete!

I think there are very distinct categories of indie game developers: veterans, explorers and beginners. For veterans such as Hecker, agile processes promote sustainable development (taken from the Agile Manifesto). For explorers such as Cactus, agile is actually cowboy coding (not in a derogatory sense). For beginners, agile is a way to learn. Voluntarily or not, explorers and beginners do not pay attention to modularity. In my opinion, this is what sets apart veteran masterpieces from beginner and explorer trials.