Nathan Young's Game Dev Adventures

in Blog Form, for Some Reason

[ncyrocks]

Nathan’s Studio VI Mechanic Prototypes, Episode 5: Random Fiddling That Ended Up Being the Core Gameplay Loop

Leading up to the September GDM, Mark put together a prototype of our game’s mechanics – at that point, we’d decided that while the theme of creep would form the base plot and concept of our game, the player needed a central gameplay loop that distracted them from the world around them, and that that loop would involve multiple platform mechanics. Mark implemented double-jumping, lunging forwards, and wall-running.

The week of the GDM itself, I put it upon myself to put together a prototype based off of his, so we’d have something to show off. I copied his lunging and double-jumping code, adapted his wall-running code, and added wall-jumping too. I made little mini-levels that involved the use of each powerup several times, made them only appear when the player couldn’t see it (as a test of our player progression), and added a few little touches of my own – effects that represented the force pushing the player (that remain in the game as of this writing, almost two months later) and a ‘stop’ mechanic that simply reduced the player’s velocity to 0. That last one was added on a whim but ended up being my favourite. I’ll write a post about our GDM adventures later, but I will say here that people liked it a surprising amount.

That got me thinking – if people like random movement mechanics like that, what else could we do with them? I brainstormed some ideas, and ended up implementing two more – the ability to slow your descent (usually to a complete stop, so we called it hovering) and the ability to convert all your momentum at any moment into upwards momentum (which is as cool and satisfying as it is fiddly and frustrating). All in all, we had seven mechanics to put together, which seemed a perfect amount – if we were to include separate towers as I included in my previous prototype, 6 would be an ideal amount. If you’re going to neatly surround a circle with other circles, you want to surround it with 6. (There are mathematical reasons for this  - 6 is the ‘kissing number’ in 2 dimensions – but I’ll spare you the details because I don’t know them.) Add in one more for the central tower’s tutorial section, and you get the 7 we have today.

That ended up being the final prototype I produced for Studio VI. I’m still developing it, seeing as it was used as a basis for the final game. I’m pretty happy with it – the 7 abilities give you a pretty useful, interesting, synergistic toolbox to play with. Just earlier today, we found a much faster way to move along the ground than walking – jumping, immediately stopping your ascent with hover, and lunging forward. You keep all your forward momentum but barely leave the ground. When I have those kinds of dynamics emerging from my game design, I consider it a success.

I want to note something else about the mechanics here – my idea for the player to be able to obtain as many or as few powerups as they thought they needed, and to obtain them in any order. Our initial plan was for the player to ascend the tower, and for each level to introduce a new powerup and a new mechanic they needed t advance. I came up with the alternative idea of letting them attempt a main, central challenge at any time, and to have the option of obtaining more powerups by attempting additional challenges in separate towers. I liked this idea for two main reasons: firstly, it allowed for the tower and player to represent nature and humanity in a more nuanced way – the player could take all the tower’s energy/life force/chi/mana/whatever and get all the abilities for themselves, or they could be resourceful and complete the challenge while sparing the tower. Secondly, it's what Zelda: Breath of the Wild did

The mechanics aren’t perfect – the controls need work and the exact values and variables need fine-tuning – but I’m really happy with them and how they've turned out. I might even go as far as saying they’re among my best work at BCT (but only if I was super-duper tired and emotional and hung-up on the fact that my time as a BCT student is going to end in exactly 12 hours to the minute (which I am)).

[ncyrocks]

Nathan’s Studio VI Mechanic Prototypes, Episode 4: The Garnet of Comradeship

After I made my ‘environment shifting behind the player when they take from it’ prototype, I made another one, based on a similar idea, that was more experimental regarding player progression than actual mechanics.

I deleted it a while ago, thinking that I wouldn’t need it again, and I didn’t take any screenshots of it. I’m kind of an idiot like that. You’ll have to use your imagination.

When play began, the player saw six 1m^3 cubes in front of them, forming a semicircle and facing inwards. On them were written things like ‘The Amethyst of Courage’, ‘The Zircon of Wisdom’, etc. (I spent, like, 2 hours researching gemstones that I felt were obscure enough that my use of them felt vaguely original.) The player had the option to pick one of them up – to absorb its power, I guess? They didn’t do anything in this version of the game, but these eventually became the coloured oases in the final version of the game. (We had already thrown around a lot of ideas about players getting abilities from some sort of collection of MacGuffin objects, so that wasn’t something I came up with.)

Actually, though, the impression that nothing happened immediately after picking a gemstone up was a bit mistaken. There were no platforming abilities implemented, but as soon as one of these gemstone cubes was let out of the player’s sight, they’d vanish and reappear in the distance – vastly taller, and now called “The Greenstone Tower of Benevolence” or whatever.

Why’d they do that? To be honest, I can’t remember my exact reasoning, but I remember that I wanted the tower to not only change around the player in hard-to-notice ways but to change in a way that made it seem as if it were defending itself.

After reading my original notes on this prototype (shout out to Evernote), I’m reminded that I originally wanted the player’s absorption of a gemstone’s power to take place during a cutscene, to force the player’s vision away from the other stones. Ben pointed out that that was a really crap idea, and that we should instead lead the player to choose to look away on their own. There isn’t all that much shifting in the final game, but one place where I’ve kept it so far is with the doors – when the player attempts a challenge, all entrances their current tower close. In the main tower, there are six doors that form a circle around the player, so at least one will always close, making a slamming sound. We haven’t playtested that yet (😬) but I figured that that would lead the player to look towards it and away from all the other doors, prompting them to close and for the player to realise that all the doors have been shut behind them. That’s not even usually possible with six doors in a circle, but there you go.

If my intention with this prototype was to give us ways to make it seem like the tower was defending itself in unseen ways, I think it was successful.

[ncyrocks]

The One Where I Realise I Haven’t Blogged In, Like, Two Months

This is gonna look good to the lecturers, eh? Two months of neglecting my blog, then a bunch of posts all at once. Molto bene. (Then again, I suspect I’m not alone in spamming posts this morning.)

The reason I haven’t posted in a while is probably pretty obvious – I’ve been working on programming for Kōwhai Studio’s latest game, which finally got a name in the time since I last posted: Oasis.

I should probably say that I’m sorry I haven’t written here, but I’ve been happy to just focus on working on our game: for once, I’m actually proud of it! It’s fun to play, the idea’s solid enough, and it’s something we can continue developing in the future. You couldn’t say all those things about our previous games, let’s be honest. Focusing on that instead of my blog isn’t something I’m ashamed of.

Since I last blogged, I’ve made a couple of prototypes, gone to a couple of GDMs, thought a lot about our game and about the fact that my BCT journey is ending soon – just over an hour from the moment I’m writing these words, depending on how you look at it. I’ll post about those soon – I’ve got a plan to finish up my blog with 300 posts (100 for each year, on average) by the showcase. Why do I feel compelled to do that? I dunno. I’m sentimental about weird things sometimes.

[ncyrocks]

You Must Be Updated on Our Social Media Aesop Fable

Yesterday, Mark and I presented the latest bit of work our group has done on our Transmedia project, ‘Tort-OS vs HEY!AR’, while the rest of our group stayed at the back? (For real, what was up with that? It wasn’t a big deal, but it was super weird.)

Since our last presentation, we’ve tried to focus our efforts on technologies we can use, figured out how to fake ones we can’t, written backstories and scripts – just generally sorted out some details that weren’t there last time. The CEOs have names, the companies have logos, everything’s just more fleshed out.

Writing the Twitter feud script was a lot of fun – I find a lot of humour in imagining social media managers just roasting each other by personifying their brands in totally off-brand ways – see here, here and here.

So I had some fun with that for this project. I also figured it was a perfectly modern, tech-startup-sphere way to portray the original argument between the tortoise and the hare – y’know, hare brags it’s the fastest, tortoise calls it out and challenges it to a race. Not only is it publicly interactable, I reckon it captures the zeitgeist perfectly.

[ncyrocks]

Nathan’s Studio VI Mechanic Prototypes, Episode 3: ExoSense 2 with moving walls

It’s not actually ExoSense 2 or anything like it, I just used ExoSense as a base ‘cause I didn’t want to reprogram picking-up code

One idea we’ve been fiddling with since our initial prototypes – and recently decided on as our main mechanic – is the environment around you shifting. I made a prototype of that last week, based around a maze that shifts when you’re not looking at it.

I brainstormed a bunch of ways the player could cause the environment around them to move, but I can’t remember most of them. I ended up deciding that in my prototype, the environment should move when the player picks up items, and not when they put them down. (We had this idea before I started the prototype, with the intent to use it as a metaphor for taking resources and things from nature, and not noticing the negative consequences until it’s too late.)

I started off by making the base object – the building blocks of the maze, which move in random ways when you’re not looking at them (not just moving to a different location but rotating and changing in size too). This worked surprisingly well – things actually moved when you weren’t looking at them (technically, when they hadn’t been rendered in the last 0.1 seconds (6 frames)) and stayed still when you were. When the movement was slow enough, it took people a while to figure out that they were moving, which was perfect!

After I’d successfully made on an object that did what I wanted, I tried making a maze out of it. It was pretty crappy, but it got the job done. The maze ended up working okay – sometimes things would become inaccessible gradually, but more often, the maze walls would be lifted above the ground one way or the other, and you could just walk straight under them. I thought the idea of things moving when you weren’t looking was pretty compelling, but I hadn’t executed it all that well.

But again, that’s the point of a prototype – try stuff out, see what works and what doesn’t, iron out the kinks, don’t spend too much time on it ‘cause you’ll probably have to ditch it. I really wanna see what more I can do with this idea because I think it’s got a lot of potential to create interesting gameplay and story ideas. I want to try moving things between set positions rather than randomly and moving room interiors when you’re not in a room.

In fact, I think this idea is so compelling that I want to try making all movement in our game not happen when the player’s looking (except for the player themself, of course). It just makes it creepier, in every sense of the word.

[ncyrocks]

Nathan’s Studio VI Mechanic Prototypes, Episode 2: That Game Maker One Where You Fight All Your Failed Attempts

For some reason, this was also an idea I had in the middle of a meeting… do I have all my best ideas when I’m supposed to be listening to someone else?

I had a few ideas for prototypes that all revolved around the player’s actions influencing variables in a way that works against them. My favourite one was the player fighting a version of themself for every time they’d died before. Several of my team members liked the idea too, so I thought I’d prototype it. I called it my “Farquaad Prototype,” after Lord Farquaad’s immortal words: “Some of you may die, but it is a sacrifice I am willing to make.”

I came up with several different ways to implement this idea – maybe the player’s failed attempts should leave ‘corpses’ of some kind where they died, which come to life zombie-style and then approach the player, or maybe they should appear in the next level after they died, or maybe they should all appear at the end of the game. Maybe the player character’s appearance should be randomised each time they respawn so that each ‘zombie’ is recognisable as a character you controlled previously (but led to their death). (Also, I didn’t actually call them zombies in the prototype, but that’s a really good word for them, so I’ll call them that throughout this post.) I probably should have considered all these options (and others) more than I did, but I figured I could try them all out with different prototypes. I only ended up making one of these ideas work before I ditched this prototype.

I initially tried prototyping this idea with Unreal, but that didn’t end up working; Unreal isn’t really made for 2D games, and the easiest ways I could think of to prototype this idea were 2D, so it was easier to use something like Game Maker, which I did.

Instead of fighting through many different levels, I ended up just making the same level repeat infinite times. Every time you completed the level, a number of zombies equal to the number of times you died since your last successful completion spawned. There were regular enemies too – after all, something has to cause you to die the first time. I made the player/zombies different from normal enemies in the following ways:

They were faster and larger

They fought with swords, giving them more reach and unique combat

They had more health and dealt more damage

I think I made the prototype too easy. The zombies had a bit less health than the player and took a bit more damage, making them so easily killed that you could easily fight a few of them and not die once – which ruins the entire point.

We didn’t end up using anything from this prototype either, and it’s not that hard to see why. It didn’t really have a tipping point – actually, it didn’t really have any good creep-y aspects at all. That was probably more of a problem with the execution than the idea, but either way, it didn’t work. Still, I and several other people wanted to see this idea prototyped, so I’m glad that I managed to pull it off, even if the result wasn’t that great. Also, polishing off my Game Maker skills probably wasn’t that useful, but it can’t have hurt too much. I still really like the idea, so I’ll consider continuing to develop it as a personal project (as if I don’t already have enough of those).

[ncyrocks]

Nathan’s Studio VI Mechanic Prototypes, Episode 1: Jewel Fuel

During the meeting in which we initially decided on ‘creep’ as the core concept of our game, I had an idea for a mechanic prototype. I mocked it up in a couple of hours using Python, tested it over a few days, and called it “Jewel Fuel.” It worked like this:

You’re in control of a jewel factory, which almost certainly isn’t a real thing. (I chose jewels pretty arbitrarily – they could’ve been anything.)

It manufactures makes 5 different kinds of jewels.

You start with 100 of each kind.

Every turn, you get the option to obtain a machine that, at the start of each turn, exchanges X% of one random kind of jewel for X+1% of another random kind (starting at 1% for 2% and increasing by 1 percentage point every time you obtain a machine).

If you run out of any kind of jewel, you lose. If you have 1000 of every kind, you win.

The idea was to give the player lots of different things to focus on and little control over how things happened. That way, it would be easy to forget about one kind of jewel, let it run down dangerously low, and not be able to get its production rate up again in time. (The opposite was also easy to accidentally do: give something an absurdly high production rate and accumulate way more than you needed. I once got 100,000 of one kind of jewel that way.) I made it turn-based, so the creep could be tense without causing panic – if you suddenly noticed you were about to lose, you could take your time and think your actions through, but you might not be able to save yourself.

It ended up being reasonably easy to win, but it took some concentration, a bit of strategy, and a lot of time. I tried fiddling with the numbers – what if you had 7 kinds of jewels to manage? What if you started with 20% production of one kind for free, but the machines’ cost climbed quickly? Those usually ended up being either impossible to win, or impossible to lose if you waited long enough. My initial setup seemed to work better than any variations I tried.

We didn’t end up using this prototype, or any of its ideas. I’m perfectly okay with that – it was a two-hour mock-up Python prototype, after all, and we’re basing our development cycle largely on prototypes this semester, so lots of things are going to end up in the bin. Furthermore, it kinda sucked. It shaped our ideas around what our creep mechanic could be, influencing our decision to ditch that idea entirely. But we got to explore its ideas quickly and easily, I got to brush up on my Python skills, and it didn’t take up much time at all. That makes it a successful prototype in my book.

[ncyrocks]

Well, if we can’t do an AR experience AND a drone race in a public place AND live GPS tracking AND get thousands of people to engage with a 15-point uni project, what CAN we do?

I met with @archolabs and @iamyoureye this morning to discuss our transmedia fable, and how ridiculously unviable it is. We came up with a few more doable ideas, some ways we could keep most of our idea but produce small parts of it, and also discussed the backstory of our metaphorical tortoise and hare.

I listed every single technology/medium we planned to use and assessed our ability to actually use it. I figured it was more or less like this:

Social media/real life advertisements building up to the race: still totally doable.

Street performance with the tech CEOs launching their drones: doable, but would be kinda dumb without actual drones.

Actual drone race: we’ll see. We need two drones and permission from the council to do that.

Live GPS tracking and video from the drones: slightly less doable than the drones, seeing as we’d need to actually get the drones first, but still po-o-ossibly doable.

Pre-filmed drone footage: Slightly more doable than an actual drone race.

Watching fake drones through AR: yeah, nah.

Fake GPS tracking: still doable, provided it’s a live-streamed video and not on, like, Google Maps or something.

Live social media race updates: 100% doable.

Continued user engagement and exquisite-corpse continuation: we’ll see… that may have to be the point where we leave the project to its own devices and come back when we take Transmedia Narratives 2. What do you mean that’s not a real paper shut up man

So yeah. Most of it’s still doable, just not the main bits. We can definitely fake GPS-tracking of the race and social media updates, but that might be the closest to an actual race we can do.

Other than that, we elaborated on our tech companies’ backstories.

The basic idea is that their CEOs used to know each other and were on good terms with one another. When they competed for startup funding, one of them (the Hare) stabbed the other one (the Tortoise) in the back (not literally), ruining their relationship and starting a rivalry between their firms. They’re having a competition to see which company can engineer the fastest drone.

I basically envision the H-AR CEO as the most obnoxious Silicon Valley stereotype possible: he’s arrogant, tries every new productivity trend that comes along (microdosing, anyone?), thinks his company is disrupting enormous industries all at once despite the fact they’re barely profitable, etc. Then I envision the Tort-OS CEO to be a whole lot more down-to-Earth, running their company out of their garage, hiring a tiny amount of people to produce something truly valuable to society, slowly but surely.

I’ve sorta defaulted into the position of the lead writer on this project – I’ve no idea whether that would be best or not, but hey. I’ll work on it gradually over the following week and get something back to the group by our next meeting on the 14th.

[ncyrocks]

The Tort-OS and the H-AR: Our Original Transmedia Narratives Idea That We Had to Kinda Ditch but Don’t Worry About That for Now

I’m pretty proud of the idea we came up with for Transmedia Narratives, considering. Pete liked it, Pete’s friend liked it, it was good. So good you wouldn’t have thought it was put together in less than an hour by 2 people who weren’t planning to work together until less than 24 hours beforehand.

I can’t remember exactly how we got to our idea last Wednesday, seeing as the brainstorming session lasted a whole 20 minutes and we barely wrote anything down. I do remember that @archolabs suggested using an old fable as our narrative base and that I suggested the Tortoise and the Hare. We pretty much liked everything we came up with from there. Two tech companies racing drones instead of animals? Awesome. A street performance where two people pretend to be the CEOs launching their drones? Love it. AR representations of the drones? Live social media updates? GPS tracking? An exquisite-corpse style continuation of the narrative, based on community engagement? Why the hell not.

We actually have to produce it, is why the hell not

Our idea, as we pitched it on Wednesday, would have gone like this:

Build-up to the drone race with social media posts explaining their backstories and real-life posters to get people interested and engaged in the story

Street performance where the two tech CEOs are portrayed as launching their drones at the start of the race

One of the following approaches to the race, each with a significant drawback: An actual drone race: two drones race down Queen Street. One goes faster, but stops due to its driver’s arrogance; one goes slowly but steadily towards the finish line and only just beats the faster one. People can watch the drones in real life, watch live-streamed drone footage online, or track their position online. This approach had the possibility of the drones not acting properly in some way, compromising the narrative – however, the drones would be real. Or... A virtual drone race, simulating all 3 aspects of the real drone race: AR allows people to use their phones to see where the drones would be if they were real; live-streamed video allows them to see what the drones would see (and would be overlaid on live footage of Queen Street); people can still track the drones’ GPS positions, but they are now pre-programmed. This approach had the drawback that people would not be able to see actual drones, compromising the reality of the story; however, their behaviours would be certain.

Live social media updates from the fictional companies, and engagement between them and users; make the narrative real, and allow people to interpret it however they want, providing the fable’s moral

Users continue to discuss the story after it’s over, continuing the fictional narrative however they want to

Exquisite-corpse continuation of the narrative based on users’ social media posts, creating a running storyline with a crowd-sourced plot

Hopefully, that makes sense.

There are a few problems with this plan. For one thing, we’re relying a lot on social media engagement – if we can’t get people to engage with the story, major parts of our project fail entirely. Also, none of us has a drone or could possibly do any kind of AR experience like we planned.

[ncyrocks]

On the Shortcomings of Storytelling in Modern Interactive Entertainment; or, Why My Favourite Games Suck Balls

I never really know what to say when someone asks me what my favourite game is. For a start, choosing a favourite game in any of my favourite series is tough enough. I think I usually pick one each from the To the Moon, Life is Strange, and Super Smash Bros. series, sometimes throwing in Ace Attorney for good measure.

But now that I think about it, that’s kinda misleading. I love the To the Moon series, particularly Finding Paradise – they always tell such beautiful stories about human lives. And I enjoy the Life is Strange series, no matter how much I like to shit on it. But they’re not really games. They’re a lot more like interactive films.

The To the Moon series neither pretends nor tries to be interactive. They offer only extremely minor choices that aren’t recognised at later points in the story – they just force the player to wander around different places and press a button every time someone speaks so the script can progress. While researching this post, I found out there’s going to be a To the Moon movie, and I’m 0% worried about the transfer from game to film. Most game movies kinda suck, but this one is just adapting a linear story from an experience that’s closer to a movie than a game in the first place.

But that’s not really an issue; by refusing to even consider interactivity between the player and the story, they get away with it. If you know what you’re getting when you play a Freebird/Kan Gao game – no interactivity, just a touching story with moving music – you’re fine with it. But if you’re expecting a game, you’ll be disappointed, because you’re not getting one.

Then we get to Life is Strange, and I really hope this is the last post I write about it. This game tries to be non-linear and interactive with its story, and it just isn’t. It has two big mechanics that the To the Moon series doesn’t – rewinding and choice-making – but their entire purpose is to serve the story. Rewinding gives you more time to make choices and lets you reconsider them, and choices affect the story. Well, except they don’t. Instead of influencing the plot of the game, choices are treated as things to be recognised later. For example, you have the option of signing a teacher’s petition in the first level (I completely missed her, and so didn’t sign it). If you sign it, she thanks you in a later chapter. If you don’t, she tells you it was a pity she didn’t get more signatures. That’s it. I’m picking a slightly extreme example, but other choices don’t do much more than that to influence the plot of the game – everything leads to the same final choice (which ignores most of the game’s story except for the very first bit anyway). Ultimately, Life is Strange gives you more control over the story’s particulars than Finding Paradise or To the Moon, but it’s still closer to a movie than a game.

I once heard it put this way: Western game developers make movies, while Japanese devs make toys. It’s a simplification, and it excludes a hell of a lot of countries and developers, but it’s a real trend. I’d put it this way, though: Western devs focus on story, while Japanese devs focus on mechanics. Starting with a story sets a path forward for both the developers and the player, with little room for agency except over minor details. Starting with mechanics, on the other hand, lets developers experiment and refine a game until they have something truly fun, lets a player do what they want (more or less), and tends to lead to a better game. At the very least, it ensures that it is actually a game, instead of a mere interactive experience.

Of course, I’m picking on a very small sample size here  – two series, with two games each. There are tonnes of other games that have much more dynamic, interactive stories and storytelling systems, about 20 of which I’ve researched enough to want to write a blog post about them. I’ll continue writing about them in the coming week(s). But I wanted to start by elaborating on why I had to research those games; they’re not the norm, and they’re not the most popular of their kind.

Almost all my most passionate creative endeavours in the past have been dedicated to recreating something I already enjoy (read: something that already exists way better than I could make it). One of my first ventures into game development was making a crappy Super Smash Bros. clone. So it’s no surprise that I want my final project to be like my other favourite games – a video game with an emphasis on its story. But from the start of this project, I decided that I didn’t want to make something that just blindly copied my favourite games. While I truly enjoy them, they have some serious issues. Hopefully, I’ve now explained a couple of those decisions; specifically, my decision to focus on mechanics and gameplay first, and my refusal to start with any details (especially about the story) set in stone.

[ncyrocks]

Working Backwards vs Working Forwards

Currently, Kōwhai Studio has two main ideas that we are exploring developing this semester: AJ’s Creep idea and my idea to produce a new storytelling system from scratch alongside a story to be told with it. My idea, which I call Project Pīwakawaka for largely arbitrary reasons, has fewer supporters, and I understand why. I’ve defined how (and why) it should be developed instead of what should be developed, and it’s harder to commit to developing a game when you don’t know what it’ll end up looking like.

I’m tempted to ease this reluctance with some example ideas or a proper GDD outlining exactly what we should do. I have some ideas, but I’m worried that talking about them would restrict our thinking too much. Instead, in this post, I want to make the argument that developing our final project this way will result in a better end product, as well as making it easier to develop.

I produced two different interactive experiences with Unreal Engine 4 last semester: ExoSense for Studio V and Magical Mushroom Trip for Virtual and Immersive Environments. I developed them in quite different ways, so it’s not really a surprise that they turned out quite differently.

ExoSense was developed with an unusually large team (by Colab standards), encompassing basically every skill set needed for 3D game development. We defined our idea quite early on (flawed though it was) and worked towards seeing that initial vision through as well as we could. In the end, it received a disappointing mark, failed to include a large amount of what we planned, and didn’t turn out as well as we’d hoped. I’m still proud of what we made, and I know others are too, but I also feel like we could have done a lot better.

(n.b.: almost all of the above paragraph also applies to Project Kōwhai.)

Meanwhile, Magical Mushroom Trip was developed by AJ, Garian, and me - a way smaller team with major gaps in our skillset. We didn’t have anything we particularly wanted to make. Instead of ideas, we had constraints - it had to be a VR experience, and it had to utilise the skills we did have (i.e. sound design, modelling, and programming). We ended up producing a complete, compelling experience that Stefan loved and gave an A+.

When I realised this, I had to ask myself: “What happened?” How did a smaller team with no ideas produce something more fun and complete (if smaller and less flashy) than Kōwhai Studio did with ExoSense?

I think I’ve figured part of it out: we worked forwards instead of backwards.

Once we decided that we were working together on a VR project, we came up with some basic ideas: letting the player use echolocation to find their way around a cave. Inside the cave were objects (I don’t remember why we chose mushrooms) that produce sounds when touched. It wasn’t a project we particularly wanted to make, but an achievable one that used our strengths and met the requirements. Why echolocation? It utilised VR well and gave me something to program. Why sound-emitting mushrooms? To give AJ something to model and Garian sounds to produce. Why a cave? We didn’t have to do any environment design or texture work.

Beginning development was super straightforward, seeing as we’d all given ourselves simple jobs to do. We easily produced what we needed to well before the deadline, so we extended ourselves: Garian made an ambisonics track for the cave, I made the mushrooms emit their own visible sound waves and cycle through the rainbow, and AJ made the cave itself and a tree at the end to give people something to work towards (actually, I think she did that before the mushrooms, but my point is that we had time to do more than we said we would).

Scope size wasn’t a problem, because we had barely any to begin with and increased it as we went along by just making what we wanted to. Nothing was missing, because nothing was really planned anyway. It just did what it did well, and ignored everything else.

Compare that with ExoSense’s (and Project Kōwhai’s) development: we started out with a pre-defined idea, and focused on producing as much of that original vision as we could. We had to sort out some particulars, but there was neither room nor time to add anything beyond what we wanted to; in fact, our original scope was too large for us to fully realise, leaving us disappointed.

I’ve advocated for radically shrinking our scope before, and I now think that this is the best way to do it. Your scope can’t be too big if you don’t have one.

It turns out that this is already a pretty common idea (which really shouldn’t be surprising): lots of people call it ‘focusing on the process, not the outcome’ (though I’m not the first one to call it working forwards and backwards). My productivity idol, Cal Newport, has written about it a couple of times, as has my other productivity idol, Chris Bailey. I remember reading about a study where students were split into two groups: one group was told to aim for a particular grade on an upcoming exam, while the other was told to aim to study for a set amount of time each week. The second group well outperformed the first.

The last thing I’d like to bring up is another post from Cal Newport: this one, on doing what works rather than what’s satisfying. He says that when you don’t have an understanding of what techniques work and what ones don’t, you end up doing a lot of things that feel productive but don’t actually make valuable progress (NaNoWriMo being a good example for wannabe writers). A much better thing to do is to study what’s been done, and what works, based on people who've gone before you. I can’t pretend I’ve done thorough research on how people come up with great game ideas, but I’ve heard a lot of stories of developers working forwards. For example, Splatoon started as an experiment with its mechanics, which were thematically simple but eventually defined its distinctive aesthetic and characters; Plants vs Zombies started as a skinless tower defense game before it was given its theme of a garden protecting itself from the undead; Mini Metro was largely designed around the developer’s strengths and weaknesses - neither Peter nor Robert Curry could really do graphic design, so it has a minimalistic aesthetic based around simple geometric shapes, and the sound design is similarly simple and based on the trains’ movement.

Meanwhile, when I think of games that start with a predefined idea of what they’ll be, I think of linear, narrative-driven games like Life is Strange, which allow some changing of particulars but give a mostly unsatisfying, linear experience.

Which (of course) brings us full circle, back to Project Pīwakawaka.

I understand why some of the team members are leaning towards AJ’s Creep idea over mine - it offers a much clearer vision of a finished product, and it’s much more satisfying to produce parts of an idea you can see in your head, as opposed to working towards an idea you haven’t thoroughly defined.

But while that way of developing games might feel better, I think it’s clear that it doesn’t work as well. We’ve worked backwards from preconceived ideas for several semesters in a row - 2 to 4, depending on how you count them - and we haven’t produced something we’re all truly proud of yet. We never include everything we want to, and we’re always a bit disappointed in the final result. There’s a lot I like about AJ’s idea, but I don’t think we should start with an idea.

Instead, I think we should work forwards - start with our constraints, work from our strengths, make stuff we think will push the idea forward, and define our idea/scope as we go.

We have two constraints: what we make has to be innovative, and it has to deal with real-world issues. My idea to help people live well by designing a new way of telling stories ticks both of those boxes. We still have most of the skillset we had last semester: in my idea, the programmers and game designers will work towards making a great storytelling system, while the environment designers, sound designers, visual artists and modellers will work towards a story and setting that complements the system.

If we do this, I think we’ll finish off our degree with a complete, satisfying game that we’ll be truly proud of.

[ncyrocks]

Nathan’s Pre-Studio Studio VI Idea: First Principles, Living Well, and Why I Love to Hate “Life Is Strange”

This semester, I really want my Studio project to have a great purpose behind it. As I’ve said before, I think that a lack of a clearly defined purpose was the biggest problem with ExoSense and its development – defining a driving purpose beforehand should help this project immensely.

The best way I could think of to do that was to think from first principles – somehow. Thinking from first principles is an idea that’s often associated with Elon Musk, for good reason – that’s not only how he does things, but how he decides what to do. His efforts to colonise Mars and reduce the harm that AI can do are two good examples – no one can do anything good if we’re all dead, so he tries to make sure we’ll survive. He may be kind of a dick, but by thinking about things as central as his life’s purpose from first principles, he manages to do an insane amount of good (depending on who you ask).

I don’t think I can reasonably claim that the ideas I had were results of first-principles thinking and nothing else, but I still like what I came up with.

My first idea was one I had a couple of months ago: if first-principles thinking is that great, maybe the best thing I can do is promote it; that is, maybe I can do more good by influencing other people to solve problems than I can by solving them myself. I had a couple of problems with this idea, though. I didn’t know how I could promote that way of thinking through video games (though I’m sure it can be done) and people already solve problems anyway.

I liked my second idea a bit better, mainly because I knew what to do with it. It’s perhaps best summed up by this quote from Dead Poets Society:

Medicine, law, business, engineering, these are noble pursuits and necessary to sustain life. But poetry, beauty, romance, love, these are what we stay alive for.

Working to ensure humanity survives is great, but what then? If all everyone did was work hard so that people could continue to live in the future (like I was gonna suggest with my first idea), they’d forget to live good, meaningful lives themselves. We’re never going to solve all our problems, and even if we did, we’d need to know why.

I didn’t think there could be a better purpose for this semester’s project than helping people live well, but I also didn’t think there could be a vaguer one. You could make an argument that any good game helps people to live well by giving them something fun to do.

I figured that the best way I could think of to help people live well is through storytelling. Telling stories of people learning to live good, meaningful lives might fit the bill better than anything else could, especially if they were interactive.

That’s about the point when I remembered something that’s bothered me for a while: games aren’t great for telling stories. I’ve already written about this: they struggle to find a way to integrate player agency with compelling storytelling. In my mind, the best example of this problem is Life Is Strange (but you probably already knew that). Among other reasons, Life Is Strange disappointed me because it tried to tell a story that was not only great but able to be influenced by the player. It had well-written characters, amazing atmosphere, all that jazz – but it didn’t actually offer any real agency. You couldn’t really change what happened, only how it happened (except at the end, which didn’t take any of your previous choices into account as well as being a cheap trolley problem that didn’t have anything to do with most of the story’s events). I’ve also already written about this – many, many, many times.

But when I wrote about why games tell crap stories, I also wrote about some ways they could improve, and the more I look into it, the more ways I find.

Anyway. My point is this:

This semester, I want to develop a game with a new, innovative storytelling system, with the intention of telling stories that help people live good, meaningful lives.

Normally, I’d link to a GDD that would outline exactly how I plan to do that, but this time, that’s not really applicable. I can’t describe the game’s mechanics, because they would have to be extensively researched, prototyped and tested so they could be different from anything else that currently exists. I can’t describe the game’s story, visuals or sounds because those would also have to be developed from the ground up alongside the mechanics. I’ve still put together a basic GDD for the team, but it doesn’t really say anything I haven’t said here.

I think the best way to go about making this idea happen would mean splitting the dev team into two groups - one to work on the mechanics/game design/programming, one to work on the story/atmosphere/sound/visuals. They’d have to work together to make sure the story and storytelling system complement each other, of course, but seeing as the core code of the game won’t exist until relatively late in development, the rest of the game should be ready to integrate with it after it’s finalised (possibly before, depending on how it works).

[ncyrocks]

Nathan’s Studio V Week 14: The Last Bit that I wasn’t sure would come, but it did

Whew. This semester has, in a lot of ways, seemed like the biggest one I’ve done yet. The fact that’s it’s ending is making me a little emotional, actually. But I’ll keep my full reflection for a little later (either late this week or, like, later today).

Anyway, this is what happened during this semester’s final week.

On Monday, I started by trying to clean up our Bitbucket repository - Mark and Garian each needed to push around 100MB worth of files, and we had about 5MB free. It turns out that we had been wasting around 600MB on starter content this whole time though, so I went and deleted the worst of that, freeing about 550 MB or so. I’d love to say that that was enough to last us our final week, but that’s not true. Anyway, I pushed the changes I’d already made and helped the others with their stuff.

On Tuesday, I stayed home and helped Mark with his programming remotely - not the greatest idea. He started to implement a lot of stuff, but it wasn’t until the day after that we really got anywhere, especially with Mark’s Sourcetree not working correctly. I wrote/finished more posts, and worked on Creative Workflows.

On Wednesday, I basically sorted out programming stuff and source control stuff for the whole day. There’s just so much stuff

On Thursday, I stayed home and mostly worked on Creative Workflows.

On Friday, I helped Mark with his stuff even more (it’s hard for the both of us to program on two separate computers, due to the nature of Unreal’s Blueprints that we’re programming with, which is why I helped him with programming more than I programmed this week) and finished off Creative Workflows.

On Sunday, I came in to finish off the game. We sorted out some finishing touches, like making sure people could see, making sure players don’t spawn three times and making sure the second level worked. (I’m only being partially facetious - we did mostly work on finishing touches.) We packaged the damn thing (well, the others did) and called it done (at least for the purpose of submission - we may have to implement a couple of changes for Open Studio).

I also wrote:

Why everything I wrote/said about releasing ExoSense publicly was either naïve or not something I wanted to commit to more than letting people do what they want

How the game’s core concept manifested in the final product, seeing as I hadn’t actually talked about that before

The potential future of ExoSense, and why I should it should never be

[ncyrocks]

On the future of our bug-ridden, not-online, still-lacking-a-driving-concept-at-its-heart video game

Or - and I don’t like saying this - its lack of one.

There are a lot of directions ExoSense could go in in the future. The playtesting feedback we got from the GDM had a lot of suggestions, and I’m sure there would be a tonne more of useful feedback we could (and will) get from future meetups. Stuff like the UX, the way the levels flow into each other, ways of getting the players to cooperate - stuff that could stretch our concept further. One thing the feedback made clear was that people liked our idea - it just needed explanation and development.

We took that feedback and made a whole bunch of good changes to the game. We no longer start players off with a plain black screen with words on it. I mean, that was never our intent, but we made a point of including a 3D cutscene before the players start, so that they at least get the idea that our game is 3D. We fixed a load of other things, like players being able to drop the orb through the floor, but I don’t think those really merit mentions here.

To take the feedback further, I’d say that a cutscene isn’t enough. We should include a tiny section of non-sensory gameplay before the players lose their sight and hearing, to familiarise them with the controls and basic gameplay before we introduce them to the game’s signature twist of deafblindness. We’ve also recognised a couple of other areas that need development, like the number of levels and senses as well as the rovers’ abilities that we never got around to.

We could also elaborate on the backstory of the planet, its inhabitants, why the cave contains alien buildings/puzzles, and so on - but that doesn’t really have anything to do with the game’s core concept. It might make for a better experience, but not for a better game.

All this discussion of where we could go next, what we could improve on, and what people liked and didn’t like about our game is great. This semester would be pointless if we didn’t learn from it.

But I’d be being dishonest if I didn’t include this:

I don’t think we should continue developing ExoSense.

I mean, if other members of Kōwhai Studio want to continue its development into the next semester, they should feel free. I’d enjoy seeing it developed more, and I’d absolutely love to see it released.

But I don’t think any part of that is likely. The game can’t be released unless someone fixes its online play, which I tried and failed to do for 2 months. If anyone else wants to try, go ahead, but I wouldn’t bother.

That’s not even the main reason, though. I don’t know about the others, but I personally want to move on to something else.

I enjoyed working on ExoSense and I learned a lot, but I was never truly passionate about it. I didn’t wake up in the morning eager to help bring it into existence. Like I’ve written several times before, it was a mishmash of several ideas that had been thrown around by several people in our studio, which meant that it wasn’t anyone’s idea. There was a clear consensus among the people we explained our idea to at the GDM - it was cool. I don’t disagree, but I do think it lacked heart. ExoSense had a cool gimmick, but little real personality.

I’m sorry if this is coming across as a put-down to all the awesome work that was put in by the 8 incredible team members I’ve had the privilege of working with this semester - they all produced great work that I truly enjoyed seeing. But it was all working backwards from an idea that was kinda cool but not truly great, and no amount of music, concept art, level design, UI, modelling, animation, or anything like that could cover that up.

We tried hard to produce a cool game. In my subjective opinion, we failed.

I want to make one final thing clear about that, though: I don’t think that’s a bad thing.

One more time in case I wasn’t clear:

We failed, and that’s not a bad thing.

I’ve written about this before; failure isn’t failure, as long as you learn from your mistakes and keep trying again. Failure isn’t the nemesis of success; that’s Lukewarm Mediocrity. It’s not like we half-arsed this game’s development - we full-arsed a faulty idea.

We brainstormed an idea, we committed to it, we failed, and now we can learn from it. We spent 4 months making a game, developing our skills, and we got tonnes of feedback from it. We found some great ways to produce a game that’s okay, but not as good as it could/should have been.

There’s so much to learn from there, and the worst thing we could do is fail to do so. I’ve already written about some of the lessons I’ve learned from failing this semester, and I’ve got a couple more that will probably end up being posted next semester.

I wish I could be talking more about what’s next for ExoSense instead of about how I want to leave it behind. But let’s be honest: we’re at university. We’re not a professional game development studio - we’re here to learn. My journey with ExoSense will probably end on Friday at the Open Studio. I’m glad that I spent my semester developing it, and I’ll be glad to learn from it and leave it behind.

[ncyrocks]

Turns out ‘forced co-operation’ is actually a euphemism for slavery... oops

ExoSense’s central, core concept has been co-operation pretty much since we came up with it (although we weren’t sure it would be strong enough at the time).

If this is news to you, this is probably your first time reading my blog. I’d welcome you, but you probably won’t actually find it very interesting, so I’d say close the tab and find something better to read.

Otherwise, if you’re remotely familiar with what I’ve been doing for the past 3 months, you already know that ExoSense revolves around co-operation - still, I want to write a post about how it encourages (really, forces) co-operation between the two players.

The main and most obvious way ExoSense makes its players co-operate is through the game’s central gimmick/reason for existing: shared senses. One player can see and one can hear. Again, this really shouldn’t be news to you, but I’m writing about it anyway because it’s what I’m being graded on.

We’ve used these split senses to force the players to co-operate in several ways:

The puzzles that the players complete to advance revolve around manipulating physical (visible) devices, with clues as to how to complete the puzzles embedded in the audio. The orb’s ambient hum gets louder as it approaches the door, and the buttons only make a sound when they’re needed to open the door.

It's kinda hard to see where you're going when you can't see, so if one player is blind and one isn't, the sighted player will have to communicate what they see to the blind player for them both to be able to move well.

We also planned extra senses that would force players t communicate, such as heat senses. These didn't end up working out, although we are currently seeing if we can implement echolocation.

We also require both players to work together to complete some of the puzzles - some of them can technically be completed by a single player who knows what they’re doing, but not all of them. (Except replace ‘some’ with ‘one’ in that paragraph because we only have two puzzles)

After that, we planned to add separate functionalities to each of the two rover designs, but we didn’t end up with enough time to implement those. We would have forced the players to co-operate by giving each rover different sets of tools they could use to complete puzzles and explore the game’s world, but right now, they have the same abilities between them so either of the two players can carry out any given task.

It would have helped the concept tremendously for the rovers to have different abilities, but the fact that we considered it is probably a symptom of scale creep that should have been nipped in the bud. But hey, at least we thought of it, right?

[ncyrocks]

Remember all that stuff I said about potentially releasing this game publicly? Yeah, forget about that

Personally, my ideal outcome for this semester would be making a polished, high-concept, publishable game that we feel proud releasing to the public as a studio.

It was a nice thought, past Nathan, but it didn’t work out.

I wanted us to be able to release a game publicly for several reasons. Firstly, I wanted us to get our names out there. Having a published game that people can download and play is a great thing to put on a CV, especially when you want to work in game development like I do. Secondly, I felt like our previous projects were too unpolished - good efforts from uni students, but not actually fun to play, and bound to be embarrassing ten years down the line. Thirdly, I wanted to see if I could make something people would pay for - and the money could go towards funding future development.

None of those worked out. I feel like I learned a lot this semester - my game programming skills have grown, I feel like I’m a lot more experienced working in a team, and I will never ever touch online play again unless I absolutely have to.

But we didn’t make a releasable game. I spent about two months making the multiplayer aspect of the game work in such a way that it would be releasable, and it didn’t work. Without a detailed set of instructions, no one who downloads our game as it is would be able to play it. It’d be a joke to even put it up for free on Itch, let alone charge 5 bucks for it on Steam.

I don’t think we were ever really headed towards a releasable game. With 9 people, there are always more ideas being added to the pile, and these are implemented and worked on constantly. Without any one person deciding what ideas to keep and what to throw away (like I mostly decided not to), the team will spend most of its time adding new things and not polishing old ones. That works out all right for student projects, but it means the game will never reach a releasable state (at least, not in a 3-month-long period).

If I wanted to release ExoSense, I would have had to take a lot more charge of it. I would have had to cut a lot of our content, cut down the concept so it would be fun to play with fewer elements (possibly to the degree that we would have had to change the central idea), and make everyone spend a lot of time improving things they’d already done. I didn’t want to do that, so I let the project take its own course.

I’m pretty comfortable with the direction ExoSense ended up taking. Hopefully, the others gave themselves enough work to improve their skills - I know I did. I didn’t get a project I could show off to potential employers in quite the way I wanted, nor was it perfectly polished, nor will it return us a single cent - but we had fun and learned a lot, so who cares?

[ncyrocks]

Nathan’s Studio V Week 13: Probably not enough done, seeing as the thing’s due in a week

This past week, a lot of what I got done was meta-stuff. Blog posts, source control management, and of course moving our studio space around so we can show off our game in a semi-presentable way. Not actually much work on the game itself, which is FINE because it’s NOT DUE NEXT MONDAY

Monday was the Queen’s Birthday.

On Tuesday, I wrote blog posts, cleaned up BitBucket, and fixed some things that I’d already fixed but had been overwritten.

On Wednesday, we spent the whole day moving desks and things and then playing poker. I won, but not out of skill, as usual.

On Thursday, I wrote more blog posts.

I felt particularly tired and worn down on Friday, and took the day off (I planned to work during the weekend anyway, so I was okay with this).

On Saturday, I wrote even more blog posts and regretted not doing so more over the semester (except not, because I spent that time on more important things like not fixing our online play).

On Sunday, I programmed the buttons and door for the end of our level.

I also posted:

How I broke the networking for two months and fixed it in an hour (except not really)

Why I’m less antsy about whether the game’s any good or not