Started on a game for the LOW REZ JAM!
I'm using an 'object pool' which is a little bit strange, but it should avoid the memory issues that were had in my Spaceball game. I should really go back and fix Spaceball to work the same way. The idea is to design the game to never logically go above the predetermined limit of 100 "actors" which should be more than enough for my purposes.
The working title of the game is "Pixt" which is inspired by Pixel's shooter game, Guxt, hence the blue color scheme.
Also, I'm using a total of 5 colors at the moment. It's an arbitrary number, and I could probably do it with 4 colors, but there's no rule about the number of colors.
p.s. Apparently the movie export in PICO-8 ignores graphics modes. I could crop it, but I didn't. ,'-y
Worked on the game some more. Added an enemy that floats left and right, because, you know, shooter games. I also started implementing a feature I wanted to try out which is an overheat meter for your gun, so that you have to occasionally stop firing or your firerate will suffer. Amazingly, the entire game lags slightly when the meter is above a certain threshold. I'll try and figure that out tomorrow. Seriously some weird shit though.
EDIT: I accidentally put some drawing code in a FOR loop that should not have been, the heat bar was being drawn many times and it got worse with more bars. I fixed it. I think I'm done for the day, I probably need some sleep.
Yeah, that's what I'm doing on my game, too. Whenever an enemy is killed or whatever, just move it offscreen (or stop drawing it, w/e) and reuse it the next time you need another one. Seems to be the best way to manage memory, since you aren't continuously creating new actors.
I think it's silly when you play a scroller and you find yourself holding down fire 100% of the time; it's as if the only purpose of the fire button is to make your finger sore. I have implemented an "overheat" bar which fills up if you fire your gun without stopping, which is a very straightforward method of giving you a reason to let go of the fire button sometimes. We'll see if I wind up keeping that idea or if I decide it's not fun.
Another method of making the player stop firing is to make mines that explode with a wide radius if you destroy them.
I have some ideas I want to play with if I have time, like walls you have to "dig" through, minefields, an ability that lets you fire sideways, and of course bosses.
This is kinda fun: I used red pixels in my sprites to mark pixels that should flash black and white, and I swap red with black and white every couple frames. So red shows up as flashing. It makes some of the animations, such as explosions, easier to do.
I've been on it for a week already and I'm probably going to finish it up in the next two days but hey I'm doing this!!
It's a micro-society simulator god-game kind of thing! Except you there's no real goal in game apart from those you set yourself! Why not try and make a micro-society of cat fanatics?! I dare you.
Here is what it looked like at the beginning of the jam:
I'm going to post it both on itch.io and here on the BBS when it's done so keep an eye out ;D
Also, you can follow ALL the progress on my Twitter @TRASEVOL_DOG! :D
(sorry the gifs are so big :S)
Enemies don't hurt you yet, but walls do, and the bosses do. :L
WARNING: There is nothing after the boss battle! The game just kinda ends and the sky scrolls forever.
Unfortunately, I didn't get enough of it ready to submit it to the Jam, and the date has passed and it won't be on Itch. Consider this my unofficial, late submission to LOWREZJAM 2016. yaaaay...
I will probably be refactoring some code. It uses far less memory than my Spaceball game (a game which actually has a memory leak). The downside is I have written the code to loop too much and it is causing occasional CPU spikes (I have achieved the opposite problem!). I'm learning some fun stuff though.
I have a few things I could optimize:
- Use a couple smaller tables so I don't loop through as many objects
-Only use the distance formula for round explosions, other things don't need it. Less math required that way.
Reduce the total loops needed (I might even break the rules and consolidate update code into the draw function, lols)
SO as usual I basically know what the project needs but I don't know if I have the time to work on it, so I'm posting the current version.
[Please log in to post a comment]