This cat is on the prowl for some fighting action. Well done!
A member registered Jan 07, 2017 · View creator page →
Creator of
Recent community posts
Day 11
Even though I had the full intent of completing this jam when I started, I'm still sort of amazed I made it this far. I keep on thinking I'll hit a point where working on this project will cease being rewarding, but each step further fleshes the game out and is all the more enjoyable to me.
I decided I couldn't stand to have this game go without a beginning or end any longer, so I added a launch screen, a game over screen, and a victory screen. The launch screen looks like butt, but I'm still weirdly proud of it. I also added sounds to the new screens, sort of musical one-offs. Making music is extremely challenging, even harder than making sprite art. I don't really enjoy that part, but it still gives me joy to hear my nightmare sounds play like I've just approached some old arcade machine with a super retro soundchip.
Day 9
Starting to get some steam here. I added enemy firing, which necessitated adding lives, which necessitated ending the game. Included a sound for being hit by enemy missiles and (my favorite) a series of hearts that change color as you get hit.
Tomorrow I add the bomb to the game and begin working on enemy appearance patterns in earnest!
EDIT: I was feeling restless so I did some continued work. I added the bomb and a few more enemy appearances. At this point, all that's left to fit my "technically complete" requirement for completion would be to add "enough" enemies to make a stage and then mark the stage's completion somehow. I'm gonna go nuts doing that, so for the rest of the week I'm going to alternate between that and adding various pieces of polish to make this game slightly less crappy. Still, I wanted to post a quick update to mark this milestone in my project.
Day 8 i think
At this point I'm just blatantly putting off working on the hard stuff. I added my "tough" enemy type that requires two hits to destroy. It is simply a recolored version of the original sprite. When it gets hit, it changes "class" to the simple enemy type, and is drawn and tracked thusly.
That was okay, but what I really enjoyed tonight was working on the "feel." I hated the way enemies just dissapeared with no fanfare. I'm trying to keep it simple here, but it was driving me nuts, and like I said before I didn't really feel like getting into the hard mechanics of the game.
I'm no good at the sound stuff, straight up. I'm pretty much guessing. But in the process of "guessing" for the sound of destroying a ship, I ended up coming up with a pleasing sound for firing a bullet. So I added that, as well as a "thud" sound for hitting tough enemies and an "explosion" sound for hitting simple enemies.
I was gonna call it there, but it was driving me nuts, again, how the enemies just dissapeared. It was even worse because there was this long explosion noise but no real visual signifier of what that noise is. This led to fun with drawing "explosions." I created a new table to track explosions and, when an enemy is destroyed, I find the center position of the sprite and save it along with a "lifespan." The lifespan signifies how long the explosion should remain on screen. For each frame that passes, the explosion's lifespan increments. If the lifespan is less than my arbitrarily set count of frames, it remains in the table and is drawn as normal. But when it hits that point (currently 15 frames), it is deleted from the table and removed.
If I end up with some polish time (unlikely at this rate), I'll try to make it a little flashier. For now though, I'm glad that it actually looks kind of like something is happening. The gif only tells half the tale, the sound takes it another level.
v
Day 1 + Day 2
I've been learning a lot, but I don't feel like I have a lot to show for it, except for an appreciation for better planning. Things went swift at first, making some odd sprites I knew I'd need and working on preparing the stage. This involves drawing a big blue rectangle over the screen (THE OCEAN!?) then drawing Ace, our protagonist, on top. A basic pong-like tutorial featured in Pico-8 Zine #1 had already prepared me to set the controls, and I'm smart enough to set rules to keep Ace on the screen (don't let his X or Y positions increment up or down at their respective borders). That's where I left off last night.
Today, things got more interesting. I drew some really rough functions for firing bullets and tracking those bullets across the scren. Then, I drew an enemy sprite. He's uh... an alien ship. A demon head?
okay, he's programmer art
I realized I'd need to control when and where these jerks would spawn, which took some thinking on my part until I came up with a solution I'm not really satisfied with. I'm keeping a count of frames that increments on each frame. Then, when the count reaches a certain number, in this case 30 (aka 1 second in 30fps), the enemy appears on a position I designate. In theory I can time and release enemies at specific positions this way. Seems kind of cumbersome, but I'm not really sure how else I'll do it.
The next horrible realization I had is that I would need to be able to track the positions and states of multiple enemies throughout the game. In truth, I had realized I'd need to do the same thing for bullets beforehand, but I had cheated by just setting the life of each bullet to roughly the amount of time it would take the bullet to cross the speed and then preventing the user from firing another one until that time had passed. Kinda gross to be honest.
I really really really didn't want to have to write code to declare, track, and draw every single enemy in the game, so I took a break with PAT Shooter before diving into its code. As a side note, other PICO-8 games are definitely my main excuse for procrastination during this jam. I couldn't stop playing more lives of PAT Shooter for "inspiration."
Anyway, it took me quite a while to figure out what I was looking at, but when I got it, it was like a lightbulb going off in my head. Actors with consistent behavior in the game are all declared in tables. As far as I can tell, Lua tables are basically just arrays. The way this handles is pretty smooth. At any point I choose, I can (for example) declare enemy E, sent E.X and E.Y to the appropriate X and Y coordinates I want to set it at, then add E to a table called Enemies. At any other time I want, including while iterating through that table, I can change these properties of the enemy, or even delete the enemy outright. From there, it was child's play to write code to iterate through the enemies to alter their positions (movement) and draw them.
I opted to refactor my bullet code to take advantage of tables and it has already payed off. I ended my day by setting up a bullet and enemy collision check where I iterate through each bullet in my Bullets table and, in each loop, iterate through each enemy in my Enemies table. If their positions overlap (or more accurately, exist within ranges that appear like an overlap on the screen), I delete the given bullet and the given enemy from the table. They stopped being tracked or drawn and PICO-8 doesn't choke on the mid-iteration adjustment to the tables at all! Beautiful!
When I started on all this bullet and enemy stuff this morning, I thought I had hit the hard part. Oh boy was I wrong. Now I have to consider enemy movement and firing behavior. I guess I could just have each enemy move at a static speed and fire a bullet that moves at a faster static speed? Kind of boring, but I think I'll stick with that plan for now. If I end up with more time later, I may try to fit in more complex enemy behavior, but at this point I'm already choking on the idea of just trying to declare and position enemies over the course of the game.
I gotta be careful going forward. I made my first bullet system in a rush and ended up having to refactor the whole thing when taking shortcuts failed me. That was already painful and it was a relatively small chunk of code. I could definitely see this blowing up in my face.