Third-Party Water

Screen Shot 2017-02-16 at 13.23.14

Having more or less conquered Unity’s water (touch “wood” ha ha) I’ve moved on to populating the other building in v r 3 with “third party water” – that is, water I’m obtaining from Unity’s Asset Store. I’ve only installed four of them so far, but already there are interesting elements surfacing (ha ha?):

Broken water. Not unlike Unity’s water, I’m definitely running into problems with the third party water here and there, and it again reveals assumptions being made about the purpose/nature of water in videogames. One of the water’s I’m using comes with a prefab (readymade version) that is scaled to be enormous (100×100 units) which, when you place it in the world, makes it more like a reasonably large lake. Naturally that’s not the size I want in my game – I want a 0.1×0.1 scaled bit of water (1000 times smaller!). But when I scaled the water down to my size, it turns out to “break” it in the sense that all the default parameters are tuned to the water being large. It’s thus been an ongoing battle to work out how to tune the parameters to allow for the concept of a small amount of water. This water “wants” to be a lake, and I want it to be a puddle.

The people’s water. Now that I have water from multiple creators (Unity, plus each of the creators of the third-party water), you really start to get this sense I’d wanted of comparing water to water, and notably thinking of the water as something created by different people. Recontextualised as something to look at, and labelled with the creator’s name (like CruduxCruo above), the person behind the water comes more into focus and the water becomes, even more, something constructed.

Purposeful water. While the main Unity water is clearly trying more or less to look like “real water” of different qualities, it’s already the case that the third-party waters demonstrate different ideas about what water is for in a videogame environment. Notably, I have some cartoon-style water alongside some realistic water alongside some water that defaults to looking like surf rushing across sand. So we have not just the aesthetics of parameters tweaks to realism (in the Unity building), but also larger questions of how to represent water graphically.

The price of water. Most of the water on the Unity Asset Store costs money. Naturally this leads to questions of whether the water you’re looking at in the game was worth the cost (I’ve added the cost to each of the didacts). This naturally interacts with the purpose idea above. Your initial reaction might be that more expensive water should look more realistic, perhaps, but there might be other considerations that will come up through the exhibition. (There are also hidden considerations like how “easy to use” the water is, how many parameters it offers, etc.) This is also shown in a really nice way because the one free water I’m displaying also has a paid version, so there’s a direct comparison there of what added value you get when you use the paid version.

There’s bound to be more as I proceed, but it’s kind of amazing to me just how generative this stuff is in terms of really thinking about how videogames are constructed, how game engines work, and so on. I’m quite pleased with it.


Open Source, Open Process, Open Heart

Screen Shot 2017-01-20 at 10.36.47

As I mentioned a couple of weeks back, I’ve been using GitHub for my latest projects. I learned the basics of version control (on bitbucket.com and SourceTree) from my colleague Jonathan Lessard when we worked on Game Studies, but now I’m toddling around with it all on my own like a grown-up.

Other than the obvious advantages of version control like not being totally screwed when you misedit or delete or otherwise mess up a file, I’m finding using GitHub quite inspiring in terms of finally being able to live my (not very ambitious or striven-for) dream of open sourcing my work. Notably:

1/ The most obvious thing is that I can easily make my code available to anyone (read: no one) who wants access to it. It just exists as a repository, organised in the same way it is on my computer, with its various assets etc. There were times when I didn’t feel comfortable with this because I’m not really the world’s most beautiful or competent programmer and I was reluctant to let people see the ugliness that lies within. However, since I’ve been working in JavaScript for a while now, it’s not really possible to hide from anyone anyway, and if I’m not going to hide, I may as well dance around in public. This goes, too, for the idea that people will be able to “hack” or “cheat” my games because they can read access the code easily. And anyway, frankly I would love for people to do that more often.

2/ The less obvious thing that only occurred to me as I was working on SNAKISMS is that I can also open source my process documentation with minimal effort. To date I’ve been writing my process notes on games in Evernote, which I kind of hate but can’t seem to jettison from my life (I used to have this same relationship with DEVONthink). For SNAKISMS I’ve been writing all my process stuff in a couple of text files in Markdown, which allows me to get a decent amount of formatting in plain text (notably I still have access to my one true love, the strike-through – the tildes in the screenshot at the top of this post). This means I can save my process stuff for posterity really easily (can’t imagine anyone else reading it necessarily, but it’s a key part of the overall game-thing so it makes sense for it to be open source as well). Also, because Git tracks changes, it’s even possible to leaf through the history of the process as well, seeing when different to-dos or ideas entered the fray etc.

3/ Along with the text of the process, it’s now very easy to include process images along the way because I just throw screenshots into my process directory and they sync with the rest of the repository like magic. This is true also of any photos I take of my notebook doodlings (though I haven’t doodled anything for SNAKISMS weirdly, it’s been all digital). So the whole process shebang is just taken care of.

4/ Finally, because GitHub kindly includes a hosting service called GitHub Pages, I can actually just host the game on GitHub too, with the game loading directly from the files in the repository itself. This just removes some of the endless fiddling with constantly uploading and re-uploading files as I’m trying to release a game and screwing up and doing bug fixes and so on. Now I just need to make changes to my game locally and then sync it and the released version will be updated at the same time. It really is a bit like magic (to me).

So that’s my (looking at it, kind of nerdy) account of feeling good about using GitHub as a platform for game development (at least in HTML/JavaScript style development). It takes care of a bunch of niggles, consolidates my process, and allows me to share my process and code with anyone who particularly wants to peer at what I’m doing. Radical transparency/honesty etc.

Clear eyes, full hearts, can’t lose.


How Monist is Monist Enough?

Screen Shot 2017-01-11 at 15.05.28

Have been getting to work on SNAKISMS over the last couple of days which has been fun. All the base code for the underlying Snake game is in there (including touch controls and a mobile-friendly aspect ratio) and so it’s time to do the good old object-oriented programming thing of extending the Snake class to create the variations. I’ve started with Monism. For the sake of implementation I’m going with what seems to be called “substance monism”:

Substance monism is the philosophical view that a variety of existing things can be explained in terms of a single reality or substance

To that end, I’m interpreting this as many that all elements of the game are “made of the same stuff”, and in this case I’m saying that “stuff” is the apple that the snake eats. Thus, this Monist version of Snake treats all visible elements on the screen as being apples. So you can eat the walls, the score, the instructions, your own body and get points for that.

But after implementing that version and being quite pleased with myself (it’s weirdly satisfying to eat the walls that normally kill you), I realised that I hadn’t actually captured the apple’s behaviour with the other elements. Notably, when you ate them they were just gone, but in Snake, or at least the way I’m thinking about it, the apple “comes back”, or at the very least a new apple appears when you eat an apple. So I had to go back through with quite a bit more effort to make it so anything you eat reappears in a random location on the screen (like the apple) to be potentially eaten again.

The most entertaining aspect of this is that if you eat the score, it still “works”, but ends up with its different digits distributed around the screen, ticking over, but kind of unintelligible.

Anyway, this requirement of the second step of making elements reappear is a classic example of how you really do end up having rethink things as you implement them. It was only while thinking about the code itself and playing with the initial Monist version that I realised that the behaviour of the other elements wasn’t the same as the apple. Truth in programming.

One down, nineteen to go.


Teacher Teach Thyself

Work

It’s a well-worn idea, but teaching sure does provide a bunch of opportunities for learning. Over the last semester and preparing for this one there have been at least three fairly major approaches to making my own work that were heavily influenced by my teaching:

Twine. I had the students in my game design studio use Twine as their first game making tool to explore how they could work with (or against) it to recreate ancient Greek myths. While the students, disappointingly, pretty much universally hated Twine, their hatred pushed me to work with it myself to see if I could figure out why or, more important, how I could use Twine in a way I found interesting. That led to making Burnt Matches – which was in part a game about responding to a game jam we did around the documentary Into Eternity, but was also hugely about learning about how to incorporate JavaScript and Twine macros into my understanding of how to make games in that environment. It led to interesting work, I think, and I even incorporated some ideas I saw in student projects into the final product. If I hadn’t been teaching Twine (and reacting to my students’ reactions to it), I don’t think I would have pushed myself so hard to figure out an interesting angle on it.

jQuery UI. I teach web programming courses in my department as well as game design, and one of the tools that comes up a lot is jQuery. I’ve always been fascinated by jQuery UI, mostly because of it’s .draggable() function that allows you to make pretty much any element on a web page draggable with the mouse. Because I’ve spent a fair bit of time looking at that library, I realised comparatively recently that the project about user interfaces (currently called It is as if you were doing work) could actually be made in jQuery UI. There’s a nice feeling of appropriateness to use an actual library for generating productivity oriented interfaces (with sliders, buttons, dialogs, etc.) to make a game. In the past I’ve always specifically used game making environments or libraries to make my work (understandably), so there’s definitely something fun about using a different set of tools, and tools that are appropriate to the subject matter of the game, to make this one. Naturally, had I not already been using jQuery UI I presumably wouldn’t have used it for this project. (Although I have to say it’s been a huge pain in the ass getting the widgets to play nice so far.)

GitHub. One realisation I’ve come to with our students over the last while is that they really should know a version control system like Git in order to manage their structuring of work, their backing up, and their collaboration. At present we don’t teach this in any of our classes, so I’m moving toward teaching Git/GitHub/GitHub Desktop. Prior to deciding this I haven’t really used version control outside of in my undergraduate Computer Science degree and when collaborating more recently with Jonathan Lessard on Game Studies. So I’ve been learning Git for the last while to teach it and, unsurprisingly, I’ve been using it for my current projects. It’s been helpful (and makes me feel like a “real programmer”), but one particularly nice outcome is that it will allow me to trivially open source my games on release, which is something I’ve been meaning to do, but just uploading a .zip of the project feels so crass. Along with that, it should make including process materials with projects much easier too, as I can just have a folder of process material/documentation in the repository and have that be part of the release as well. Perfect.

So that’s probably more than you needed to know about some technical minutiae of work I’ve been doing lately, but I do think it’s nice that you this out of teaching along with the other obvious “good stuff” like getting to see students improve, seeing impressive projects grow, and so on.

Done.


Stated! Goals! 2016!

It has become a tradition at the end of the year to write down the basic goals of the games I made in the year as a way of thinking about what kinds of ideas I was after. (See also: 2012, 2014, 2015.) So with absolutely no ado at all:

Play VVVVVV/How Do You Do It?/Desert Golfing/The Artist Is Present/The Graveyard as Breakout

Write a novel

Do the Abramovic Method after an apocalypse

Contemplate a room in different spatial configurations

Contemplate objects you can’t see because they’re inside generic cubes

Push a rock up a hill/Eat an apple and drink water/Break free of your chains/Fill a bathtub and have a bath/Run a footrace

Experience classic game studies concepts through slapstick

Contemplate a complete, disastrous playing of The Oregon Trail

Pretend to play chess

Explore an abandoned nuclear facility (made of text)

What can I say about these goals? Like I said last year, I think they’re at least somewhat diverse in terms of things you might do inside a videogame? Writing a novel, having a bath, and pretending to play chess are all relatively different kinds of activities… I think I’d be prepared to argue for that.

Although my games are always pretty “meta“, this group seems perhaps more meta than usual. From games remediated into a different game in BREAKSOUT, to another game (about a method) reset post-apocalypse, to another game reframed so that you can win (instead of be eternally punished), to a game where you pretend to play a game. And, for that matter, a game about the academic study of games… so this is definitely some one-eyebrow-up and a faint smile (or is it a frown?!) stuff. Does that mean it was also a more inaccessible year? Couldn’t tell you, but I wonder if it was. If it was… sorry?

The role of violence in game generally is something I care about, so I’m also prone to wondering/worrying about violence in my own work. The 2016 games involve pretty much no explicit violence – certainly not violence enacted by the player explicitly. There’s some violence to be suffered (the eagle eating your liver if you don’t break your chains, an oversize tennis ball hitting you in the face, an irradiated final moment) and there’s some violence that’s implied (post-apocalyptic landscapes had to come from somewhere, the Oregon Trail is a nasty place). So ultimately I like that the player isn’t violent, and that the violence in the games is usually minimal or has a point/role to play in the overall idea (beyond just being part of a “core game loop”, say).

Apparently I think the games are contemplative given that I wrote that word three times in my descriptors. It’s true that a significant number of the games in 2016 involved little player activity in the sense of doing things to the world and more encountering a world and thinking about what it is the way it is, or trying to look at it from different angles. To go with that perhaps I’d say that a lot of the games were spatial in nature, not least of all because it was a year where I was trying to more seriously pick up Unity as a tool of my trade. Thus a number of games were environments to be looked at (often with some extra philosophical element added for, well, contemplation). Even Burnt Matches was heavily spatial in nature, despite being made in Twine.

Four of the games had pretty solid art world references involved in them, or more often integral to their very being. This of course includes references to Marina Abramovic’s work, but also to the work of Gregor Schneider and Donald Judd.

There you go, kid. Make of it what you will.