Spomenik-1 is the first game I’ve actually produced for public consumption, and perhaps more significantly, the first game I’ve made with the intent of it being a complete, packaged product. In the course of making it I learned a lot of things I found useful and interesting, so I wanted to write a bit about the process. Some of this is technical, but most of it is more related to the process of game development in general. Feel free to skip ahead if there’s a section you don’t care about.
So let’s get the technical stuff out of the way first:
Image effects
One of the major things I wanted to play with was the new image effects scripts now part of Unity 5’s Standard Assets package. I knew I wanted a particular exaggerated photographic look, to emulate Kempanaers’ Spomenik photos, but I really didn’t know what I was doing with the image effects. I messed around, just changing things and seeing what I liked, but none of it did exactly what I wanted. I got something that was pretty close to what I wanted, but not quite, and every tweak seemed to take me further from the goal.
Eventually I looked up a guide to get basic image effects working, and tweaked from there. What I ended up with was a very dialed-back version of the image effects I’d had previously. I’m not sure if I should have gone with the original effects, to maintain a distinctive look, even at the cost of not getting the perfect effects. I need to look more into how these things actually work, so I can do better at working out what I actually want.
Prefabs
Because I was using two different scenes for the menu screen and the main game, I quickly found that prefabs were going to be a necessity, for both the camera (with its image effects) and the model of the monument itself. I actually haven’t used prefabs very much in Unity before, because I’ve mostly worked on small, single-scene projects with no repeated assets. This is obviously a feature of Unity most users probably use extensively, and after using prefabs I can see why.
The more interesting discovery was that Unity always treats terrains as prefabs, which saved me a lot of hassle in this case, but is something I’ll need to be aware of when using terrains in future. I usually won’t want to end up editing a terrain in one scene only to find changes propagated throughout all instances of that terrain, even though in this case that was exactly what I wanted.
UI and UX
The only significant amounts of code that I wrote myself in Spomenik-1 are those behind the UI and UX features, to drive menus and load scenes. And the part of that that was the most trouble was implementing a feature one of my pre-release players asked for: the ability to invert vertical mouselook. Actually, implementing inverted mouselook was easy. The hard part was making sure that Unity could retain user preferences between the Menu scene and the main game scene, and that the UI would reflect the user’s selections in all cases.
But once I had this working for mouselook inversion, it was easy enough for me to set it up to provide a crosshair with adjustable opacity, something I’ve seen other first-person games provide to help some users affected by motion sickness. This is the first time I’ve used Unity’s UserPrefs, or any kind of configurable options, and while reading and writing to UserPrefs was easy enough, I ran into some hiccups with the logic behind keep the UI up-to-date with these. In future I probably need to actually chart out the logic before I start implementing it.
Building and testing on multiple platforms
I wanted to make both Windows and Mac OS X builds, because I know that a lot of the people who are interested in smaller, experimental games only have Macs, usually a laptop. Unfortunately, I haven’t had a Mac of my own since my MacBook Air died in early 2015. This meant I could build for OS X, using the Windows version of Unity, but I couldn’t test it.
Iain McManus let me know pretty quickly that the OS X version wouldn’t run, and I eventually worked out that it needed its file permissions changed in order to be executed. I couldn’t work out how to do this from Windows, and fortunately Iain helped me out by running the necessary chmod command, and sending the build back to me. In future I might have to have a Linux environment on-hand to do this myself, but the only thing that’ll solve the testing problem is getting a Mac myself, something I’d like to do but don’t have the money for at the moment.
This would be especially helpful for solving the other issue I discovered, which was that OS X and Windows treat custom cursors very differently, so the cursor in the OS X version wound up looking huge. I’m pretty sure all I need to do is change the maximum size of the cursor image in its import settings, but then I’ll have to do a new OS X build and deal with the permissions issue again. That should happen in a new OS X build in the next day or two.
Making an art game = no (conventional) playtesting
Generally I want to playtest anything I make extensively, as early as possible. But I decided against that for Spomenik-1. Playtesting is about identifying problems, whether they’re utility, usability or user experience problems. For Spomenik-1 utility and usability were secondary concerns to the user experience, and even that was secondary to the idea of me expressing an idea in a particular way. I had to think a lot about this, about whether I should playtest something that was essentially just an artistic, personal expression of an idea. I wasn’t worried about it not working, because it’s built out of proven parts, in the same way I wouldn’t be worried about paint not sticking to a canvas. And because it was about expressing an idea, in a fairly simple way, I didn’t think I’d get much out of a general playtest as far as user experience.
What I did instead was simply distribute it to a small number of people, and get feedback on it, much like I might do with a short story I’d written. They gave me great notes, and I changed Spomenik-1 a lot in response to their feedback. For example, I changed the footstep and wind sounds and reduced the distinctiveness of the background scenery, to intrude less on the core experience. These more editorial notes were much more useful to me than I think a more general playtest would have been, and I’m very happy with the outcome.
Packaging and distributing
I already knew I needed a cover image for itch.io, and a number of screenshots. But Robert Yang gave me a note saying I should add a custom config dialog banner, and that sent me down the path of making my game look more of its own thing in other ways, i.e. by using custom icons. Each of these things, cover image, screenshots, config banner and icons, required images at different sizes. I started with screenshots, which would form the basis for the other images in any case.
The image effects I was using looked best in a built version, rather than Unity’s Game mode. So I ended up doing several builds tweaked for screenshots, one with only the main menu scene but no menus, and one with a run button so I could get into position to get the shots I needed. I could have added a free-floating camera to these builds, but I decided the player view was enough. And rather than using something more complicated, I went with a familiar option and added these builds to Steam, so I could use Steam’s screenshot function.
Taking screenshots was pretty much a virtual landscape photography session. I tried to get a lot of shots of the central monument, the land around it, the path leading up to it, the background landscape, and every combination of these I could think of, from a bunch of different angles. Once I had a few dozen shots, I went through them much as one would after any photo session. I quickly decided that I didn’t want anything that showed the monument in its entirety, and that became an approach that persisted across all the images I used.
Selecting screenshots for the itch.io page was easy, and I could put those straight on the page. Then I found one of the shots that did show the whole monument, and cropped it in Photoshop to only show a corner. That image became the basis of the cover image, icons and config banner. I used the Serbian-Cyrillic and Roman script versions of the title for the cover image and config banner, but I decided using only the Serbian-Cyrillic version was a stronger image for the icons. I saved a bunch of different versions of this image at different sizes, and that was all I needed.
The whole process of collecting and preparing all these images took a substantial amount of time, something I expected, but I didn’t expect it to take quite as much time as it did. Because of the small scale of the project, this ate up a large proportion of the total time before, release, roughly 10-15%. That proportion could shrink with a larger project, but then, the larger the project, the more it’s probably worth investing in this stuff. In future I think allowing at least 10-15% of project time on preparing marketing/packaging material like this is probably wise.
What I chose not to use in packaging
Usually an embedded YouTube video would be essential on an itch.io page. But because Spomenik-1 is a very short experience, any YouTube video would show a substantial amount of the game. But maybe more importantly, Spomenik-1 is about being in a space, and YouTube could only let people observe somebody else being in that space. I’d actually prefer people not to make videos of Spomenik-1, because I think presenting it to people at an additional remove is detrimental to the experience.
For similar reasons, I decided against including an animated GIF on the itch.io page. One of the reasons animated GIFs are great for promoting games is that they’re very effective at communicating actions, verbs, mechanics in games. But Spomenik-1 is all about images and imagery, looking rather than acting.
These considerations reinforce something I’d already been thinking about in relation to Robert Yang’s games, which is that certain kinds of games can’t get the promotional benefit of YouTube and GIFs without it detracting from the player experience. The takeaway here, I think, is to consider what kinds of games a focus on YouTube or GIFs privileges, and what kinds it neglects.
Publishing and promoting: social media connections
The other part of actually shipping a game that I wanted to tackle was promoting it, at least to some degree. Spomenik-1 isn’t a commercial project, but I did want people to see it. Part of the purpose of treating Spomenik-1 as a ‘product’ was also about taking a first step toward being known as somebody who makes and releases games. So as well as wanting people to play the game, I also wanted people to see me releasing it.
To this end, I posted links to the game and its accompanying artist’s statement to Twitter and Facebook immediately on releasing it, and I’ve tweeted about it a number of times since. I also wanted to thank the people I got feedback from about the game publicly on Twitter, and I won’t deny that this also had the side-benefit of some of them retweeting it to their followers, bringing them to the game as well. I also mentioned the game in tweets directed at Brendan Caldwell, who writes Rock Paper Shotgun’s Free Loaders features, and at Warp Door. These are both places I’ve found games similar to Spomenik-1, so they’re obvious outlets that might be interested in Spomenik-1, even though neither have mentioned it to date. And finally, this post-mortem itself is something I hope will drive some more eyeballs toward Spomenik-1’s itch.io page.
The biggest part of tracking the impact of these efforts is the analytics section on Spomenik-1’s itch.io page. Because it shows referrals, I can see where people are coming from when they reach the page, which lets me know which channels are putting the game in front of the most people. This is all really obvious, elementary stuff to anybody who’s done any kind of marketing, but it’s something I’ve never done before, and doing it for the first time has been fascinating.
Conclusion
Spomenik-1 is a very small project by most people’s standards, but I feel it’s achieved the goal I set out with: to make a short vignette game that expressed an idea in the form of a virtual space. Making Spomenik-1 is another step in the ongoing process of re-awakening my software development roots, and pushing myself towards making games, for my own enjoyment and satisfaction more than anything else. Over and above all the specific things I’ve learned, my biggest takeaway from this project is simply this: I can complete, polish and ship a game. And I want to do more of that.
Macrotransactions 