Media Release: Run, Darling, run! – ‘Codename Darling’ update released for Windows, Mac, web and Android

Media Release: Run, Darling, run! – ‘Codename Darling’ update released for Windows, Mac, web and Android

An infinite neon noir platformer about the mysterious Codename Darling escaping Neon City

In this infinite, atmospheric platformer set in an alien jellyfish invasion, the player takes on the role of Codename Darling, navigating the perilous rooftops of Neon City. How far can you run?

To stay alive in this endless game, the player needs to time their jumps and double-jumps with increasing precision. A single lapse in judgment can send Codename Darling plummeting to their death, resetting the score.

The first version of the game was made overnight during Pocket Jam #5, September 14th – 15th 2020, in just under thirty hours. Pocket Jam #5 ran in conjunction with the Pocket Gamer Connects Helsinki conference 2020, and the game was awarded joint second place in the jam’s competition by the PGConnects judges.

The game’s aesthetic is inspired by film noir, as well as superhero cartoons and comics. The character animations were hand-drawn frame-by-frame by Lassheikki, and part of Neon city’s soundscape are field recordings by sound designer Rintanen. Krechmer’s layered and driving music pairs with the monochrome environment to set the scene for the moody, 80’s inspired dystopian megacity.

The new post-jam update adds major quality of life improvements such as level selection, sound settings and a high score, as well as updates to sound, graphics and music. Some changes have also been made to the game’s design, adding a double jump mechanic for gameplay variety and softening the learning curve. For fans of the original version (which features an unforgiving difficulty curve) the jam version is still available as a download on

Codename Darling is available to play and download for free on The game was created using Unity, and is available to play in-browser on computers and touchscreen devices, and as downloads for Windows, Mac and Android.

Credits & team:

Codename Darling was made by Henri Sarasvirta (code, design, postprocessing & Unity), Christina “Chride” Lassheikki (graphics, animation, VO), Simo Rintanen (sound design) and Leo Krechmer (music, sound design, additional graphis). Sarasvirta, Lassheikki and Krechmer have collaborated presviously on the Pocket Jam #4 winning game Mochabot Organic.

Pocket Jam #5 was arranged from September 14th to September 15th, 2020 as part of Pocket Gamer Connects (PGConnects) Helsinki 2020 by the Finnish Game Jam association. The jam’s submissions can be found at:

Contact – email:

classheikki [at]

Play and download ‘Codename Darling’ at:

Media images:

App Icon
Full logo
Promotional image


New article out – ‘Designing Games as Playable Concepts’ in DiGRA 2020 Proceedings

Designing Games as Playable Concepts: Five Design Values for Tiny Embedded Educational Games – article out in the DiGRA 2020 Proceedings

Hello everyone!

Currently I work as a research assistant in the Aalto Online Learning-funded Department of Media pilot project Playable Concepts under the supervision of games scholar doctor Annakaisa Kultima. During the spring, our team also included Solip Park (now doctoral student at Department of Media) and Tomi Kauppinen from Aalto Online Learning and the Department of Computer Science, with some additional support from programmer Teemu Kokkonen and game designer Noora Heiskanen. Our aim is to explore how tiny, embedded and partial games communicate – if they do – and how to teach new game makers to adopt games as a communication tool!

To further explain the framework, we wrote an article, and it’s now available in the DiGRA library (free for personal and classroom use!):

Designing Games as Playable Concepts: Five Design Values for Tiny Embedded Educational Games. 2020. By: Annakaisa Kultima, Christina Lassheikki, Solip Park, and Tomi Kauppinen.

Click to Access PDF in the DiGRA library.


Digital games transform our lives; they provide an opportunity to engage with other worlds in a playful way, in many ways similarly to what other forms of audio-visual communication (like movies, paintings or photos) have offered for a longer time. However, learning materials still use rather traditional ways for accompanying media, ranging from static figures and graphs to videos and animations. In this paper, we explore the notion of Playable Concepts: tiny games that are embedded as part of educational material instead of separate and standalone products. We argue that games could be in a similar role as static graphical elements in educational and communicational material, embedded in the text, together with other media formats. We suggest that the design space of Playable Concepts can be framed with five distinct design values: Value of Partiality, Value of Embeddedness, Value of Simplicity and Immediacy, and Value of Reusability.

Playable Concepts is a pretty exciting project in the field of game development education and educational games. In addition to the research, so far we’ve created a library of 12 moddable playables and a graphics and sound asset library for people to use that is CC-by-3.0, and written tutorials.

We’ve also organized a handful of workshops on the basics of game making for different audiences, including the Academic Mindtrek 2020 conference audience, the Turku Edu Game Jam for high school students, Aalto games students, and Aalto staff and educators in the A!OLE community. The global pandemic forced our concepts to become fully online, and so some of our workshops were carried out over Zoom.

PlayCo Workshop at Academic Mindtrek – Tampere, January 2020
PlayCo Workshop over Zoom – Topical content for March 2020
Asset library – CC-By-3.0 Licensed pixel art assets for games by yours truly

During the academic year 2020-2021, we’re further improving our learning resources, and looking further into science dissemination through games – How could researchers use playables as figures to help explain and illustrate complex concepts?

Take a look at the paper if you’re curious about our design framework, or head over to our Playable Concepts platform to start learning how to make your own playable concepts using Construct 3!

Tips for solodev game jamming

This post was written following my first solodev game jam experience, and originally published on the community March 30, 2020.

Are you considering flying solo for your next game jam, but you’re feeling a little nervous? Perhaps you aren’t that experienced a coder, or you’re just wondering what it’s like compared to working with a team?

I’m a narrative designer and game artist who’s all about game jams, clocking in at around 20 over the past five years. I’ve taught game development through jamming, and even wrote my MA thesis on game jams and learning. (You can download it over at ResearchGate if you’re curious about my findings)

Over the past week I tried my hand at solodeving a game for the first time for a game jam! The result is Grumpy Librarian, a visual novel / game made in Ren’Py. You can check it out and play it over here if you’re curious: 
It was made for the Aalto University Games Now! Online Jam 1, and this was also my first time doing a fully-online jam.

So what did I learn from jamming alone, and what are my tips to you? 

Let’s get to it – Solodev game jamming vs. team game jamming:

A note: This is not an exhaustive list, and in no way a guarantee that the game you make turns out good. But these are things I’ve found helpful. Take them with a grain of salt, or a slice of lemon if that’s your preference.

1. It is definitely possible, but you’ll have to make sacrifices

Let’s start off this list by saying; YES, you can do it, and NO, it doesn’t have to be the hardest thing you’ve ever done in game development. A solodev game jam can be super fun, and my Friday was mostly spent cackling at the project I was working on.
Making a game by yourself is also a very good exercise for any aspiring developer, since it makes it clear just how much work goes into creating a full game and how much expertise each role in game dev requires to achieve professional results. I definitely recommend it to anyone aspiring for a directorial role or designer role, since it shows you just how you deal with the responsibility of a full game experience.

One of the sacrifices you are making in taking on this extreme generalist role of solo developer is that your core skill probably won’t get to shine. Most people find it at least somewhat difficult to switch between tasks and different mindsets. For me, the experience made me more empathetic to how my demands as an artist or narrative designer might look to other disciplines.

Then again, when we’re talking game jams, we’re not talking professional results to begin with. I wouldn’t based on this jam game apply for audio positions at game companies, and I’m doubtful whether or not the game I created works as a portfolio piece in any of my core disciplines, even. Considering the time I had to create character art, it’s pretty amazing, yet on an objective level I can tell it isn’t up to snuff. Same goes for dialogue. And, of course, code, which leads me to…  

2. You don’t have to be a coder, but it helps, kind of?

 I am not a coder, but… // I am not a game programmer, but… // I am not a computer scientist, but…

These are all ways in which I’ve started sentences while teaching game development, because, even though I am not trained as a programmer, through game jamming and narrative design I’ve gotten proficient enough with code and scripting that I can read code. Not with ease – it’s kind of similar to trying to understand the meaning in a poorly translated Facebook post.

So, here are some of my strategies for coping with coding at a game jam as a non-coder:

1. Don’t panic – You can always ask for help, if you need it. I recommend having a person in mind to turn to if you run into big issues. It helped me not panic, and in the end, I didn’t need their help.

2. Focus on your strengths – be it art, sound, design, music, or writing. Make a game that emphasizes the things you are good at. You don’t have to prove your worth as a coder, so don’t. Is there a tool you already know? Use that, if you don’t explicitly want to learn a new one. Embrace the spaghetti code; embrace the bugs; embrace that the game has simple mechanics.

3. Start by modding a tutorial project – You have limited time at a jam, but I would still encourage you to start from an official tutorial project and modding it into your own thing. Learning the most basic ropes of your engine will save you time in the end, and the engines I’ve used so far have pretty good tutorial projects offered to get you started (Good examples: Unity, Unreal Engine, Construct 3, Ren’Py. Not so much: Godot, Twine)

4. Start by reading relevant documentation, and then look for examples on forums of how it’s used. This one I’ve learnt the hard way. For example, I spent over an hour fixing a splash screen issue for Grumpy Librarian because I tried to figure this out from forum posts and source code alone. I even looked at the game on different browsers to figure out where the splash screen was coming from. It turned out the solution was well-documented in the official Ren’Py documentation, and took all of ten seconds to implement through simply placing the splash screen in the correct folder.  Similarly, I spent a silly amount of time trying to adjust the volume of the music from looking only at the documentation, not understanding that the issue was about syntax.

5. In general, when switching between languages, syntax will be your biggest source of frustration. To be honest, my coding is at the level of “I guess I could make this well, but maybe I can get this done with simple if/else logic and for and while-loops?”. Again, I am not a coder, and you, an experienced programmer, are allowed to frown at me. The good part about that, however, is that most languages support all structures I can come up with. When switching engines, I don’t have to learn everything anew, and I don’t have to learn the engine fully to get started. You, an experienced programmer, are allowed to cringe at that statement. What will however frustrate you for the first few hours is syntax. I chose Ren’Py for this jam, something I had never used before, and compared to Twine, it is much, much stricter with indentation. It took me a while to understand why I couldn’t use ‘&&’ in my conditional logic statements (and I sighed so hard when I found out you simply use the word ‘and’ in python). My first two hours were spent screaming at error messages I didn’t understand. And that leads us to…

6. Error messages could be much, much easier to understand. You have my sympathy. This is true for any engine I’ve used. Ironically, the ‘easier-to-use’ engines and tools don’t necessarily have easy to understand error messages. The best strategy is therefore usually to Google the error message, but here the size, and activity, of the development community online matters. Depending on what you are working with, there is or isn’t a community of newbies like you who are asking the most basic questions. For Unity, there’s a lot of complete beginners asking silly questions about the first steps, so you’ll find answers easily, even if the engine itself isn’t the most beginner-friendly.

3. Deadlines and rules are arbitrary*

Look, you should aim to make the game happen in the time assigned for the jam, but more than that, you should simply finish your game, even if you run out jam time. Jake Parker, comics artist and the founder of Inktober, has two mantras that I strongly stand by (despite no longer standing by Parker): firstly, Finished, not perfect, and secondly, You need a product, not a project. This sentiment of finishing things being the ultimate teacher is also a rule in the game industry: Just Ship It.

Controversial opinion? Well, I’ve never been that respectful of game jam deadlines or design constraints, which comes from being a member of the fairly non-competitive Finnish game jam community. It’s all about fun, learning and building networks, less so than winning competitions. Think of it as a NaNoWriMo sort of challenge: everybody wins by participating, finishing something teaches you more than abandoning the project, and you are competing only against yourself. This strategy is actually the same for me as a solodev as in a team.

My strategy goes something along these lines:

1. Scope the game to fit the time-frame of the jam. This usually means a game that plays in 10 – 15 minutes, single-location, few characters and one game loop.

2. Realize I won’t be able to finish the game during the jam, because I got distracted from the initial design.In the case of Grumpy Librarian, distraction was making art for 7 characters.

3. Get the game ready enough during the jam, so that I want to finish it in the following two-three days, when I still feel motivated.

It usually helps if what I leave for after the jam is easy to do and fun. If you leave gaping holes in your game design, or big scary bugs in the code you won’t want to go back. But, if you just don’t put in the animations, or need to add some writing to a specific scene, that’s much more fun to do. After the jam, I (or team mates) usually only want to make changes that are direct and fast improvements and polish to the game. Which brings us to motivation in general…

4. Task lists help you keep up the motivation

From what I’ve talked to other developers, staying motivated during your solodev jam is harder than if you have a team cheering you on. I found it helpful to keep a task list. In the task list, I list out what needs to be done, but more importantly, every single thing I’ve already done. Seeing that row of green makes it so much easier to feel accomplished, and not feel like the list is endless.

Even if it’s just for myself, keeping a task list helps me focus. These kinds of lists are what I usually make if I am the producer at a game jam, and they give structure to what I’m doing.

Here’s my task list for Grumpy Librarian at the start of the jam:

Screenshot of partially filled in excel spreadsheet with columns for “What?”, “Status?”, and “Important?”. Categories I use are Art, Sound, Writing and Code. I divide art tasks by character assets, environment assets and graphic design / GUI.

Here’s my task list for Grumpy Librarian March 30th:

Screenshot of mostly filled in excel spreadsheet. Note the fleshed out character art list especially and red status of some essential code…

A few tips I’ve found good for your task list:

1. Let the list live. Some things will move about, some will be removed, some will be added.

2. Don’t mark things in red before you have green markings. Seeing the whole sheet in red is almost certainly guaranteed to make you feel demotivated.

3. Prioritize, but don’t get boggled down by what you’ve marked high priority. As you can see, one of the first things I marked OK was fonts. Why – the default font of Ren’Py isn’t that bad, is it? Well, it isn’t. But by switching the font I learned how to edit the GUI files, which was important. (Sidenote: Also, in a text-based game, typography is going to be visible on every single development screenshot...)

5. If no one is around to hear your terrible puns, does it make them less terrible?

Alright, here’s my last tip, and this one goes out to all of my game writer colleagues: it is funny, but not that funny. Practice a little self-restraint. Or then don’t. This is your chance to make a game that looks exactly like you want – in good and bad….

Hope you found my tips helpful!

Overall, I definitely recommend trying your hand at jamming alone. I still prefer working with a team, and in person, but if I can do this, so can you 🙂

Do you have any tips & experiences of your own? Questions?