Trasevol Dog's tweetcart. Carts like those are part of a somewhat unofficial Pico-8 jam to make a program in 140 characters or less. There is already a great amount of effects showing what you can do in this limited amount of code. You can look them up either by checking #tweetcart on twitter, or on Pico-8 BBS. Those carts are a great resource for both inspiration and learning. Sure, the tweetcart code is not very human readable, as most of the variables use single letter naming, but figuring out what 140 characters of code does is much easier than figuring parts of a whole finished game...
This is how I stumbled upon this effect. After seeing it on twitter, I added it inside my game and to my surprise, it produced a pretty cool distortion noise effect. Now to break it down and tweak it.
The original code was taking every other pixel on the screen and made another pixel a random amount away the same color. The problem was that the code made the game slow down pretty bad. Originally I was going to use it just as background for game over screen, but then I started tweaking that script. I found that if I will check and move less pixels around, the game will run pretty smoothly. With some trial and error I managed to to that! Then I just added a variable that will change how much noise is being rendered and came up with the code below:
Now I can just change the glitch_noise_factor and render the noise. The bigger it will get, the more noise will get rendered. Even the slowdown can now be used as a part of gameplay...after all slowdown is pretty common in machines that are bugged out and glitchy. Another bug that became a feature... as Rob Ross would say: "happy little accident."
Now that I finished the first glitch effect, the floodgates have been open and I am motivated to implement more glitches... after all, they were the one of the main ideas to behind this game.
Thursday, June 30, 2016
Wednesday, June 29, 2016
Most of the time I spent in Pico-8 was toying with the background pattern to make it look less like random assortment of pixels and to add the life counter. It is still not perfect, but I think I will leave it for the time. It is not all doom and gloom. I have managed to tweak some small things to make the gameplay feel better and solved a small bug in which the ball would destroy bricks in a straight line under certain conditions. The biggest achievement in this time was the screen transition animation. This frame will show up in red when you lose, and in blue between the levels. I might have just wasted 300 tokens on something purely cosmetic, but I think it will be a good way to show some of the game's theme.
That's it when it comes to progress in those ten days. I will try to implement more things this week when I have a bit more time to spare. Maybe I will finally make a dent in the new enemy/brick types, add some of the long promised glitches or mess with the win/lose formula. Recently, it was that last one idea made me think most about the game. Having score and lives is ok, but I have an idea for alternative approach where the ingame "system" would crash (lose condition) if you let too many bricks/bugs/errors exist for too long. It is kinda a time limit system, but it would be flexible to give a player more time the better he/she plays. This is something that will need to be tested to see if it is any fun. I am also toying with having limited amount of levels, as the game is infinite right now. Maybe some kind of "betting" mechanism, where the players could bet on how many levels they could beat and get bonus points based on that? We will see...
Sunday, June 19, 2016
Looking back on the past month, I think that the biggest surprise for me is how the process of making the game will actually dictate and shape the game. Only now I really understand why everybody urges new devs to go and actually make a games, instead of planning their Magnum Opus. You can plan all you want, but the game will only take shape as you are making it. I have spent a lot of time planning things on paper, only to find out that they sucks after I added it to the game. Such was the case with different variations of the two-hit brick, the general graphics of the bricks, and animations in the background among others. They all look great on paper, and even look great when drawn outside of game, but when put together they just don't gel well with anything else. Making games is as much as an art, as it is science...
Well, the first month is behind me. I have learnt a lot from making this game so far, and I have much, much more still to learn. Yet, the biggest lesson here is that virtually anyone can learn to make video games. If I can do it, so can you.
Sunday, June 12, 2016
|Particles, screenshake and level progression are in!|
...and I am really pleased with the results! The game is much more satisfying to play when the block breaking has a bit of a "weight" behind it. I was surprised how much of a difference a few lines of code can make. Also, that I managed to implement those things without much trouble. Sure, I looked up similar code in other games to get a hang of the particles and I was given a basic screenshake mechanic by @emu from the Pico-8 Slack, but making it work inside my game still felt like a triumph. As of now, I see the basic gameplay as complete. There might be some small tweaks done to it in the future, but right now it's time to move to other things.
One of the main features of the game are randomized levels. I have opted to go this route for few reasons: Pico-8 sprite map limitations means I can only make so many levels, lack of knowledge about level design (and not wanting to make an exact clone of something like arkanoid) would lead to levels that are just boring to play, and my fascination with randomization in games of all kind. A drawback of making the levels random is having some levels that are pretty easy to beat, so I needed more levels to keep the game from being disappointingly short. So far I implemented the backbone of the level progression system, rest of it will come out of the algorithm that is responsible for generating each level. Anyway, here's the code:
I am using two variables to check if the levels has changed, and two functions that are placed inside the _update() function (so they are checked every tick). On the beginning of the game the current level is 0. After the start_level function has generated the level, it simply makes the current level, equal to the level the program has just generated.
When the player clears a level (there are no entries in the bugs table, that holds the bricks/enemies), I make the ball go back to the serving position and change the level variable to the next one. Then the start_level picks up again and does its thing. Done.
Unlike the previous approach of generating the level before the game starts, running it frame by frame as a game starts makes the bricks appear one by one. I haven't planned for that, but it is a cool effect, that is probably easier for Pico-8 to run, so it's a win-win. It just needs some animation of the bricks appearing to make it great. Oh, and sounds...but the sounds will come much later. Next step is to add some enemy variety and implement them into the level generator.
Tuesday, June 7, 2016
So far I only implemented the basic brick. I didn't go any further because: 1. I didn't make a final list of enemy/brick types, and 2. Adding more types will require re-writing of the code for creating those sprites, and I don't even have an algorithm for that yet. Nevertheless, I am happy with this style so far. It is simple enough not to be distracting to the player, but representative enough to carry the theme. For what it's worth, the "computer noise" inside the bricks is the thing that makes the sprite truly stand out. Both the idea and the code for this effect are blatantly stolen from the Ryukyu Circuit cart. Because why should you take precious sprite space for an animation that you can procedurally generate? This is another example that reinforces me that choosing Pico-8 was the right fit for me. Being able to lookup the source code to of existing carts to see how others have solved similar problems or implemented a cool feature is an amazing learning tool for someone like me. Before I dug into that source code, I was ready to make the exact same effect with sprites. It would take much more time and I am quite sure it wouldn't look as good when limited to few frames of animation. Now, I only need one sprite and few lines of code. Awesome! Also, a big shout out goes to Dan Anderson from Pico-8 Slack, who once again helped me understand code where my own brain has failed me. The code for the circuit cart doesn't have many comments, so I couldn't find the function responsible for the noise effect. But Dan could. Thanks Dan!
As for those mechanical sprites above, I might expand on them and use them in some robot inspired shooter in the future... I like their angular style, but man, do they suck as breakout bricks.