🤑 Indie game store🙌 Free games😂 Fun games😨 Horror games
👷 Game development🎨 Assets📚 Comics
🎉 Sales🎁 Bundles

GlitchThief

31
Posts
1
Topics
3
Followers
2
Following
A member registered 225 days ago · View creator page →

Game

Recent community posts

This cat is on the prowl for some fighting action. Well done!

Solid first shooter with a pleasing soundtrack.

Adorable character designs!

Solid runner :)

WAH! (Good work!)

Very moody and evocative.

Phew, that was challenging! Well done!

Somber and atmospheric!

This is cute and fun to play!

Aww hooray, another PICO-8 game! The sprites were really cute, the gameplay was fun! The effect when I hit a cat was well-done and alarming. The start menu and the game over screens are really well designed. Overall very impressed with this entry!

Yeah, myself and at least one of the others in the team I'm in are looking forward to producing something positive and hopeful.

Replied to eggnog in Air Ace comments

haha Thank you, I couldn't resist. Thank you for playing my game.

Thank you! And thank you for playing!

I almost can't believe this was made in PICO-8. Very great showing.

Air Ace is has now been published and is available to play. Check it out if you like.

I have so many crazy feelings about this game. On one hand, I'm disapointed that I set my sights so low. I thought as a first project, on a timeline, it would be prudent to keep it simple and not even think about things like fun or polish. Given that I ran out of time due to unforseen consequences, this was probably smart. And on the other hand, I learned a lot. Like, a LOT. I thought I had ideas before, but now I've experienced so much, I have more realistic ideas I can pursue. I don't feel this game represents me particularly well, but I feel equipped to make one that does.

I'd say a few technical things I learned... USE OBJECT ORIENTED PROGRAMMING! My code base is a shambles because I tried to program out all the behavior on the fly. If I had planned things out, thought about what I"d need to re-use, I would have had a much more attractive and maintainable code base. Expanding this game would be a nightmare. I have some shmup ideas I want to pursue in earnest, but I would not build directly off Air Ace.

The other thing is like, holy crap I knew I can't do art or music, but I REALLY can't do art or music. If ever I decide to engage in a professional venture (that's a far off dream), I need serious help with that stuff.

So yeah, I feel mixed up. Working on the game, and in this jam in particular, was very rewarding. And I truly learned a lot, which was my objective. But oh jeez, I don't think I'll be able to rest until I build something better to prove what I can do.

I want to say thanks! Thank you to everyone that encouraged me here! Thank you to everyone reading this. And most of all, thank you to anyone who plays my game.

This jam is rad and you all are rad. Making my first game is a big step on a dream I've been stalling a long time. I'm filled with confidence like I've never experienced before. I don't know what else to say. Just thank you. Thank you.

Day 12

It was really sticking out to me today that there isn't really any reason to shoot most of the enemies that appear in the game. So I added scoring. Now players will experience bloodlust in pursuit of ever higher scores!

If I had done this last week, I'd probably have a story about everything I learned and struggled with, but this is getting easier.

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.


A clever game, with some devilishly funny ends. The only bug I noticed is that if you restart after getting the cat or dying, the door to the west remains open (though you cannot cross the threshold).

Great work, Komrade! Looking forward to seeing it with sound!

Day 10

Fixed a bug where colliding with enemies wasn't causing Ace to take damage. However, after the fix I ended up making Ace take TOO much damage. If I'm gonna check for collision every frame, I need to give Ace some clemency as an 8x8 object colliding with other 8x8 objects. First, I refactored the code so all the effects of ace's collisions are tracked in a single function, and then I made that code conditional on an invincibility counter not being in progress. When the invincibility counter is incrementing every frame, ace is invincible. When those increments hit a certain point (arbitrarily 5 frames at the moment), they cease counting and reset until the next time Ace takes damage.

Added some more enemy placement.

(Edited 1 time)

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.


I'm really digging the visual gusto you've got going on here. The animated tiles are a particularly nice touch.

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

Wow this is way more elegant and maintainable! Thank you for sharing!

hahaha extreme thank you for the heads up.

uhh is it really Day 6? I was sick and now I'm working extra hours to make up the lost time at my real job so I don't know. Today I tried to implement logic to handle two types of enemies, and spent the better part of an hour trying to figure out why the system was reporting unclosed functions. It seems, DESPITE some examples in the wiki, the correct syntax is elseif, not else if. I would have known this if I had just looked at the manual instead of relying on some random 3rd party BULLSHIT that I googled up.

Would-be PICO-8 users, avoid the wikia page. It fucking blows.

Will you be sharing your cart when you're done? Would leave to see the code!

This is awesome! Thank you for sharing, Plum!

Here's the bullet collision, by the way. It's a good thing I'm deleting all bullets that leave the screen or I bet this process would start to slow down real quick.

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.

I'm excited that I'm not the only participant going with a PICO-8 entry. Really excited to see how this turns out!

Created a new topic [DevLog] Air Ace

Greetings, I'm GlitchThief, real name Mori, and this is my first DevLog for my first game in this FIRST GAME GAMEJAM! I'm playing with the PICO-8, which is an application that bills itself as "fantasy console for making, sharing and playing tiny games". It's incredibly charming in its design and provides some tools to dive in and get dirty making simple lo-fi games. It's really cute and fun to play with and I can't wait to make my first game in it.

I'm arbitrarily titling my game Air Ace. I've played all kinds of games all my life, and SHMUPS are seemingly the simplest that I regularly come back to. I'm aiming for an incredibly simple "technically complete" experience, with any surplus time I'm left with used for polish. We'll see what someone with no art experience can do with an engine that lets you make 8x8 16-color sprites.

Some basic goals:

  • Allow players to move in 8 cardinal directions
  • Allower players to shoot forward. Bullets remove simple enemies.
  • Two enemy types. Simple enemies are removed when hit by bullets. Tough enemies become simple enemies when hit by bullets.
  • Provide 3 lives. Getting hit by a bullet causes a player to lose a life.
  • Provide a bomb, an emergency button to remove all enemies from the screen and make the player temporarily invincible. Bomb gets reset when a life is lost.
I'm so effed.

1. Hi there! What's your name? Want to introduce yourself?

I go by GlitchThief. I'm a web developer by trade, but I'd rather be making game.

2. Did you participate in the last jam we held? If so, what do you plan on doing better this time? If not, what's your reason for joining?

I decided late last year that I want to make one new game every month this year. This seemed like the ideal way to kick my own ass into starting.

3. What games are your favorites? Did any of them inspire you, or made you want to make your own?

I typically play MMOs or Pokemon games, but smaller older games are what really capture my creative imagination. Old-school RPGs and shooters really make me think about what I can do.

4. Do you have experience with game development? What did you do/with what engine?

I have a few false starts. I've done tutorials in various engines and languages bu never finished a project.

5. Tell us about something you're passionate about!

It's embarrassing, but I pretty much think about Pokemon 24/7