Cover photo by Wences Sanz on Unsplash

The Fall of game dev

This year I decided to participate in the event Devtober. Created by the french game developer Jonathan Rousseau and inspired by Inktober, it consists of choosing a project and committing to work on it every day during the month of October, documenting your progress on social media and ultimately writing a post mortem at the end of the month.

I make games for a living, working as a gameplay programmer on Dead Cells. Why add more game dev to my day then you ask? As any interviewee trying to gain some time to think would say, that's a good question.

Reasons

Like many people in this industry, I decided to work on games because I simply love the media. When I was a kid, I used to imagine the games I would make if I ever got to make games for a living. Except ever since I started working on games, I've always worked on someone else's project. And even if I'm quite satisfied with my career today, there is still this itch I feel the need to scratch now and again: make a game that I can call my own.

I could have done that many times. In fact, like so many people, I have a long list of projects: some ideas jolted down on a Google doc, two or three code files stashed on my hard drive, and even a complete demo. And I had time to work on them, either after work, on the weekends or during this long period of time where I was unemployed. But, and I know I'm not alone in this, I've never made it further than a demo. Because working on your personal projects is fucking hard.

Devtober is what behavioral economists call a commitment device. By declaring I'll be doing it and documenting it regularly, I'm trying to fight my laziness and to prevent myself from losing interest in my project, to accomplish what I never managed to do on my own: work regularly on a single project and try to bring it to completion. Basically, I'm making a promise to you that by the end of the month my game will have progressed to the next step.

There is another beneficial side to documenting my progress online: creating a presence. Making a game is only half of the trip, the next half consists of bringing it to players. Games are meant to be played, and social media provides a fantastic way of making your game known. Sure, you'll be drowned into a sea of other people trying to push their projects, but not showing what you do is the best way to keep it from finding its audience. By joining Devtober and documenting what I do every day, I hope to reach people who might be interested by what I do.

The game

Now it is time to talk about the game.  Nicknamed The Tower, it is an asynchronous cooperative game where players use limited resources to reach the top of a tower. It plays like a 2D side-scrolling platform game, where the player can run, jump and climb, with an added mechanic that changes everything: every time the player performs movement other than walking, their stamina will start to deplete. During their ascension, they will also be able to install equipment, such as ropes, pegs and bridges, making the climb easier. Fatally though, a time will come when their stamina will be depleted, and this is when the asynchronous cooperation will come into play.

When a player can't climb anymore, they have to set up camp. While camping, they can't do anything, but another player can start ascending the tower, from the start or from the place they last stopped to camp, using every equipment installed by other players to climb more easily than their predecessors. In turn, they will use their resources to install more equipment, allowing the next climbers to go further than they did, until someone reaches the top. I also plan to add a way for players to communicate using messages written on the walls of the tower.

From start...

I won't be starting from scratch during Devtober. I already started to implement a prototype of the game in Lua, using Löve2D. In this version, the player can walk, jump and the world wraps horizontally.

This is what it looks like at the moment

And it is fantastically ugly.

I'm not sure I want to keep using Lua for the final version, but I wanted to be able to prototype very fast and I love Löve2D and Lua, so I'm at home in this environment. I want to continue on this prototype at least until I'm satisfied with the way the character moves and controls.

...to finish

By the end of October, this is what I wish would be in the game:

  • All the basic movement (running, jumping and climbing), fine tuned to be as enjoyable as possible;
  • The stamina mechanic, interacting with the basic movements, with the proper UI display;
  • Three equipment that can be installed by the player: the peg, the rope and the rope bridge;
  • Basic graphics: an animated sprite for the character and a tileset for the environment;
  • The Camping mechanic;
  • A title screen, with a menu to launch the game or quit;
  • A procedurally generated tower, made by assembling sections designed by hand.

Yes, there is no mention of the multiplayer aspects of the game in this list. I don't think I can do it in one month, as I know next to nothing in networking. I haven't mentioned sound and music too, as I'm not knowledgeable in those subjects either.  If time allows it, I might add some mechanics to make the game enjoyable as a single player experience.

Start climbing

This is where I stand at the beginning of October. I will be updating this post hopefully every day of the month to document my progression on the game, then I'll write a new one as a post-mortem at the end of the month.

Day 1: Animation

I already have a good base of code for the game, so I wanted to start with something a bit different. So I opened up Aseprite, went to find my favorite pixel art tutorials made by Pedro Medeiros and got to work on the simplest walk animation possible.

First, I needed a character to animate. When I thought about what kind of tower I wanted to make, I thought more about a mountain, with harsh conditions. So I decided my character would be a mountain hiker and I drew them to be as simple as possible.

I want to remind the audience I am not an artist

For the walking animation, I decided to really represent the character walking, not running by default like in most platformers, because running and walking will be two different state in the game (the former will require stamina, contrary to the later.) Again, I tried to keep it simple, and went for a 6 frames animation.

And now my character is walking! Tomorrow I'll implement the animation into the game.

Day 2: animation integration

Yesterday I did some animation, today it was time to put it in the game. It took me some time but I made an automated system which reads spritesheets in a folder and puts them automatically in the game. Nothing very impressive to show today I'm afraid.

Day 3: jumping animation

I forgot to push yesterday's new code on my git, and as it written at home programming was out of the question: I could only work on my game at work during lunch break. So I decided to make more animations, and followed another of Pedro Medeiro's tutorial. Now that all the animations for basic movements are in, I think I will focus on making them feel good tomorrow.

Day 4: nothing to see here...

Although I already had implemented basic movement before starting devtober, one of my goal for the month is to have smoother, more enjoyable game controls. So today, I set up to do just that. I watched this video from Game Makers' Toolkit (one of the best YouTube channel about game dev out there) that explores why Celeste feels so good to play. The video has a link to Matt Thorson's Tumblr, where he explains how the basic physics work in his games. He has a pretty elegant solution to a problem I was aiming to solve: what do you do when an entity in your game moves enough in one frame to go through another entity. So taking inspiration from those, I set up to rework the physics of my game, but didn't have enough time today to finish. So more on that later.

Yesterday night though, I started to imagine what a portion of a level could look like, and drew it on paper.

It might not make sense if you're not me though...

This brought up an interesting mechanic that I think would make this game more unique, but I won't be discussing it today. I need to keep some bullets for the rest of the month!

Tomorrow I will be participating in Ludum Dare 45, a game jam that takes place every 6 months. I'll be creating a game in 48 hours with my colleagues, so I might not be able to work on The Tower.

Day 5, 6 & 7: ColorBound

So I have been working on a game for three days for the Ludum Dare 45. I won't spend much time talking about it here, as it's not part of Devtober, but I might write a post mortem in another post. You can find the game and download it here.

Day 8: Running in place

Continuing what I started on day 4, I re-wrote the way objects move in my game, which at the moment means I changed how the player character moves. My goal to reach a satisfying feel when moving around is closer, but unfortunately I didn't have time to finish. So basically I worked two days to get to something that is less than what I started with! I'm moving in the right direction though, and I'm pretty satisfied with the new system that is more robust than before.

Day 9: deep think

Disclaimer: I'm writing this on the 10th day, as I didn't get time to write this on the 9th day.

This is also why I didn't write any code or drew anything that day. But I took some time to think about gameplay, and I developed on an idea I got on the 4th day. Basically, I will put ropes front and center, and I might change the overall structure of the game. The idea is to use different types of ropes tied to different types of things to diversify player actions during the game. For example, a rope tied to a peg can be attached anywhere and used to rappel down a ravine. A rope tied to a hook can be used as a grappling hook and throw to grab on corners. Using a heavy chain instead of a rope could make it less susceptible to strong winds. So on and so forth.

This means pretty soon I'll try to implement ropes into my game. Wish me luck.

Day 10: around the world

Today I finished the rework of basic player movement. Simply running around feels more satisfying now, and I fixed the world wrap which displayed an old debug sprite before. Tomorrow I'll either start working on more detailed sprites for the main character or I'll start working on the rope mechanics.

Day 11: states, physics and a glimpse of a rope

Not very convincing...

Today I wanted to start implementing ropes in the game. So I went online and started to search for documentation, and I found this very interesting article written by someone who worked on the game Spider-Man 2.
Unfortunately, my character wasn't ready to be swung on ropes, and was definitely grounded. So I attached to it a state machine I coded before devtober and implemented two states for it: grounded and airborne.
The grounded state contains the code I had already written for walking left and right. I removed everything concerning movement on the y axis, except a movement of one pixel each frame. The way collisions are implemented, this allows me to check if there is still ground beneath the character's feet, and if there isn't switch to the airborne state.
The airborne state simulates gravity and switches back to the grounded state if the character hits the ground. This is also where I check if the character is attached to a rope and modify its velocity accordingly.
Ropes are pretty simple at the moment. Using the character velocity and position, they check where it should be at the end of the current frame, and correct its velocity depending on their length. The length of the rope is actually two values: current length and desired length. Each frame, the current length of the rope tends toward the desired length, to simulate the elasticity of the rope. It is the updated current length that is used when the character's velocity is calculated.
For debug purposes, I implemented a mouse left click detection that creates a rope where the cursor is and attach it to the player. For the moment it doesn't look good at all, but in the following days I will work on that.

Day 12: art attack

I needed a change of pace, so I went back to Aseprite with a new concept in mind for the character. At first I wanted a character that looked kind of bland, so anybody could project anything onto it. But now that the scope of the game as shifted a bit, I went for something with more personality. The first sprite I made was not supposed to be final, but a placeholder vaguely looking like the what I had in mind. Now I went for something closer to my goal, and even if it's not perfect I kinda like it.

Once again, Pedro Medeiros was a great help, this time with his series on medium called Pixel Grimoire.

Day 13: swing by anytime

After a small pause making pixel art yesterday, and a good night of sleep, I felt ready today to tackle the ropes again. Using the same article I linked on day 11, my goal was to implement two things: swinging velocity and better rope elasticity. For the swinging, I straight up implemented the algorithm the article described. I lost some time trying to debug it before I went down the comment section and found out that the author had forgotten one vector addition when moving the character to constraint its position with the rope's length. For elasticity, I added a rope acceleration and velocity, and changed the current length of the rope with those as long as it was greater than the desired length. I tweak the acceleration value depending on how close to the desired length the current length is, using a quad function (so the longer the rope, the stronger the pull to get it back to normal length.) I find the end result mostly satisfying, but at the moment elasticity only applies when the rope has a length greater than its desired length, which makes it look a little jittery sometimes. I won't spend too much time on that though, and will more likely try to make the ropes interact with the environment in the coming day.

Day 14: bug fix and posture

I didn't have much time to work today, so instead of improving the ropes as I wanted I fixed a bug preventing the character from moving when grounded that appeared when I refactored player movement for rope physics yesterday. Then I went back to my new character, hoping to use some advice I got from people on Pedro Medeiros' Discord and one of my colleague. I was not pleased with her posture, so I decided to change it, but didn't have time to finish. This is where I stopped.

WIP

Day 15: fleshing things out

Today I took over where I left off yesterday and finished the new sprite of the main character I started yesterday. The old position made the character look like a hooligan, which wasn't really what I was aiming for. So I went for a position that showed confidence and readiness, and I hope this is what it looks like! I also added some details: straps on the coat so it's easier to understand what it is, and a belt where the ropes will be attached.

Day 16: tangled

Back to the ropes, my goal for today was to make them react to the environment. First, I needed to detect if there was any collision between the rope and any environment element, which I achieved using a method for line collision I found here. Now that I knew where there was a collision, I need to make sure the ropes wraps around the object nicely. I did that by finding the closest corner to the collision and moving the anchor of my rope there, reducing its length by the distance from the original anchor. The previous anchors are kept so I can draw the rope properly. Next step would be to detach the rope from the collision point to restore it to its previous anchor when the angle is right, but it's getting late, so it will have to wait for tomorrow!

Day 17: unsticky situation

Ropes now interact correctly with colliders in the level. My problem for today was to un-stick the ropes from colliders, which I did by checking if the line between the character and the point of the rope before the last intersects with the collider.

There is a collision, keep the point

If it does, the point stays. If there is no collision, the point becomes unnecessary, so I remove it and restore the rope's length.

And this is what I get!

Tomorrow and the next day I'll be away for a friend's birthday, so I might not be able to do anything. I'll try to work on some level design on paper at least, but I can't promise anything.

Day 18,19 and 20: renovation

As I was away for a friend's birthday on days 18 and 19, and I spent most of today recuperating, I wasn't able to code or make pixel art for the game. So instead I started to really think about the setting and the structure of the game.

As I said before, for Devtober I wanted to focus on making the Tower a good single player experience. I've been playing and thinking a lot about metroid-vania games lately, and I think I want something with a similar feeling. As I see it, what this implies is a game that takes place in a single big level that the player will have to explore, discovering and re-discovering areas as they get access to new capacities. Those new capacities are not just keys, but they often also change the way the player approaches the game, by giving them more mobility or more options during combat, and allowing the player character to go through a clear progression throughout the game.

What it means for the Tower is that I'm going to make one big level, a big tower obviously, that the player will have to climb. The main ability of the character will be to install and use ropes, either to swing or to climb. This ability will evolve during the game as discussed in day 9: the player will find different types of ropes and different ways to use them. At first they will only have normal ropes, that they can install on pegs. Then, they might discover elastic ropes, that they can use to propel themselves, or a grappling hook which allow them to throw and attach ropes at a distance.

The main difference with classic metroidvanias is that those are resources. Once a rope is installed, it will stay in place until it is removed. So the player will have to build their way up the tower, installing ropes (and maybe other equipment) to reach new places, in which they'll find new resources to go higher, etc. I also thought about a mobile camp, which players can move around when they find a new place to install it, and that will serve as a checkpoint. As I will keep the stamina mechanic I talked about before Devtober started, the camp will play a central role in the game, because the player will need to regularly go back to it to rest. What I want to achieve is a game loop that would look like this:

  1. player explores around camp to find new resources
  2. player goes back to camp to rest
  3. repeat 1. and 2. until enough resources are gathered
  4. player uses the resources they found to climb higher and find a new spot for the camp
  5. player goes back to camp, dismantle it and transport it to the new spot
  6. go back to 1.

This leads us to the narrative of the game. It won't be a narration-heavy game, but I need at least a justification as to why the main character wants to climb the Tower, and what this tower was about in the first place. I came up with a simple and unoriginal story that serves me well: in ancient times, legend has it that the Tower was used by humans to go meet gods. People would go on a pilgrimage, called Ascending, and climb the tower to reach the heavens and trade with the gods. One day though, the pilgrims found the gates closed, and nobody knew why. The tradition of the pilgrimage continued for a while, but the gates were never found open. So year after year, less and less people went to reach the top of the Tower, until nobody bothered anymore. Centuries after that, a young woman is suddenly drawn to the Tower, and decides to starts the pilgrimage on her own.

I'm sure you can see where I'm going, but I will keep details of the story for myself at the moment. I chose a mystical theme to let myself use some mechanics that could appear as magical and still be coherent. It would also allow me some leeway on how the main character might evolve during the game.

I also started thinking about how to teach players how to play the game. At the start of the game, players will come across messages written on the walls by previous climbers now nowhere to be found giving them the information they need to go further.

That's it for those three days. I've put my notes down there so I would have something to show, but I'm not sure they are readable.

Day 21 and 22: push it to the limit

I hope you have this song stuck in your head while reading this.

I didn't post anything here yesterday because I didn't have enough to show anything. I started animating the new character. At a higher resolution than the first one I made, it quickly felt like I needed to put more frames in the animation. So I ended up doing a 12 frames running animation, with a huge help from the Animator's Survival Kit (which is an important book on animation, so no link) run cycle, recommended by a colleague.

Lo and behold, a dummy running

So yes, this is not final. Now I have to "dress" this dummy so it looks like my character. I'm also going to show it around to get some feedback.

Day 23 through 30: it's alive!

It took me a while (and two or three days to breathe a little), but I put some skin, clothes and hair on my running dummy. There is nothing much to say, I just painstakingly went over each frame to add all different elements of my character: trousers, jacket, hair, shoes, etc.

The result is not perfect, and having spent so much time on it I can see every little flaw I could try to correct. But there is only one day left in Devtober and I want to do move forward. So it will do for now.