Burn It With Fire!!
Description
Survival platformer where you play as a fire wizard trying to survive as long as possible as ninjas swarm from all directions. Jump between platforms and fire a massive torrent of fire at your enemies.
Influenced strongly by Astroboy’s laser.
Challenges encountered
Everything was coded close to the hardware, the limitations had to be taken into consideration, no loading lots of textures and animating through them. The separate types of memory were utilized to allow for nice backgrounds and UI, whilst letting the character and enemy sprites have a varied set of different animations. This was the main challenge with the GBA.
The physics handling was AABB and point collisions to check where they are on the platforms. If the speed of interactions was to be increased this would have needed to be increased to allow for sweeping collisions, but this was out of the scope of this program.
Cool Code
The GBA stores a sprites values in an array of uint16_t attributes. Using Nand operators and a few defines we can store multiple bits of information easily in GBA memory.
One of the odd problems with GBA and its memory system for sprites, is that going into the negative for a sprite position can cause errors. The other factor is that you want to keep the position accurate to allow for collisions. This was fixed by keeping the stored position fixed, but offseting the value passed to the sprite to allow for accurate positions. This is a common problem on the GBA but easily fixed, this is part of a larger code base so may be harder to discern.
Use the ternary operator (?) and only pass the valid value, this is obviously not fool proof, but outside of this most likely requires a game redesign. and it nicely allows sprites etc, to be partially off screen with little worry.
// Ensure position is within valid range for sensible values, less than -512 will cause positional and texturing errors.
ATTR1_X(position_x_ < 0 ? position_x_ + 512 : position_x_)
One of the nice features on this project was the various different animations, this was not as easy to do as it is on modern hardware due to the limitation of available sprite sheet memory space. This limitation resulted in devising a normal state machine system. but with an added texture switching element to allow for multiple sprite sheets.
switch (state_) {
case walking: {
playWalkingAnim(walk_initial_frame_, walk_final_frame_, idle_initial_frame_, idle_final_frame_);
break;
// etc…
// update game logic for character
updateCharacter();
// progress animation and prepare for next frame.
updateCurrentFrame(game_time);
Products used
