This is the second Postmortem article I'm dedicating to the development of The Line. Click here if you want to read the previous one.

Where was I? Oh! Right… well…

Which idea won?

If you read my last entry, you probably know about the three game-ideas I had for the jam project: a match-3 type, an action-platformer (a la Chu-Chu Rocket) and a puzzle-platformer.

And if you thought the idea I came with was the puzzle-platformer one… you're wrong. 

My initial choice was the Match-3 concept. Basically, I had my reasons:

• I honestly thought it could be easier to build.
• On paper (or in my head) the idea of having Match-3 elements in 1 to 3 lanes without a grid could be something interesting.
• The other ideas (the puzzle-platformer and the action-platformer) were intriguing, but maybe overused.

That's why I opened the engine and created a new project with the idea of replicate a Match-3 game and iterate from there… 

But, while I was doing tests, this happened:

And, suddenly, everything changed.

I'm not going to lie: it is unclear to me why this happened. Maybe I was applying the platformer behaviour before placing the characters in a column. Perhaps I tried to make the characters move and be affected by gravity. 

The case is: with my input, all characters moved at once. And it was chaotic. But, most of all, it was FUN.

That's when I decided to go 100% for the puzzle platformer.

Building a prototype

After that revelation, and knowing what to do, it was time to create something playable. To achieve that, I would need to answer some questions:

Rules?

What would make the game fun? Or a challenge? And, more important, what makes this game unique? Let's remember the initial idea:

I had the basic rules in that post-it:

• To win the game, you must guide the characters to a goal.
• The characters must avoid some obstacles in their way.
• The characters will be an entire line full of people.

Easy. Now I would need to know more about the context. Fortunately, I had a place in my board with that:

My initial idea was to introduce all these public places. But after a moment of reflection, I realised I needed to choose just one ambiance (for the sake of the artists… that was me, BTW) That's why I choose the grocery store as the main ambiance for the game.

But I was open to new places in the future, but we will talk about that later.

Characters? Control? Camera?

The basics in Game Design. I'll go fast on those, since I have them super clear since the beginning.

The NPCs turned… PCs(?)

The idea was to control an entire group of people at the same time. Implementing that was super easy, but soon I realised that the action wasn't as fun as I imaged because of one thing: they have the same skills. 

That means: they run at the same speed, jump at the same height and fall with the same weight and the rest of attributes. In other words, they act the same. And that was BORING.

Do you see what I'm saying?

So… I tried to spice the things up…

And this was the result:

There was a difference, huh? Moreover, that was the moment when I realised it could be some characters that were exceptionally faster or more agile than others. And the idea of having a super-granny was very funny in my head. 

You see the characters well-defined here, like in the last build made for the game jam, BUT let's see how they looked at the time I was working on their movements:

Those are the placeholders I had for my characters: normal state, death state and frozen state. Cute, right?

What about controls? And camera?

Exploring the mechanics I wanted to implement, I become with this baseline:

• Basic movement actions for platforming (move left, move right, jump)
• The jumping mechanic will be enough to sort platforms.
• They could be obstacles harder to avoid.
• Some items in the stage will help on avoiding / neutralizing those obstacles.

My main inspiration? 1994's Donkey Kong for the Game Boy.

That settled the controls and the camera perspective, as I wanted to keep a classic approach to the platforming genre.

One question left: Should I keep the stages in a fixed camera frame, or should I make them bigger? My idea was to start with “smaller” levels in the same frame and move on to bigger levels. But I scrapped that idea due to two reasons:

1. Time constrains.
2. The screen format. (16:9 instead of 4:3)

As the idea was to play on a Full HD standard screen, I had more space for the levels as initially thought. That doesn't change the fact that, as the project evolved, they were some level ideas I had to scrap due to not having enough space… but I believed I had enough as a start.

Comparing with my source of inspiration, they are a few things I had to consider:

• Character's speed. In Donkey Kong, Mario is particularly slow. My characters don't. That will affect the game pacing.
• Moving obstacles. I didn't consider having moving obstacles or enemies in my game (not enough time for that) so I'd need to think how to make it funny with fixed obstacles.
• Panoramic screen vs squared screen. That impacts directly on the levels' layout. There's more space in my game, but also I have more controllable characters on screen (remember, the line…)

After all those considerations, I established the following:

• A classic platformer controls layout (ADW or directions in keyboard / direction pad + A in game pad to move left, right + jump)
• A multiview 2D side camera.
• The levels will be cage inside the camera frame.

The goal and the obstacles

Trying to get into a playable prototype as soon as possible. I needed a goal:

At that moment, I haven't decided where I was going to place the game already, so I drew a classic goal(?)

Thinking about the obstacles that I could put into the levels, that's when I really decided to go with the supermarket ambiance.

Those were the “superfast doodles” version of the two blockers I wanted to implement: a wet floor and a special sale stand.

FUN FACT: I wrote all the game code in English to follow a standard, BUT I keep the Spanish project name for the wet floor obstacle. Fregao sounds catchier. So, if one day you can check the source code, you will see things like “if NPC collides with fregao, then the NPC is destroyed”.

The wet floor and the sale stand worked the same way:

• If any character collides with those obstacles, the character will “die” or “freeze” (two different states, but with the same meaning: they're out of the game)
• Those obstacles can be avoided using one item. That item will spawn inside the stage. The character with that item in their inventory is immune to the obstacles of the same kind.
• Those obstacles can be deactivated using one item. That item will spawn inside the stage. The character with that item in their inventory, if it interacts with the obstacle, will destroy the obstacle, and it will not be affecting the playable characters any more.

Those were the items that could be used against the wet floor:

Water boots. The character who wears them can walk through the wet floor without getting hurt.

A wipe cleaner. The character who has this item in their inventory can use it to “clean” a wet floor. That specific obstacle will no longer affect other characters.

Same principle, but this time against the sale stand:

A coupon. The character who has this item in their inventory can walk through the sale stand without being impacted. Unlike the water boots, the coupon was for one use only.

A hammer (yes, I know what I did). The character who has this item can “destroy” the sale stand, and it will no longer affect others.

Due to time constrains, I couldn't implement the sale stand properly. Furthermore, I felt that the blocker was too similar to the wet floor. That's why I decided to focus my energy on the wet floor entirely, and explore the game around that.

Some troubles and implementations later…

That was the first proof of concept I could compile to test before deciding to go ahead.

After deciding what to do with the characters, the goal and the obstacles. I finally had a solid baseline from I could build my game on.

I had to figure out one more thing before moving on:

What about the win conditions?

That's a good one: Should the player safe ALL the characters? Should I have a fixed number of people to safe as minimum? I explore around this, and I come by with the answer: Let ME decide how many, depending on the level layout.

Why?

• That way, I can balance the level's difficulty.

And more important:

• If I established a minimum number of people to safe, players will know they can pass the level with a few casualties… buy they will feel challenged to complete the level WITHOUT leaving anyone behind.

Following this train of thought, I implemented a system that allowed to set at any level:

• The number of characters of the line.
• The MINIMUM number of characters you need to save.

This decision gave me a lot of liberty when the time for designing the levels came.

…and the prototype is up and running!

After some implementation, a rough layer of paint and a few hours of development… that was how the game looked. That was 3–4 days after the game jam started.

What's next?

In the next (and last) postmortem article, I will talk about creating the levels, polishing, and the learnings I'm gathering from the whole experience.

I hope you can find those useful for your projects. I can tell you I've learnt a lot from this project.

Before I go, allow me to share another fun fact: I was mapping the controls to the game pad and I realised I had all the buttons with function except one: The B button…

And I couldn't resist.

This is what happen if you push the B button (keyboard or game pad) during the game.

And why are the characters numbered? I'll tell you next time. :)