2 months off-season and i was beggining to get sick of it, but it's finally here, folks, have fun!Play here!
or Grab the JAR here!
Quick info about it:
-You play using arrow keys to move, and A to shoot;
-You don't shoot without ammo (so try to conserve it);
-You must save ALL the santa helpers (the guys in green and red) to be able to exit;
-Killing the black guys are optional, but if you touch them, you die;
-You have infinite lives, but there's no checkpoints. When you die, you go back to the start of the level.
-Points are optional, try to reach 100% if you are a tryhard;
-7 levels, with some kind of boss at the end.
-Music wasn't composed by me, but i don't even know who did it (lmao)Valuable quotes and impressions:
"THIS MOTHERF**KING SANTA CAN'T SWIM FOR S**T WTF" - Some friendDeveloper-point analysis
This is probably my last game in Java2D. It's a fun, easy and all-around lib overall, but as you strive deeper into it, you see flaws and incapabilities.
Well, about the game. I was planning on making a some sort of Commander Keen/Dangerous Dave mashup, with a Christmas theme. I had ZERO experience on how to create a platformer, but i tried anyway;
I knew i had to use an array for the tiles. I set up everything nicely, with a camera moving instead of the world. Then the first question appeared. What about entities and world collision?
Again, i had no idea on how to create a platformer. My first thought was about assigning a tile to an entity, and do collisions based on the same array i used to assign the world. Result: If i wanted to fall down a gap, i'd need to move to the exact point where the tile below is empty. With a tile being 32x32 pixels and the entity being around 24x12, you don't need to be a math genius to realize you'd be flying around pressing left and right looking for that exact pixel where i would be able to fall down.
At this point my player code was full of hacks of magically-set numbers. Welp.
Some time later i thought: Why not use hitbox-based entities instead of tile-based entities? 1 hour later i had refactored the entire entity hierarchy with simple methods and clean code, working smooth as butter, and, suddenly, pickups, snowballs, creatures were suddenly precise and working as intended. Welp
Then for the next subject: Level generation.
The levels are just PNGs with the tile data on them, divided in 3 layers: Tiles, Background, and Entities. The game loads those images, convert the color data into tiles, selects a texture that is appropriate, depending on the tile and it's position, and that's it. So, in some way, the levels are automatically generated. Which is something cool, to be honest. But the downsides are something to be frowned upon as well:
Firstly, you can't hard-code a certain texture into a certain position (well, you can, but it wouldn't be a good practice);
Secondly, tile divisions are harder to do and almost never end up as expected, since you have to check the adjacent tiles to determine which texture should be in place;
Thirdly, code gets ugly and hard to read.
To fix this? Well, i could set up a different color for every texture, and then draw those colors to form a map. Madness? Indeed. In a world of game with miles and miles worth of levels, why would i resort on this painful and unproductive method of drawing little points on the screen? Yet i decided to stick with it. And start thinking about a custom level format.
However, this got me sad. Sad enough for me to rush the rest of the levels, skip some tilesets (and thus, levels) and just worked on the ending. About the ending: I thought the "boss" art was pretty cool, and i'm even considering on reusing some stuff in an improbable sequel. Who knows? Until the next Christmas.