Developing in 'Public'

Part of working on Sibilant Snakelikes is that I’m working on it out of a public GitHub repository this time around. You can find that repository here if you want in on the magic: https://github.com/pippinbarr/sibilant-snakelikes. Even looking at the repo now I can see it’s kind of user-unfriendly in terms of actually explaining itself as a work-in-progress in terms of the non-existent README information. I should correct that.

Anyway, the repository is in public, so anyone can mosey in and see what I’m working on. A big part of the reason for that is that I’m working with colleagues (Rilla and Jonathan) on a larger project around how to more rigorously/carefully document the game concepting/design/development process for later recovery and analysis and the like. We’ve focused on the idea of using Git as a means to do that, and the process has its jumping-off point to some extent in the kind of work I did on games like SNAKISMS and It is as if you were doing work which have quite intensive documentation as part of the repositories.

But I guess the repository being in public is kind of meaningless to the extent I don’t tell anyone I’m doing it in public, so now I suppose I’m telling you about it. If you wanted to, therefore, you could get the agonising, blow-by-blow experience of me working on a new game, figuring out what it means, writing a design journal, writing code, writing bad code, more bad code, then some code that works, musing on design decisions in the commit messages of my code, and on and on. It is, for better or worse, very detailed. For example here is a recent commit message:

Added nicer implementation of generating tile, had realisation about the “apple” tile from last commit

Just reworked the code for generating tiles to be a bit cleaner.

? Just as I was about to change the neutral tile sprite to “apple” I realised that it doesn’t make sense for them all to resemble an apple because that would mean that bombs were hidden “under” apples, which isn’t fair and doesn’t make sense. Minesweeper doesn’t imply that the tiles are safe or not (they’re just neutral). If you put them down as apples you’re implying they’re “good to eat”. This then resolves my design issue around the snake getting longer: there are no apples so the snake will never get longer. The remediation here is that we have a traditional Minesweeper board with a Snake doing the selection of tiles rather than a mouse. It’s possible obviously that this will make it impossible to play, but whose fault is that? Surely not mine.

That’s what this process looks like moment to moment. Because it’s me, there’s a lot of philosophical worrying with the concepts the game is using. It feels like it’s operating on three levels in fact: the moment-to-moment implementation of features, the meaning of those feature in the context of “translation” or “remediation” as the core value of the project, and then the methodological concerns being explored through the project as well.

So I don’t know, I’m just saying this is what I’m doing. I wouldn’t classify it as “performative” at this stage, because I’m kind doing a “code and write a design journal like nobody’s watching” affair, rather than solliciting a more publicly interactive style. But maybe in a project down the line it would be worth pursuing the possible experience of developing more along a highly public/performative structure? I. don’t. know.

Follow the repo if you want. If you don’t, it’s okay, I’m not watching.

1 November 2017
← next words previous words →