Half-Line Miami: a videogame mashup between HalfLife 2 and Hotline Miami – written in C++ for a programming course. Published in Itch.IO, with >55.000 downloads and intentional press coverage.
Download Half-Line Miami on Itch.IO
“Grab it—trust me, it’s worth your time”
– PC GAMER
“What’s better than a pixelated, top-down gorefest set to frenetic synth music? A pixelated, top-down gorefest set to frenetic synth music with a gravity gun.”
– ENGAGET
“a nice playspace to inhabit on your Friday night.”
– ROCKPAPERSHOTGUN
“I just got done trying to beat a level by bludgeoning everyone to death with a medkit because, you know, irony.”
– KOTAKU
A LITTLE INTRODUCTION
Half-Line Miami is a project that grew out of an earlier project, super hotline (hotline miami / superhot mashup). This is not the super hotline that was released on itch.io, this was merely a cosmic coincidence.
After super hotline becoming and incredible mess (it was my first pure C++ game project after all), I decided to take all my acquired knowledge and start Half-Line Miami.
In this article I will describe some of the challenges I faced and how I solved them.
① LEVEL ARCHITECTURE
Before HLM (I will be abbreviating from this point on) I hadn’t gone past small demos with basically one level. The idea of level architecture, recurring assets and persistence were completely foreign to me.
I wanted a system that read level completely from file, and required no additional coding.
The system that I came up with reads all the objects data from a file, such as props and their transformations, enemies, spawn and end points.
the level background is essentially one big .png
In the level browser, the class reads all the entries from /Levels/, and extracts the right data to be used, such as titles and thumbnails.
The system ended up being more convoluted than intended, but not bad for a first try.
② AI
The AI in HLM is very basic, but totally suits the gameplay. I needed something that was challenging, but easy to understand, so that players could predict the behavior of the enemies.
I don’t use any pathfinding for this, instead, here’s what’s happening:
Each enemy keeps track of where the player is. If the player goes behind a wall, the enemy will just try to go there, and see if the player is there. If he isn’t, he’ll just walk around.
If he is, then he will engage. He will shoot, maul, or throw a grenade. This makes the behavior of the enemies predictable, but challenging when faced head-on.
④ MAIN MENU
The main menu was a blast.
There is no real trick to it – just a bunch of matrices and sinusoids.
I used 2 sprites for the floating logo, one pink-purple one for the background, and a white bordered one for the foreground. Same with the menu options.
I couldn’t use any custom shaders, so the distorted background is done rendering the scene to a different texture, and then re-rendering that texture in distorted slices.
⑤ PAUSE MENU
I use this same trick for the pause menu in-game, together with some noise at the bottom and throughout the screen.
⑥ LEVEL EDITOR
With the level architecture of the game, making a level editor was a logical step. It wasn’t hard to do with polymorphism. The objects are kept in an array, and when an objects is added or removed, it’s added or removed from that array. This is saved to a text file, which is then loaded whenever a level is loaded.