thethirdkate

[thethirdkate]

Photo Match Prototype #1

This is a prototype for a game where the has to explore the scene to take photos matching the target. The mechanic is functional - the player can:

- See the target, and hold alt to bring it up as an overlay

- Move around the scene and press space to take a photo

- Click the button to compare and see if their photo is a match

In terms of gameplay, the ultimate idea is that the player is not given an identical target, but a sketch or outline of some kind. They will take multiple photos, which will then form a collage to make one big final picture. The end result may be unexpected - for example, their pictures of plants and kitchenware add up to make a mosaic of a rabbit. I’d also like to explore a version using a wireframe shader to make lineart rather than colour blocks.

[thethirdkate]

Global Game Jam 2021: Get That Door!

This year I joined Game Dev London for some remote Game Jamming in the theme of Lost & Found. 

Our game revolves around the mechanic of rummaging around in your house looking for a key while someone impatiently knocks at your door.

Play Get That Door! on Itch

The team was:

Thomas Kiley (programming)

Rachel Shuttleworth (audio)

Me (game/level design, some code dabbling)

Unity Asset Store (all the art assets)

[thethirdkate]

AnxietyWare Journal #3: Art!

Here's where I'm at after a bit of art experimentation.

Direction feels like a good fit - it's quick and scrappy (highest priority), reflects my personal doodle style well, and has scope to reflect the weird, surreal nature of anxiety dreams. Pinspiration board: https://www.pinterest.co.uk/thethirdkate/doodle-styles/

I had previously look at more nightmareish stuff - https://www.pinterest.co.uk/thethirdkate/nightmares/. It didn’t feel right - the game should be more weird than clichéd horror. The bright but super creepy feeling of Midsommar was another interesting direction, but the slow, tense build up that requires is a bad fit for the game’s frantic gameplay.

I'd still love to experiment further with how to introduce an increasing sense of unease as the game goes on, and have some ideas about how to incorporate that into this style. 

But for now the main thing is to have enough direction to tidy up the minigames so far and get player feedback, and not get distracted/overwhelmed by art for too long.

[thethirdkate]

AnxietyWare Journal #2

My new goal is to add to this once a month (at least), in sync with doing a monthly screenshot Saturday.

Lots to add this month!

- Trees minigame added

- Tiny Baby minigame added (screenshots next month!)

- Found an art style that’ll “do for now” (more notes in next post!)

- (Hopefully) got my git repo running correctly

- Battled xcode and got it running on device 

“Trees” minigame

Very WIP in visuals - player has to dodge falling trees by dragging the  character left and right, and make it to the end of the level without getting hit. Higher difficulties go faster and have more trees falling.

[thethirdkate]

AnxietyWare Journal #1

As I mentioned before, AnxietyWare (working title) is my current side project.

Over a handful of short sessions I’ve made the structure around the microgames, i.e. randomising and loading them, timing them, increasing difficulties and losing lives.

The first microgame I wanted to prototype was “wrong boyfriend,” where the player has to somehow find the right boyfriend. 

Mechanic Idea Prototyped

- The player sees a polaroid of the “right” boyfriend - The player swipes left to discard wrong boyfriends until they find the right one, when they must swipe right

It Didn’t work

The next step I’d planned was to make the instructions and feedback clearer, but coming back to it after a break, it felt like the wrong direction.

The Tinder interaction seemed like a neat fit, but I don’t think it’s intuitive enough. Why? Because I can’t sum it up in one instruction - it needs two things explained: 1. Find the match and 2. Swipe right/left. For me (admittedly not a Tinder user) it’s one step too many to parse for a microgame.

What’s next

I have 3 alternative interaction ideas for how to represent this dream. I’ll prototype at least one (probably the swipe based one, as I already have that interaction) and see what’s feeling good:

1. Tap the right one in the crowd of randomly moving people

2. Tap the right one in the line up (the differences between them could be very subtle - more like spot the difference)

3. Swipe left to get through the whole pile to get to the last one, which is “right” (like any of the WarioWare games that require very speedy tapping)

[thethirdkate]

Notebook Ideas #2-4: Playground Games

Here’s a selection of ideas for simple/hypercasual game mechanics based on playground games from my childhood. There’s various ways the mechanics for these could be implemented, but they’d be relatively fast to prototype.

Stepping Stones

This is a game my family and I invented and used to play on the patio stones at my grandparents’ place. You start at opposite ends, take it in turns to jump from one flagstone to another, and win by getting both your feet on a stone someone else is on. The real game is as much about how you position your feet and try to block others from landing on you, but the game idea is a very simplified version. Technically, you aren’t supposed to push each other over...

Stuck In The Mud

A party / .io style game of running around, tagging people from the opposing team to make them “stuck”, and rolling through your teammates’ legs to “unstick” them.

Granny’s Footsteps

Probably best as a hypercasual game with increasingly hard levels, this game simply involves trying to move up to the top of the screen as fast as you can, but making sure you hold completely still any time “granny” turns around. If she sees you move, you lose.

[thethirdkate]

Notebook Ideas #1: AnxietyWare

I’m going to kickstart this blog again by sketching out some of the ideas I’ve been noodling on and tracking in my notebook over the last couple of years. This will also push me to develop some of them further, from one line of text to something with a tangible design.

AnxietyWare

This is an idea I started prototyping in Godot engine last year. I didn’t get very far, and would still like to revisit the idea (in Unity). It felt like a good combination of fun and silly, but also personal and highlighting one aspect of my experiences with mental health. I also thought it could be a good structure for a side project, as I could easily increase or decrease the scope of how many minigames I would make.

The game is a touch-based selection of silly minigames, in the format of WarioWare, but where the games are all based on my personal recurring anxiety dreams. Examples in the sketches below:

[thethirdkate]

Prototypes from the archive

Just have a clear out and wanted to share a couple of old prototypes. I think this is my way of officially accepting that I’m not going to take these ones any further! But that’s fine..because something new is on the way ;)

This was a game about trying to get a word in edge ways.. the goal is to catapult your words (currently just a ball) through the gaps in conversation into the boring person’s face. It’s not a metaphor of subtlety.

This is maybe the first real attempt at prototyping in Unity, at least more than a year ago. Things have come a long way since! The idea evolved from being in a bar trying to get drinks to your friends without spilling them into giant-monster-destroys-town-(drunk?)

(Just discovering Tumblr’s file size limit on gif uploads.. booo...)

[thethirdkate]

Stump Trump is here!

- Download for Android

- Play in your (non-Chrome) browser

- Unity source on GitHub

Last weekend I took part in the XX+ Game Jam in London - Stump Trump is the result of 9 hours of work from the team. On this occasion, I took on coding as the jam was a bit short on devs!

Since the jam I made a couple of minor changes - one or two bug fixes and a couple of difficulty modes to choose from, but otherwise the game is pretty much as it was at the close of the jam.

There’s some flaws in the mechanics, but overall I’m really satisfied to have been able to put something like this out in such a short time! The main missing feature right now is that you can’t really lose :D

Built in Unity.

Team:

Harriet Quarless-Edge, Viki Walden, Tuesday Jones, Lydia Thomas and Kate Killick.

[thethirdkate]

Ink Stamp Game Prototype

My latest Unity prototype. The player controls a cube (currently WASD but later to add swipe controls for mobile) which has shapes on one or more sides. The player must roll onto an ink pad to pick up the colour of the ink, then stamp it (the correct way round, for non-symmetrical shapes) onto a target tile.

I thought of this mechanic out of the blue (a mix of games I’d been playing - Ink and Lara Croft on iOS, as well the classic Flash game Bloxorz). It started off sounding very simple, but building levels has proven difficult. As soon as the player has any space to manoeuvre, the difficulty curve jumps up - it quickly becomes too much effort to anticipate the cube’s movements (or maybe I’m just not great at visualising 3D space). Instead, I end up using trial and error to get into the right place, without really learning the method - if I restart the level, I wouldn’t remember how I got anywhere and would again be moving randomly.

The original idea was to start with very simple levels and build up complexity by adding:

- Shapes on more than one side of the cube

- Shapes that aren’t rotationally symmetrical and have to be fitted the right way up (e.g. the early levels only have circles, with arrows introduced later)

- Other types of tiles to experiment with (e.g. disappearing ink, moving tiles, tiles that can be activated/deactivated by changing colour, etc.)

But at the moment it seems like the difficulty jumps too sharply as soon as *anything* except basic movement is involved. I see two ways of doing this:

1. Restrict how the player can move. For example, don’t let the player pass a shape tile on the floor unless they are landing on it with the correct colour/shape. This would force the player to solve one part of the manoeuvring before they can move on, breaking the problem down.

2. Make manoeuvring less of a focus. For example, every side of the cube could be a circle (but the ink tile can only be used once). Or the same thing in reverse - the whole cube changes colour when you land on an ink tile (but only one side has the shape on).

At the same time, experimenting with this more and learning the “tricks” of moving around with this mechanic myself is the only way I’ll be able to figure out how to 1) build levels around them and 2) teach them to the player.

A couple more levels -

And a still shot of the last level -

[thethirdkate]

5 tips for user testing with young children

A few weeks ago, I had the pleasure/terrifying prospect of user testing an early prototype with a room full of 3-4 year olds. It wasn’t my first experience testing with kids - I’ve showcased games at events with many young players, done some ad-hoc feedback sessions and observed/assisted with an external testing agency, but it was the first time I’d be fully responsible for planning and execution.

As we needed feedback on a rough prototype, I decided to run all the tests as one-to-one sessions rather than in groups, so that we could observe their behaviour closely.

Here’s a rundown of five things I’ve learned so far:

Patience, patience

This has to be top of the list. You can’t rush children to complete a task or answer a difficult question, so you’ll need to anticipate the extra time it takes them to formulate their thoughts. For this reason, it’s important not to try to cram too much into the session and stay focussed on one or two main goals for the test.

There may be more long pauses than you’re used to as well, so try to not to jump in prematurely or repeat questions, especially for a tester who’s already feeling under pressure. I try to reassure them that they can’t do anything wrong, and praise them for doing well even when they don’t know the answer. I find a good way to move them on is to change the subject and ask, “can I show you something else cool/secret?” (which also works well if they got distracted by something off-topic).

Asking the right question just got harder

I’m sure I don’t need to say that asking leading questions in user testing = bad practice. Unfortunately, young children struggle more with very open ended questions, so you’ll need to develop some other tactics for eliciting answers. It’s an art I will readily admit I have not yet mastered. Prompting them with a few options works better than asking a broad question, as does showing them something visual to choose between rather than asking them to remember something they saw earlier (having an extra device for this is handy).

I found the least successful questions were any that required them to imagine something new - for example, asking them what they think might be in a particular section of the app - as they tend to feel put on the spot.

Plan tasks and observations rather than questions

Because I had needed something quite specific from my testing session, I spent considerable time planning how to run it, including what questions to ask. In some respects it was useful, but afterwards I considered whether being too specific in the planning was actually something of a distraction. Young testers get bored and intimidated by too many questions, and it’s hard to predict which will get answers from each kid - it requires a lot of improv.

So, I think planning has to centre on observation, and notes should serve to keep you focused on the one or two main priorities - for example, have a short list of behaviours to look out for, and save questions for the really important things.

Don’t let it become a chore

In my research beforehand, I read various bits of advice on how important it is to build up rapport with young testers. I agree that it helps to do what you can to set the tone and make them feel comfortable, but I also found that once you’ve lost their attention, it’s really hard to get it back, even if you take a break and spend time playing with them. In future, I’d look to do three things:

Make everything as much of a game as possible

Make the tasks as varied as possible (for example, getting feedback through activities other than using the actual app/device)

Identify when a tester is becoming disengaged and cut down the tasks to the one or two that are highest priority

Parents can help and hinder

Parents can undoubtedly be a great help in user testing with children, putting them at ease, helping bridge the communication gap and giving their own highly valuable feedback. They can also be a hindrance, particularly if they are under the impression that the child needs to perform well at tasks in order for the session to be useful. Parents who are overly keen may start prompting or pressuring the child, for example, or telling them off if they get distracted. I think it’s therefore worth briefing parents beforehand, even in an informal setting, so they understand what level of involvement you’d like from them.

That’s it for now - I’m sure I will have plenty more to share in the future, so watch this space!

[thethirdkate]

A method for less easy case studies

I’ve been thinking about UX portfolios again lately. It’s something of an obsession. I have a conflict between the appeal of a minimalist showcase where visual design speaks for itself, and the written case studies that I’m increasingly convinced are necessary to cover my UX work (and I just can’t satisfy myself with splitting it into multiple portfolios).

Mainly though, the problem is that writing case studies is hard.

Because in reality, working on UX at a startup means you don’t end up with neat narratives - “we implemented x to achieve y and the result was z.” There’s no beautifully constructed presentations for clients, little thorough documentation and often there’s not even the time or resources to iterate and test as much as you’d like.

None of this is inherently a bad thing. I’m in favour of doing the least amount that’s needed to communicate an idea, whether that means a scruffy wireframe, polished concept or a functioning prototype. That is, it’s not a bad thing..until you need to build a portfolio out of it.

So my obsessive question is this: how can I create a portfolio out of these scraps that tells a story - the right story - in an engaging way? How do I keep it concise and engaging without underselling the thought process that went into it? And how do I communicate its purpose when the reader has little or no wider context?

I don’t know, yet. But I have a hypothesis.

Maybe the things that matter are precisely the things that didn’t progress the story.

Last time I tried to write case studies, I wanted to show that my work got results. I started out with this skeleton:

Why were we doing this project?

What did we want to achieve?

How did I go about it?

What was the result?

And it kind of worked…except it was boring. And I had this nagging feeling that it only told a fraction of the story.

We have a tendency to rejig the stories we tell ourselves in a way that shows clearly how A led to B led to C. We dismiss routes that turned out to be dead ends and emphasise the parts that reinforce our story of success.

The problem is, any story can be made to fit this narrative.

Take the example, “We chose the left path home because it was the shortest.” Make sense, right? What about,”We chose the middle path because it was the least muddy” or “We chose the right path because it was scenic.” Each statement makes sense - they are equally reasonable sounding, despite having completely different outcomes.

In other words, if you only give the reason you took one path, it’s as good as giving no reason at all.

Anything can be made to “make sense” if that’s how you choose to present it. And fortunately for writer, our brains are very adept at jumping to conclusions without worrying too much about whether we really have enough information. In Thinking, Fast & Slow, Daniel Kahnemen calls this What You See Is All There Is (WYSIATI):

“[WYSIATI] explains... how we are able to make sense of partial information in a complex world.”

This covers a whole range of biases that help us to jump to conclusions faster than we would if the more analytical side of our brain was to get involved. For example, overconfidence...

"The confidence that individuals have in their beliefs depends mostly on the quality of the story they can tell about what they see, even if they see little.”

…as well as the framing effect, which is obvious in the example of the path home.

So on the one hand, a case study in which you omit anything that makes the story less linear will probably be quite persuasive. On the other hand, this isn’t the level of reasoning I want to settle for, either in how I approach UX or in how I present it. I don’t want to settle for cognitive ease, i.e. using the least mental effort and accepting a conclusion based on biases.

This leads me to my current hypothesis: the best way to write a UX case study that is both concise and meaningful is to focus almost exclusively on how you decided that one path was better than another. This might mean omitting any detail of the process that doesn’t directly relate to how options were compared - and maybe ignoring “results” altogether.

We still need to maintain some form of a narrative - hoping readers will stay engaged through chunks of analysis is undoubtedly too big of an ask. What will it look like? I don’t know yet. Maybe the result won’t even look that different to an average case study. The only when I’ll find out is to start writing them...

[thethirdkate]

A breakup letter

OH,

It’s over. I know I said this before, but I mean it this time.

I wanted to make this relationship work, I really did. But a relationship shouldn’t be this much hard work, and I can’t always be the one putting in the effort.

It was always going to be hard with you being in the shadow of your predecessor, my first love. I never wanted to compare the two of you - that would be unfair. But I just couldn’t help it. I guess some part of me hoped you might recapture even a fraction of that passion… but it turns out you’re a poor imitation.

You’re just not an original. That’s not an insult, it’s a fact - it’s just who you are, and I knew that when we met. I tried to come in with an open mind, but how could I when you insisted on reminding me at every turn?

“Oh, you like boats? I have boats. You want block puzzles? I have hundreds!!”

You kept trying to give me these things you thought I wanted, but you never understood why. You were like a parrot who doesn’t know the meaning of what it says. You never really knew what made me happy.

Oh, you had some redeeming features. You were pretty, if not charming (you obviously spent a lot of time on your looks). You were there when I needed you, dependably picking up wherever we’d left off, and you put the effort into telling me stories. But it wasn’t enough.

I kept believing you could change. That I would discover more, another side of you. Just give it one more day, I’d think. When you took me up staircases that didn’t go anywhere, I kept going. When I had to self destruct because I got stuck on one of your block puzzles, I took a deep breath and ploughed on (what would have happened if I’d had no bombs? Would you just have left me there?). Even when you got me lost, looping and backtracking on myself, weary and exasperated, I kept trying. I really wanted to like you.

At some point though, I have got to cut my losses.

Do you want to know the moment I realised? The exact point when I knew I’d had enough, that this relationship was toxic, unfixable? It was the honey pot. You and your bloody honey pot. I took that thing everywhere with me, traipsing around from island to island, trying to figure out what the fuck you wanted from me. Finally, I was on the right track until…I got attacked and had to put it down.

And you wouldn’t let me pick it up again.

PICK IT UP, I screamed. JUST PICK THE BLOODY THING UP!

But you wouldn’t let me. I came at it from every angle, desperately tapping the action button, tears of frustration obscuring the screen, but you just kept reading out the sign it was in front of, again and again… There it was, literally the sign I needed, showing me the way. “It’s over guys,” it read. “Time to move on.”

It was so typical of you, I thought to myself. Always getting things slightly wrong. I know you can’t be perfect - I don’t expect you to be - but it’s like you don’t even know what’s important to me.

So, Oceanhorn, this is where I leave you. I hope I don’t sound too bitter - I’m not. I learned a valuable lesson. I’d like to think you did too, but I can’t be sure. Maybe our paths will cross again - I doubt it somehow, though. I’m sure you’ll find a better match. A younger player perhaps, who doesn’t come with the emotional baggage of a Zelda fan.

In the mean time, I think we should keep our distance. We both have some soul searching to do.

[thethirdkate]

“Delighting users”

I’ve read a few blog posts lately about delight, and people getting generally tired of “delighting users” as an overused phrase. It’s easy to agree - when words get adopted in this way they tend to lose their meaning. But does that mean it has no value? I’d like to make a short argument why we shouldn’t entirely begrudge the idea of delight.

As product designers, we’re often concerned with analytics, testing, performance, bug fixing - it’s easy to get lost in process, and often our final offering doesn’t resemble much of the designer’s vision, but is determined by a bunch of different influences. Our creations don’t reflect us, and because of this, they lose their sense of human-ness, and that’s exactly what I think delight brings back. 

Delight is a little piece of the designer’s personality. It’s the moment at which a user understands that a product was made by another person - a person thinking about them. It’s a connection that reminds them that they are human, and that you the designer are too. It can be depressingly easy to forget that, especially here in London, packed into the tube like sardines, feeling like a drone - a moment of delight in your product is like the moment that a stranger smiles at you on the tube. Although we look like a miserable bunch, pushing and shoving and shutting ourselves away reading the Metro or playing Candy Crush, if you scratch the surface just a little you find that underneath, we all share something - a sense of humour, a desire to play, a delight in seeing the absurd in the everyday.

We spend a lot of our time engaging in faceless interaction. We consume constantly, are bombarded by advertising, we spend our time engaged with computers, with apps, with self-service checkouts. Without any delight, these experiences - experiences that now define a huge portion of our lives - feel soulless.

So, yes, “delighting the user” may be a clumsy way to put it. It’s been misused and overused to the point of ridicule. But if you take the perspective that it’s a way to make products more human, to share some humour and some personality, then I think it’s still a valuable concept for digital designers.

[thethirdkate]

An update on the maze tile game - you can now also use the arrow keys to move your player along the path.

[thethirdkate]

Ghost Player / Time Machine Prototype

Another prototype! I’m definitely getting into Unity..

http://www.katekillick.com/prototypes/TimeMachine.html

So, this one came from some ideas about a time machine platformer.

How to play:

- Move the player around with the arrow keys, using up to jump

- After doing a few movements, press space

- This will create a ghost who will replay the movements you just made (you won’t be able to move during this playback)

- When the ghost has finished moving, press space - you can now once again move the player cube

- Repeat ad infinitum (ok, not quite - up to 99 ghosts)

How could we design puzzles around this mechanic? (The possibilities vary depending on how you treat the clones, too - should they be affected by gravity? Interact with the player/each other? What about if they could push levers?)

[thethirdkate]

Game Dev Story / management sims (part 2)

I’ve been thinking about making a tycoon/business management sim game.

Why? Well, because I enjoy them. That’s it.

I especially enjoyed Game Dev Story by Kairosoft. I started doing a bit of reading around how one would approach designing such a game. It’s not so easy to find out about - for a start, “business / management sim” often leads to results about serious business training games, “sim games” can be anything from Surgeon Simulator to Flight Simulator, and “tycoon games” tends to refer to more complex games with big economies. I’m not interested in making compulsive freemium games right now, either.

So, after about 10 minutes of reading about models for virtual economies, I decided to instead take a look at Game Dev Story and break it down a bit.

Why do I like it so much? Let’s see...mainly because it’s a simple game. More specifically:

You don’t have to manage space or physical objects

This is, I believe, quite unusual in this style of game. Most of them have some elements of construction (in freemium, usually to make you pay not to wait for it to be completed). And in games that do use it, I often find the relationship between the positioning of objects to be a bit abstract - either inconsequential (and therefore, a distraction) or too ambiguous and requiring a frustrating amount of trial and error. Either way, I personally don’t find it appealing in a business/management sim (on mobile, at least).

Secondly, there are clear phases of gameplay, with a clear indication of what to do in each

Game Dev Story is made up of a very simple loop:

This lets the player understand what they should aim for in each phase. For example, the travelling salesman only visits periodically - the rest of the time, you don’t need to worry about purchasing items. You are only asked at the appropriate time to select a staff member to work on something. In short, you are only concentrating on one choice at a time - and the consequences of your choice are, in most cases, fairly immediate and fairly linear.

So, after a few rounds, you can draw up a mental model of how resources are moving around:

Of course, this level of simplicity does have a limit of how long it will keep your interest. Although investing in new consoles - unlocked every few cycles - allows you to spend more money for higher returns, it does, inevitably, start to feel like churn. (I think this could be improved if these larger investments also proved more risky - but normally by this time in the game, your staff have high enough skills to guarantee successful sales).

It’s not an advanced strategy game, for sure. But it’s quite entertaining - for a while.

At first, I was thinking about how to apply a similar model to a few different ideas, but I also think there are some places for improvement, and perhaps that’s a better starting point.

Mainly, the game does not require you as the player to improve your skills as you go on - it gets easier, not harder to make money, and while that may be a realistic business model, it’s a limiting style of gameplay. So, how could we add a difficulty curve to this kind of game? A few ideas:

Build in complexity as the player progresses

If every cycle adds one more layer of (interesting) complexity, the player has to learn to juggle more and more factors - but only once they’ve seen the clear cause and effect from the previous ones. If you also set up a fail condition (I think you can go bankrupt in Game Dev Story), then the player will want to replay just to discover what the next unlockable feature would be.

Allow the player to take bigger risks

Game Dev Story almost does this with higher value games as you go on, but it’s too easy to make back your money. Adding less-certain investment opportunities would give the player 2 possible strategies - slow/safe or risky/big reward.

Include phases where other (non-managerial skills) are required

e.g. mixing in a phase with a mini-game. Perhaps you have to do some manual labour yourself, arcade-style, or solve some puzzles. It definitely has the potential to feel shoehorned in, but if it fitted the context and narrative of the game well, I think this could work.

There’s more to investigate here..