Pixel is a reminder of what the pixel means and its power.
Today’s screens, by creating ever-increasing pixel densities, the pixel is completely overlooked. This experimental game, on the other hand, gives it prominence and even in displays of extremely high density and resources barely perceived by the human eye, the pixel is staged, which is the minimum representation of any digital work.
Since each element in the game is represented by a pixel, this is also the largest element in the interface; there is nothing else: there is no visible score, there is no running time, only pixels. The whole game can represent a classic game of ships, or also a person struggling in vain against the heat of the planet, or whatever each player can imagine. The pixels agree to be representatives of whatever players want.
Pixel seeks that when you play, you can perceive the power of what you are moving, of what appears to be a minimal glimpse of light and at the same time is the fundamental piece of everything that is digitally represented on a screen.
You can play by clicking here: https://pixel.lucasdima.com/
About Pixel
Pixel is my second finished Pico-8 project. The first one is mine2020, which I developed during 2020 as an attempt to learn Pico-8. The learning process of 2020 was a success, because I managed to develop Pixel quite fast.
As it was mentioned in mine2020 post, Pico-8 is an amazing platform with strong limitations allowing only the essential topics to be visible and it is super enjoyable to program.
Programming Challenges
Actually everything was more or less simple. The only challenge I found was the collision detection between the bullets and the enemies. Basically because the bullets travel quite fast, I put a speed of 5 pixels per frame. So it is not possible to make a pixel over pixel collision because bullets (or any other fast traveling object) may overpass the enemy without being in the same position. So I developed some checks that depend on the direction and the speed. It checks if there are enemies in the line formed by the bullet position with the ending position, so if there is an enemy there, it will count as a hit, destroying both the enemy and the bullet. So each bullet can only destroy one enemy, which adds some challenge to the game itself.
Process and Discarded Stuff
At first I created two short levels were only one or two enemies appeared every 2 or 3 seconds, giving the player the possibility to learn how to play, but later on, I discovered that after you play a while it’s really annoying to replay this levels, so I decided to remove them. Right now, when the player starts there is one random enemy spawned every second, and after a short time this is increased to 2/3 of a second and finally to 1/3 of a second, so at the end you get 3 enemies per second, which is a lot. And is quite fun and challenging (at least for me!).
Another feature I added to be more fair is that enemies spawn at least 50 pixels away from the player, or else an enemy can spawn very close, or even in the same position, killing and annoying the player at the same time.
Interface
When you finish, all the killed enemies are displayed on top, as individual pixels. But after a while I decided, first to add the killed enemies as soon as they are killed, giving an effect of progression.
And then I went even further and I added at the bottom of the screen the amount of enemies that are currently in the screen, and this gives a sensation of danger, which I also found it quite interesting.
Next Steps
I am not sure about this, but I think it would be interesting to try some hardware console and put Pixel inside. Maybe as a concept, or maybe as a was of generating a tangible piece, and maybe (too many maybes) a limited amount, but I am not sure about this. We will see. This post https://www.lexaloffle.com/bbs/?tid=44065 has a good explanation about which console to use.
As an art piece, I like the idea of having a console, which only runs Pixel. We will see…
