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.
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:
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).
Clear eyes, full hearts, can’t lose.
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.
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:
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.