Belén Albeza

Ludum Dare #56 post-mortem

2024-10-08T21:18:00Z

Last weekend I participated in Ludum Dare, my favorite game jam. As always, I opted for the Compo category, which consists in making a game solo in 48 hours. The theme for this edition was "tiny creatures".

You can play the game in your browser from my itch.io page, and that might be helpful to put this post-mortem into context.

Development log

Saturday

I started by making a mind map to brainstorm game ideas.

I opted for a virtual pet game and pay homage to Tamagotchi, one of my favorite toys from my childhood.

In retrospective, I should have made sketches of the UI, think about which attributes I'd like to implement, how the pet would evolve, but… I just went ahead and drew a hatching egg animation in PICO-8's sprite editor, and a square with two dots as the "pet".

Then I went on coding a calendar, a few actions, stats and the main core cycle of "selecting an action" → "modify stat" → "tick time". And I called it a day and went to sleep at a reasonable hour.

Sunday

A lot of basic features were missing, but at the start of the day I made a list of my must-haves:

Pet death
A simple mini-game for executing an action
Pet evolution depending on the stats
Some sort of "end game" beyond keeping your pet alive… I ended up with an idea of showing a gallery of the different pets you could collect, kind of like a card album.

For the mini game, I implemented a simple reflex-based game. Depending on your results, you will get a boost or a debuff to your chosen action.

As for pet evolution, I definitely needed more stats beyond the two initial ones. I ended up with eight, and I kept tweaking them during the whole day. I still don't feel satisfied with the balance, but it's very tricky to nail this in an afternoon. I would have wanted two distinct "evolution branching" events, but ended up with just one. At least I found the sprites adorable.

The last thing I implemented was the "reserve", aka the album. I did a trick of being able to collect female and male versions of every pet type, so it didn't look so empty and players would have an incentive to try to figure out what stats exactly made the pet turn out like it did.

I had only a couple of hours left till the end of the jam, but I decided to not try to pull out a background music track and submit that version already, since I was tired.

Lessons learned

What went well?

Booking PTO for the following Monday and take it easy during the jam.
The cute sprites for the pet and egg were a source of motivation.
Publishing a build by the end of Saturday so people could check the game out already.

What went wrong?

Making assets before coding the features.
Balancing stats was very tricky. I should have set up a spreadsheet or something of the like in advance to help me balance everything.
Introducing new pet stats on the fly.
Leaving audio till the very end.

Tools

PICO-8 as the game engine.
Pen & paper
Git for version control and back up.

That's it. I'm quite happy with PICO-8 because it features all the tools I need to make a game, like a sprite and SFX editor. I wish the code editor was better, though, and/or had vim shortcuts.

PICO Payun post mortem

2023-07-18T18:30:00Z

PICO Payun is a small, retro shoot'em up game I made with PICO-8. This article is a post mortem of the development, so I'd recommend you play the game first (you can do it directly in your browser).

Scope of the project

The idea for the game came up due to this tutorial series. While I quickly diverged in the codebase it is a good tutorial in terms of which features to implement. It also put a lot of emphasis in visual effects and feedback to the user (a concept often referred as juiciness in game design), which is something I never put too much attention in PICO-8. So I decided to take the gist of each video, implement it my way, and add / remove stuff as I saw fit.

In the end, PICO Payun features:

8 different levels (including two boss battles)
2 weapons (1 main weapon and 1 special attack)
Pickable power-up's.
6 different enemies, each with a unique attack.
Background music.
Score.
Loads of visual effects (explosions, sparks, shooting muzzles, etc.)

If you're not familiar with PICO-8, it's a "fantasy console" with limitations that force you to think out of the box and keep your games small. The most relevant restrictions are:

Palette of 16 colors (including 1 transparent color)
128x128 pixels display
8192 source code tokens (for instance, a variable name is a token, special characters like ( or = are tokens too)
Limited memory for storing graphics (bank of 128 8x8 sprites)
4 channels of audio

Code

Nothing too complicated in this regard. Half of the codebase relates to the enemies and levels, and the code ended up being quite messy until I started to put some "order" in the new stuff I was implementing (I did not refactor previous code).

It turns out PICO-8 has coroutines! They are amazing to implement sequences. I used them to implement the cinematic sequence when you finish the game and the ship moves on its own.
The final boss is implemented with an actual finite state machine, since it has a few attack patterns, plus the transitions between them, plus its destroy sequence. The other enemies' attacks are also FSM but they are not implemented cleanly that way, and it's painful to see (luckily I didn't need to modify existing behavior because enemies worked well).
Collisions are implemented with rectangular and circle bounding boxes. It's a quick system and enough for this game. Of course, the size of the bounding boxes are tweaked so the player feels that they're "fair". For instance, the one for the ship is very small, so enemies clearly need to hit the player's ship in order to damage it. However, power-up's have a large bounding box so it's easy to pick them up.

In total, the codebase takes 7300+ tokens, which is near the limit of PICO-8's 8192 tokens. I didn't optimize for this and have a lot of auxiliary functions that make the code more readable, but with more tokens.

Development

The game was implemented over a span of ~2 months. I didn't work on it every day, and when I was up to the task it was usually in small chunks of time (20-60 mins at a time).

I ended up consuming most of the tokens and a lot of the space in the sprite banks (but I didn't bother to optimize for any of this, so I guess I could have added a few more enemies, power-up's or weapons…)

I tweeted the whole process (you can follow the thread here), which was good for morale and also for getting feedback. I even published a playable release at the middle of the development for people to try out! I got good feedback (and bugs!) and the game was definitely fun to play, so that gave me the energy to push forward and finish.

Art

I wanted the game to be cute and colorful. This can get tricky with PICO-8's small color palette, but I think I ended up achieving it.

Most of the animations are just 2 or 3 frames long. For instance, the main ship is just a 3-frame 8x8 sprite (one frame for staying still, and then two different ones for each direction). The animation for the engine thrust is a separate sprite, and keeping it separate gives the illusion of a more complex sprite.

For the enemies I chose them to be "organic", kind of like alien monsters. That helped to be cohesive and to differentiate them from the player's ship —which is "mechanic".

All of the enemies —including the bosses— feature a 2-frame animation that is a squash and stretch. They shrink and squash agains a virtual surface, and then they "rebound" and stretch to their original size. Again, this helps with coherence (and also with production!). It's seen most clearly with the slime alien:

Most special visual effects are based on drawing filled or unfilled circles. There's a primitive (due to the fact that PICO-8 doesn't allow for transparency or blending mode) particle system in place, that is used for explosions, weapons, etc. Example:

Audio

Sound effects are core to this "juiciness" we were referring to, and the game features different sound effects for shooting, impacts, pick-up's, etc.

The most lacking aspect is background music, in which I struggled a lot to compose something that made sense and that did not occupy all the audio channels (PICO-8 only has 4) to leave space for the sound effects to be played.

The main track for the game ended up more cheerful that I intented, but I didn't want to spend a lot of time on this task, so I went with it anyway.

Lessons learned

What went well

Project is finished and didn't took ages!
The game is quite polished, specially in terms of audio and visual feedback given to the player.
It was a stress-free process, since it was done in very small chunks of time and I didn't have a deadline looming in the air.
I was able to limit the scope —specially given there was no deadline— so the game could be released.
PICO-8 limitations in terms of graphics (palette, sprite bank size, etc.) actually helped me a lot in achieving a balance between art that was "good enough" and time spent on it.

What went wrong

The code for enemy behavior is a mess. I was very, very lucky I didn't have to modify it significantly out of feedback from players.
Near the end of the project I took a few weeks' break and then I felt unmotivated to actually take it up again and finish it. Breaks are fine, but I should have made myself easier to return to the project, like a list of what was actually left (very little!) and notes on what to do next exactly.

To try next time

Have an actual list of tasks, even if the project is small (I usually keep one, but didn't for this project)
Keep using PICO-8 for small games and prototypes. Jump to a fully-featured engine like Godot for more feature-packed projects.
Put a bit more emphasis in code readability, even if it's just a small Lua game.

Talk – Learning Superpowers: Leveraging Obsidian for technical learning

2023-05-31T18:00:00Z

It's been many years since I presented on staged, so it's nice to be back and this time in my home town. Thanks to the nice people of the Alicante Frontend meetup for inviting me to speak.

In the talk, I show how I've been using Obsidian to aid my technical learning and build reference material. It has a companion Github repository with an starter vault to get you up and running.

Download the slides here.

Leaving Mozilla

2021-09-14T09:30:00Z

I've been working at Mozilla for almost six years, and today is my last day. We finished the last project I was working on, and I felt it was a good time to have a break and then go do something different. Six years is a lot of time in tech, so I wanted to write this to reflect about my work there.

I joined Mozilla as a developer advocate. My role involved a lot of divulgation and outreach around Web standards. Beyond the usual CSS, JS and HTML, I focused on those standards and APIs related to video games and virtual reality. Many articles for Mozilla Hacks, the MDN or even here at my blog; talks at conferences or meetups (including View Source in Berlin) and even a multi-day workshop on game development… And then, after almost three years, I left this advocacy role to switch teams and join the Firefox Developer Tools team as a developer.

I've had the chance to contribute to multiple Developer Tools, such as implementing support for Web Components in the Inspector, completely re-vamp the about:debugging (aka "remote debugging") tool, code a brand new tool from scratch (the Application panel) and lastly, migrate the Storage panel to the new Fission architecture.

I'm grateful to have had some great teammates and to have met some interesting people as well. But it's time to move forward now.

I still don't know what my next adventure is. I'm planning to take some time off (I had to cancel my summer vacation, so I'm definitely intending to have it now), tinker with new tech, maybe join a game jam, learn new cooking recipes and get some clarity on how I would want my next position to look like.

I know two things for sure: 100% remote work is a must, and I'd also like to keep doing work as an individual contributor (i.e. not a manager). Other than that, I haven't decided the kind of company, product or tech stack I would like to work with. Although I will not be actively looking for a new position for a while if you'd like to get in touch in the meantime, feel free to write me an e-mail.

Ludum Dare #48 post-mortem

2021-04-27T18:30:00Z

It had been around a year and a half since my latest Ludum Dare, so I was really eager to join the game jam this past weekend. My goal: make a game from scratch (code, art, music) in 48 hours. The theme for this edition was “Deeper and deeper” and I made a tiny game about an elf trying to return home, which you can play on Itch.io.

In this post-mortem you will find a short development log for the game, the tools I used, and what I learned while making this game.

Development log

Saturday

I woke up at 7:30 AM and saw the theme: “Deeper and deeper”. I had a short workout at home (thanks, RingFit Adventure), and then brainstormed some ideas while having a coffee. For this, I like to do mind maps:

I was unsure of what to make out of it, so I went for a walk, and then did some house chores while still thinking on which kind of game I’d be making. At lunchtime, I settled down for a Diablo-like game about a dark elf having to return to his home in the Underground after having been cast out. I quickly drew a mockup of how I wanted it to look like.

On game jams, I usually like to spend Saturdays coding and leave Sundays for art, music and level design. However, this time I got “trapped” into doing 1-bit retro pixel art —a poor decision in retrospective, but I was having fun!

And quickly after that, I re-designed the main character to make it cuter and have black skin (like the dark elves from Forgotten Realms).

I loved how it turned out. I posted it on Twitter and people really liked the character as well.

I implemented rendering a level based on tiles, and also the character with basic movement. At this stage I decided not to follow Diablo’s controls with mouse, and rely on arrow keys or d-pad, like Zelda.

I called it a day, and went to bed at a reasonable time.

Sunday

I was behind schedule in any way possible, so drastic measures had to be taken: I dropped combat mechanics and introduced dialogues instead, so I could tell a story while the character was travelling down the different levels.

And I hit a wall with this because I still don’t fully understand how Godot handles UI, and it turns out that implementing a box that will expand and shrink depending on the length of the text is not trivial.

In the end I managed to implement it, but I wasted a lot of time doing it. I could just have drawn boxes with three or four sizes and just picked one depending on text length. It would not have been perfect, but it would have been much quicker.

It was getting late, and I realised I still didn’t have a title screen or an end screen, so I made those two. I used the title screen to display a short tutorial, and I re-used the main character and my new shiny dialogue bubbles to achieve that.

SPOILER ALERT: You may want to play the game before you continue reading!

I only had a few hours left, so I quickly decided the story: the elf couldn’t win. He had been banished forever by some cruel gods, and he would be forever stuck in a loop trying to get home in vain. To reinforce this idea of looping, I made the player to go through the same levels a few time before displaying the “end” screen, and the main character would say something before going downstairs to switch to the new level.

And to make the levels a bit more interesting, I decided to introduce doors and keys, so the player would need to explore the level a bit before finishing it.

Once everything was in place, I added some retro sound effects I generated, and also quickly composed something in Garage Band as the soundtrack. I wanted something repetitive, that felt like endless work.

And I was done! The game turned out like nothing I thought in the beginning, but I’m happy I could submit something that felt complete somehow.

Lessons learned

What went well

I had no problems when exporting the game to HTML5 with Godot.
Rendering a tile map with multiple layers was a piece of cake.
I designed a super cute main character!
The 1-bit pixel-art style was quick to draw.
I like the story and I think the game does a decent job telling it.

What went wrong

It took hours to implement the comic-like text balloon for the character to speak. And my ego kind of got in the way of me settling for a dirty hack.
I had a very slow morning on Sunday, and it took me a while to get to work on the game. I also decided to watch Barça’s game in the afternoon, so I lost an extra two hours there.
Since I made the art assets before implementing the game, I ended up with assets I couldn’t use (a walk animation, a sword, etc.)

Tools I used

Game engine: Godot
Art: Pyxel Edit
Music: Garage Band
SFX: jsfxr
Ideas and mockups: Apple Notes
Project management: Notion