How else Heart.Break() turns players into coders

Playing else Heart.Break() taught me basic coding practice.

It's set in a simulated city in which atoms are replaced with bits, meaning that everyday objects run on code, and can be manipulated through hacking. The player is cast as a young newcomer who has no experience of coding, but who soon slips into the city's underground world of hackers. Your avatar is moved through the world by simple point-and-click mechanisms, but hacking into objects requires players to type code with their keyboards.

I think the game could be used in schools to teach kids about programming. But creator Erik Svedang disagrees. He feels that else Heart.Break() contains too much partying, drugs, and booze to be appropriate for the classroom. I see what he's saying, but I'd still argue that it has the same qualities as a great educational game. In my experience it's the only piece of software to incorporate coding into its mechanics without making it feel like a chore.

How to make coding fun

Tweaking code to change the functions of objects is how else Heart.Break() began as an idea in Svedang's head. He had misread a description of Monolith's 2003 game Tron 2.0 , thinking that it had players tinkering with code to battle viruses inside a computer. (This isn't the case-- it's a first-person shooter .) Svedang was enamored with the concept of allowing players the freedom to use code to solve puzzles. He got the funding to work on else Heart.Break() from Nordic Game Program in 2010.

Svedang's game adheres to two tenets: appeal to the player's curiosity, and give them freedom to explore instead of forcing them into a rigid lesson structure. "I wanted to create a game that had a rhythm to it, and that let you live inside its world," he says. "So things are believable even if you don't progress."

To this end, else Heart.Break() has a simulated city that runs on a day-and-night schedule, with citizens going about their lives on their own accord. Svedang hides the story and the puzzles within this simulation, and teaches actual coding while you play. Unlike other recent games that incorporate programming principles such as Infinifactory and Machineers , you actually have to type things out manually with your physical keyboard.

"I'm trying to convey this magical view of programming. Especially those moments when you understand and can solve issues"

You start life as a soda salesman. It quickly gets dull. Then you see a hacker fiddling with a fuse box, only to be blown up in the process. It immediately implants the idea that hacking is exciting.

You become attached to an enigmatic woman called Pixie who shows you where all the cool parties are at. You enter her circle of friends. She stays up drinking and dancing with you. But she refuses to tell you is what her day job is. Of course, you eventually find out she's a hacker. And so Pixie acts as a conduit to suck you into the underground world of hacking. From there, you can consult a number of coding manuals found on floppy disks and get characters to give you tutorials on certain functions.

"To me, it wasn't interesting to just make a game where you solve programming puzzles; that's another reason why it's not an educational game," Svedang reasons. "I'm trying to convey this magical view of programming, especially those moments when you understand and can solve issues. And to get people into the mood to do that you, need to lure them in with a believable world. Then you can let them flip the world upside-down when they start hacking it."

How to make coding seem cool

Svedang initially lures you into this "magical" portrayal of coding through world design. The city of Dorisburg seems to be stuck in the mid-'80s. Data is transferred on floppy disks and computers take up whole rooms, being operated with huge red buttons and giant text-heavy monitors.

Svedang tells me that he chose this retro aesthetic as he thinks computers had a better look back then. "Nowadays, they're all just invisible," he sighs. He adds that he was inspired by "everything that makes computers seem cool." The eternal image of computer hacking was embedded in the public consciousness by Hollywood with the movie WarGames in the summer of 1983. We know that this kind of romantic, fetishized portrayal of coding is inaccurate, but it does have the effect of making hackers seem like wizards of the technological age.

Svedang draws from the same iconography as Hollywood to depict hacking in else Heart.Break . In fact, he goes beyond that, conveying it as something close to a religious act. Hacking in the game is done on "modifiers." When they're being used, a colorful halo appears around the hacker's head, as if they've achieved hacker sainthood.

Turning coding into intuitive and forgiving gameplay mechanics

While else Heart.Break() turns hacking into a form of ethereal magic, it also treats it as a science. As said, else Heart.Break incorporates actual coding into its challenges. There are 'if' and 'else' functions, looping is totally possible, and accurate syntax is vital if you want your code to work. This is the core of the game and where it all started.

"One of the first things I did was to design a programming language that I tried to make similar to what people might have experienced," Svedang said. His language is called Språk (literally "language" in Swedish) and is inspired mostly by BASIC, as that's what he learned to code with as a child.

Svedang's most challenging goal with Språk was to ensure that newcomers to coding wouldn't be intimidated by it. To this end, it contains a few subtle differences that make it less strict than other coding languages. For instance, while you can still use semi-colons to end lines of code, it's not a requirement in Språk. But that is not its most distinguishable feature.

"It's designed to give really good error messages that almost tell you what to do when you've made a mistake. So it's designed around usability more than anything else," Svedang says.

Svedang had to presume he's teaching his players how to code from scratch. That means there's a high risk of them getting bored and giving up if their initial experience is having a computer yelling at them. There needed to be some leeway so that there was room to experiment and, hopefully, deliver players that first thrill of executing code and getting it to work; a feeling that should be familiar to any coder.

That first-time excitement is what Svedang is relying on to keep players interested in pursuing the rest of the game's challenges. That's why it was so important that Språk be very flexible and forgiving. If you forget to type in a comma or quotation marks where they are needed, Språk will tell you. Or if you forget to hit Return (or Enter) when typing out code, meaning that two lines that should be separate are written as one, it will "try to be okay with that or give you a hint," to use Svedang's words. What this is really about is allowing players to fail.

"Sometimes you will fail to solve a problem," Svedang said. "And this is accepted in else Heart.Break() . If you fail, then something else will happen. And that path may be even more fun than if you had solved the problem."

Trying to break else Heart.Break()

Achieving the right balance with Språk required a great deal of playtesting with people both familiar and unfamiliar with code. But it hasn't been possible to catch everything. Svedang learned this when exhibiting else Heart.Break() at the A MAZE. festival in Berlin earlier this year. One player divided by zero to create an infinite amount of liquid inside a cup, and then had the character drink it. This caused the entire game to crash. "It was very smart," Svedang said with a big grin.

This incident is an example of the other big issue that Svedang had to be prepared for when giving players the freedom of writing original code inside a game world. Any self-respecting hacker, even a neophyte, will try to find ways to completely break the game.

Svedang tied to address this by restricting what assets players can hack inside the world, ensuring that buildings and bigger objects are static. This meant that its infrastructure would remain intact. Secondly, he limited the functions that are available to use on all the hackable objects. The modifier interface has a number of functions written out in its bottom panel: these are the only ones you can use. This has two benefits. Not only does this act as a reminder for new players of how to write those functions, but it also tells experienced coders the limits of what they can do with that object.

That said, there are some secrets hidden away inside else Heart.Break() for those who have both the curiosity and coding knowledge to tease them out. It's an acknowledgement by Svedang that the best students will eventually bend the rules and find their own way.