Thursday, June 30, 2016

Glitches and Tweetcarts

Today I stumbled upon a piece of code on twitter that motivated me to start implementing the glitchy aspects of the game. The code came from 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:

function glitch_noise()
 if glitch_noise_factor > 0 then
  local f = glitch_noise_factor
  for tx=0,16 * f  do
   for ty=0,16 * f do
   tk=rnd(3)-1 
   ta=tx*(8/f)+tk 
   tb=ty*(8/f)+tk
   tc=pget(ta,tb) 
   tc+=flr(rnd(9)/8) 
   pset(ta+rnd(3)-1,tb+rnd(3)-1,tc)
   end
  end
 end  
end

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.


Wednesday, June 29, 2016

Game Dev Vs. Life

Sadly the last two weeks or so were pretty slow on the gamedev front. I didn't have much time to think about what I want to add to the game, not to mention implementing it. Thanks real life.

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

First month of gamedev

Past week was pretty busy on real life front, so there isn't much programming progress. I did manage to implement a two hit bricks (yellow), tweak the paddle movement to be a little smoother and add background graphics. Apart from those, most of the week was spent on testing, tweaking and making the game play, look and feel "just right." So far I am really happy with my progress, just to think that a little over a month ago I had no idea how to even start making a video game. Now I have that something that resembles an actual game! I am really stunned, that I managed to pull this off! More than that, I had gotten some good feedback (and even some interest about the game) from people online, which is a really humbling, but also really exciting. I never thought that anybody would be even remotely interested in a first game from a total programming noob. You are all making me want to push forward. Thank you.


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

Game feel and level progression

Particles, screenshake and level progression are in!
Before I added any more features to the game, I wanted to make sure the the basic brick breaking feels good. After watching few talks about the game "juiciness" and the art of screenshake, and reading about the "game feel" in general, I have decided to give those things a try...
...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.


LEVEL PROGRESSION:

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:

level = 1
currentlevel = 0

function start_level()
 if currentlevel < level 
 and #bugs < 20+level then
  create_bug()
 else currentlevel=level 
 end  
end

function end_level()
 if #bugs==0 then
  ballxdir=0
  ballydir=0
  ballx=(padx+padx+padw)/2-2 --centers the ball on the paddle for serve
  bally=pady-6
  newball=1
  if btnp(4) then
   level+=1
  end 
 end   
end

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

Finally some progress [on the graphics front].

The game actually moved past the "janky prototype" phase in this past week. I finally added some theme, but it took forever to zero-in on it. I knew I wanted a glitchy aesthetic and for the bricks to be somewhat representative of robotic bugs or some mechanical "body horror" thing or growth. Well, as it turns out making a good representative sprite on such a small scale, with limited palette, and on top of that, keeping them more or less rectangular (after all they need to work well as breakout bricks) is really hard. The sprites that look good on their own, end up looking really distracting once few of them are spawned in the game...not good  After spending close to a week on trying to make representative sprites I somehow found myself googling fictional 80s computer UIs. So I decided to try that. After all, Pico-8 is an 80s fantasy console, so an 80s aesthetic wouldn't hurt. After delving into artstyles of Tron, cyberpunk and 80s retrofuturism in general, I knew I was onto something.


Now, instead of trying to squeeze in some H.R Giger-esque cybernetic growths and other assorted horrors into tiny Pico-8 sprites (you can see some of my passable attempts here on the right), I am going with a simpler neon style reminiscent of  "as seen on TV" 80s computer interfaces. Those simple sprites will be applicably distressed with glitchy graphical effects (and glitchy game mechanics, coding skills permitting) to make the game more pleasing to the eye and to reinforce the theme of fighting against computer viruses, bugs in code, whathaveyous.

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.