CPCRetrodev 2023 : Fitzroy Feels the Heat

[awergh]

Fitzroy Feels the Heat
Another CPCRetroDev has finished so it's time for me to write a few "short" thoughts on how it went and some analysis on what I did right and wrong. It looks like I did better than last year with a 10th place (it was 12th last year). I would have liked to do better than 7th (Fitzroy Dives Deep) but if you look closely at the rankings there were not many points between 10th and 6th place. I can also be satisfied that I am being consistent.

TLDR
This is my game for CPCRetroDev 2023 and an opportunity for me to provide some insight into how I thought the game went this year as well as technical detail about the implementation. Following this post there will be a few updates to the game and maybe some more detail on the fixes.

Game Download
The game and source code are on the itch.io page. I would attach it to the first post, but I can't edit the post later to add the updated versions. There are also screenshots there that you can look at.
https://awergh.itch.io/fitzroy-feels-the-heat

Ideas
For this year's game I began with two ideas. The first was an idea about manipulating body temperature and level temperature which I came up with in September last year (running is a good place for ideas). The second idea was an idea about collecting map pieces to find treasure. When I started work on this game, I couldn't decide which game idea to go with and instead decided I would take bits of both ideas.
However, as I developed the game, I focussed on the temperature idea as it was more interesting to implement then the treasure idea. The end result was that I built a game mostly about temperature but with a few treasure related things in it. The collecting of different items that you required as you progress was also a feature of the treasure idea.

I was concerned that the game might be less focussed because of multiple ideas combined but I don't think it diminished the game. I feel that I got the balance right, once the implementation begins the design will change based on what I find interesting or works well which may be something entirely different to the original design.

Development Process
My overall development process was the same as last year.
The game is written in C with cpctelera and I make use of wincpctelera for debugging.
I used Retro Game Asset studio to draw the graphics (unless I stole them from previous years, the more games I make the more there is to steal) and load the graphics into my map editor.

I wrote a new map editor specifically for this game to design the levels which are then exported to the game source tree. If you want to know more about my map editor, you can see my post about Fitzroy Dives Deep.
The main difference this year was that the map editor had to support smaller maps (including a slightly different number of tiles on screen) and provide some way to export castle positions on the main island map.

This is what the editor looks like.
You cannot view this attachment.

I also use Git for source control (source control is something everyone should do) and Azure DevOps for task tracking and building the game (probably too much work for anyone else).
If you have ever been wondered, the number below the game version number (1.0) on the menu screen is the build number.
Every time I push a change with git or create a pull request (PRs are part of my processing for tracking what I've changed\done) a build runs and it increments the build number that is shown on the menu screen.
You cannot view this attachment.

Map and progression
One of my goals for this game was to make the level progression non-linear. My previous two games were purely linear, but I wanted to try to do something different. I have attempted to do non-linear before with Fitzroy in the Dark, but in that game, it didn't quite work because I designed the progression of the game without considering that the game wasn't linear. The result of that mistake was that the difficulty curve was off, and you might be missing prerequisite items for the later levels if you did the levels in a different order to the order I expected.

To solve this problem, I took my inspiration from Commander Keen and implemented gates in the game. Each gate requires a certain number of levels to be completed before you can progress through to the next part of the game but the levels before the gate can be played in any order.

To explain how this works in my game I will detail the first gate and the first three levels works.
Each level teaches the player different concepts in the game.

1. Keys and doors
Coloured doors are opened by the matching key.
You cannot view this attachment.

2. Teleporters
A pair of teleporters are linked together to allow the player to instantly move between two locations (A and B). However, using teleporter B does not have to go back to A, instead it could be connected to teleporter C. This has a potential to be very confusing, but I don't think I went too overboard here.

The other feature of this map are CPCs which can be activated by using either a floppy disk or a cassette tape. This is effectively a switch that requires you to have the right item. I particularly like this because it fits nicely with it being a CPC game.
You cannot view this attachment.

3. Switches and doors
Toggle switches can be used to toggle open and shut linked doors (I think of these as electric doors as opposed to keyed doors).

One-way blocks only allow the player to move through them in a single direction. This is helpful for level design as I can force the player go where I want. I first used these in Fitzroy and the Confounding Labyrinth and implemented them here when I found a need for them when designing levels for this game.
(This year I did not do any toggle directional blocks that could change direction because I was running out of space. Although there might be a way to link a switch to a one-way block and alternate it between left and right; and up and down without having to design a dedicated object for it. Maybe next time I will try that.)
You cannot view this attachment.

As you can see each level introduces new concept(s) but there is no overlap with the other levels required to get through the first gate.
As the game progresses, I make use of features that have come before but only features I know the player has encountered based on what levels they have completed up to that point in the game.

This is what the main\island map looks like after completing the first three levels (each level is represented by a castle).
You cannot view this attachment.

In contrast to the last few years, I made the levels smaller. Previously I designed levels as 3x3 screens but this time I did 2x2. By making smaller levels I could have more of them, and this works better for a non-linear game. If the game only had six or seven levels it might as well be linear as there isn't enough levels to make significant branches in the level progression.

With the combination of smaller levels and a lot of different items and interactive objects I managed to create 16 levels where each level introduced something new. I've found that introducing new features in each level as you progress is an effective way to do level design and ensures there's always new things to discover.
However, it is possible that the game was a bit slower to introduce things then it needed to. The downside is that if you only played the first few levels, you would not have seen much of what the game has to offer. I think there is a balance to ensure the player gets enough new things as they progress to keep them interested as opposed to throwing too many things at them and overwhelming them.

The original plan for the size of the game was for 16 levels and then one final level that was split up in two parts (the two parts form an extra-long level). As I ran out of time and memory it got shrunk to 15 levels with the final level being one full size part and a second much smaller part. This was an acceptable compromise even if I did have to do an all-nighter to achieve the second part of the final level . 

Temperature
As I said in the ideas section, the main idea of this game is managing temperature. There are four temperatures to manage in the game: room temperature, minimum temperature, core body temperature, and maximum temperature. The way the idea manifests in the game is that you must pay attention to both your core body temperature and the temperature of the room.

These are the temperature changes that the player can make because of their actions in the game:
- Change your core body temperature up or down.
- Change your safe temperature limits (increasing or decreasing both minimum and maximum).
- Change the temperature of the room (level) up or down.

You cannot view this attachment.

The main part of the temperature system is implemented in the temperature cycle. This is a regular interval (implemented in interrupts) where the game will both adjust the player's core temperature and verify the player's core temperature is inside the safe temperature limits.

When the player's core temperature is being adjusted the game calculates the difference between the room temperature and the player's current core temperature. This difference is used to calculate the temperature delta which is how much the player's core temperature should be adjusted. The bigger the delta the more the player temperature will change. The room temperature being hotter than the player core temperature has a greater impact then if the room is colder than the player. Gradually the difference between the player and room temperatures will decrease as the core temperature gets closer to the room temperature.

Verifying the temperature limits is a simple check that the player's core temperature is within the safe temperature limits. If it is outside the limits, then the player loses 1 health. I considered changing this to a larger value, but I decided against it. I might still do it for hard mode instead for v1.2.
 
Temperature progression
During development I did not know how to implement the progression of the temperature features. It felt like I had built all these features, but they felt disjointed, and the game didn't flow well from one stage of the game to the next (I didn't have many levels at this time either). I wanted to ease the player into the temperature features without confusing them with unexplained deaths but didn't feel like I had the progression right.

During another run (great place for ideas) I came up with the idea of designing the levels of the games in phases.

Phase 1
This is the first three levels which serve as an introduction to the game before the player needs to consider the temperature.

Phase 2
Phase two is levels 4-12 where you are now making changes to the room temperature, your core body temperature, and your temperature limits (minimum and maximum temperature).

As you progress through this phase the safe temperature range from the minimum to maximum temperature will increase. Effectively this is levelling up the player as they go based on completing certain levels. Originally, I had planned for you to increase the limits all the way to the maximum (-127C to 127C) but I decided against this as requiring the player to manage the temperature limits made for more interesting gameplay and level design.

Phase 3
In the final phase (levels 13-16) you use your core body temperature to influence the world. I originally had an aura that would affect the cells around the player based on core body temperature, but I decided against this as there was not enough control. It also made level design harder because unintentional actions could prevent progress.

Instead, I implemented the temperature gun which affects the cells in front of a player based on the current player core temperature. For example, if the player is very cold the gun can turn water into ice. However, when the player uses the gun it changes their core temperature, effectively this is converting temperature into fuel for the gun. This is probably the most interesting mechanic in the game (and fun to design levels for) although most people probably won't experience it because it is at the end of the game.

Phase Summary
In phase one the player is introduced to the game without temperature having an impact. In phase two the temperature of the world affects Fitzroy. In the third and final phase Fitzroy affects the word with his core body temperature. Once I had the plan for the phases the level design fit much better together.


Gesture and Tribute
This year the gesture which was to Super Cauldron, and I implemented it by having a plant that opened and closed its mouth. I prefer a gesture that has a real impact on the game as opposed to being a graphic in the background.

In addition to the standard gesture there was a tribute to commemorate the commercial life of the CPC. There were some morbid suggestions like a tombstone, but I didn't want to do something like that. From the other entries there were a few examples of a picture of a CPC but I decided to do something more interesting. I decided I would include a gesture for each year from 1984 to 1993.
I chose 10 different games from 10 different publishers (one for each year). Super Cauldron was the game for that fulfilled 1993. The tribute itself is a screen at the end of the game which is filled with different sprites as you encounter certain things (items, enemies etc) in the game. If anyone wants a challenge, they can try to figure out what the other 9 games are.
You cannot view this attachment.

Game Codes (save state)
I knew that this game would be at least an hour long (I think it might be closer to 90 minutes, but I haven't tried yet). In my last two games I had level codes for choosing which level you can start from so you didn't have to start from the beginning every time. This system does not work for this game because the level progression is non-linear and there are items that persist across multiple levels.

In most non-linear games I have played (I'm thinking 90s MS-DOS games) you can save your game to file, and it will store your current progress and state. I have seen CPC games that save to tape (eg The Hobbit) but I didn't know how to do this and I suspected it would be both time consuming to implement reliably and inconvenient to use.

My solution was to implement game codes that contain both progress and state information. Not every piece of state is included (score is not included) but it includes enough that you can use it to save your progress for later instead of having to play from the beginning again.
The game save state stores the following:

1. The completed castles
This is two bytes where each bit represents a level that has been completed, this is what decided that there would be 16 levels to complete before reaching the final level.

2. Game inventory
The persistent items that the player can carry across multiple levels.

3. Player temperature (core temperature, min temperature, max temperature)
All the player temperature values as these values can change as a result of completing a level.

4. Island temperature
There was originally a plan for this to change based on what you did in the castles, but it never happened. It remained in the game state as I didn't want to change the codes.

5. Map piece count
As the player can carry multiple map pieces it became necessary to track this, I originally tried to calculate it from the levels the player had completed but it was more efficient to add an extra byte to every game code.

6. Checksum
In order to ensure that the game code hasn't been fiddled with there is a checksum. The encoding isn't exactly a secret since you can read the source code, but it makes it a little bit harder to guess the game codes.
 
This feature was initially intended to prevent the game from being too hard and too long (playing from start to finish is always harder than picking up from where you left off). However, it also became very useful for testing as I didn't want to have to replay every level just to get to a certain position in the game where the error could happen.

There is a downside to this system, the codes are 18 characters long which are easily mistyped.
The codes are 18 characters instead of 9 because I divide each byte of the state into two parts (4 bits each). Each pair of characters that is entered represents a byte in the game code.
You cannot view this attachment.

Improvements over previous years
Difficulty
One of the problems with my last game was that many people found it too difficult. As the creator of the game, I am a terrible judge of difficulty because I have become very skilled at the game. (I'm probably the only person who ever finished my previous two games on the hardest difficulty.) Two things that made last year's game more difficult were: the proliferation of spikes and the game timer.

To address the problem of spikes (or at least soften it), I didn't add any spikes until level six. Initially this was because spikes had not been implemented yet, but I decided this was a good design decision for the earliest levels. I have often used spikes as a crutch for level design, so it was good to avoid using them. When adding spikes, I try to make sure there is a route that is safe without pixel perfect precision, but I can't stop people going the wrong way all the time.

I decided that this game did not need a game timer as it would artificially make the game more difficult. It turns out that the temperature system sometimes acts as a timer. If the Fitzroy's core temperature is outside of the safe temperature limits, he will start to lose health. This means that when you start to lose health because of unsafe temperature you are on the clock to resolve your temperature, or you will die.

I'm sure an interesting level could have been made around the player having to collect health to stay alive because they have an unsafe temperature the entire level. I doubt I'll ever make it, but it would probably make for an interesting level with a faster pace.
 
Equipping items
In this game there is equipment that you carry across multiple levels. This is instead of having to find everything you need in every level. There are some items that do not persist like keys but the most important items such as the spade will persist.

One of the things I had to do was create a screen to choose an item and equip it. I have done a similar thing in Fitzroy in the Dark, but it was quite clunky. This time I managed to make an inventory screen that I feel is simpler to use (at least in my opinion).

One of the interesting bugs I fixed was that I had to make sure the game was paused the game timers while the inventory screen was open.
There are instances in the game where precise timing is required and opening the inventory screen was messing with the timers making it hard to ensure I could consistently complete the level.
You cannot view this attachment.

Building levels faster
Unlike last year where I didn't start building levels until October, this year, I started building the initial levels in September. This meant that I was not rushing as much to complete the levels and could get a real feel for how the game would play earlier. The decision to make the levels smaller also made it easier for me to build the levels.

Enemies
This year's game has more enemies than last year.  The change here is that enemies now spawn when you enter a room instead of only when you start the level. This means that I am no longer tracking enemies that are off screen. As such enemies are a little more performant and I can get add more enemies without too much slowdown (there is a little bit of slowdown, but it is acceptable).

Originally it was possible to dig holes with the spade and trap enemies (I wonder what game that was in  ). But I decided having tested all the levels without using this feature that it would make the game too easy, and I was better off using the memory for something else. Often respawning enemies can be frustrating but since you cannot actually kill the enemies, I don't think this is a problem in this game. An interesting side effect of this is that when you teleport within the same room the enemies will respawn. I don't consider this a problem, but it is an interesting side effect.
 
Things that might have gone wrong
Finalising levels
One of the mistakes that I made was that I didn't completely finalise the levels when I built them. I made sure they were fully playable but did not add the extra score items to make them complete. To save a tiny amount of memory I left the score items out. The problem was that on the last night I added the desired score items, this meant I needed to retest the levels again.
This was an unnecessary time sink of a couple of hours that could have been better spent elsewhere. If I had added the score items initially, I wouldn't have had to retest any levels and I could have considered them complete and final. If you look closely the score items disappear at about level 10 as I was not retesting the hardest levels again. This is something on my list of things to fix in v1.2 when I have the time to retest the levels and ensure that everything is as good as it can be.

Graphics
Its hard to know what to say about graphics. If I had better graphics, I would probably get a higher ranking as this is an area that I traditionally don't get many points (I haven't checked to see my points distribution yet). However, I did manage to avoid having anything that might be considered garish which was a problem for Xyphoe last year. I continue to make graphics that are clear and colourful, but I do not attempt to add extra detail to the graphics. I'm probably getting better at drawing the graphics, but I doubt it will ever be something I am good at as the technical details and level design are what I enjoy, and the graphics are the best I can manage quickly.

Colour palette and finalising graphics
I would like to say I learnt this lesson from last year and finalised the colour palette early on, but the reality is once again I left this nearly to the last minute. At least it was during the last day rather than the last night, but it was still late. As I only had one colour palette it was a bit easier than last year, but I could have done this earlier since choosing a palette mostly involved rearranging the colours and adding an extra brown. After choosing the palette I still had to fiddle with all the colours but that always happens due to my insistence on supporting the green screen. (My GT64 decided to be unhappy and deliver 0V but I have a spare, so it wasn't a disaster.)

Complexity
I'm not sure if this went wrong but it is a challenge for the implementation of the game.

Fitzroy Feels the Heat has a lot of complexity in the temperature system. This means that it is a less approachable game then other games. I had thought about adding a hints system, but I ran out of time and memory so didn't do this. Instead, the information is on the game page and the user manual (which most people don't read). I build games that I think are interesting and I don't want to completely avoid complexity as this could prevent me from building the game I want to design and play. The challenge is then how to ease the player into a game with significant complexity without overwhelming them with systems that they don't understand.
 
Bugs to fix
As always there are some bugs in the game that I have yet to fix. Usually, I try to fix bugs as I discover them but sometimes, they are not severe and can be left for later. Game breaking bugs such as crashes will ideally be fixed immediately (assuming I can figure it out, Nesu has been very good at figuring out this type of bug in previous years).

I considered the game to be one of the least buggy games I have made but there were some serious bugs still hiding that I need to fix (Thanks Nesu for pointing them out to me).

This is not a complete list of bugs, but it includes bugs that I will be fixing in v1.1.

Game hang on temperature death or quicksand death
If you die during the game from either temperature or quicksand the game will hang (death is a little bit too permanent here). This is caused by an infinite loop in the interrupts (my game breaking bugs are usually related to interrupts). This bug is the result of implementing a pause when you die, it highlights the danger of making changes near the end of development time when there is not as much time left to test changes thoroughly.
 
Switches and doors dead end
On the second screen of the switches and doors level there is a way for the player to get stuck with nowhere to go. When I played this level, I never considered someone exiting the columns without using the second switch. However, I have seen two people do this so I should provide a directional arrow to provide a way back in. If this was a later level in the game, I wouldn't be as forgiving but as this could be the first level played there should be some hand holding instead of forcing the player to exit the level due to a dead-end. This bug is the result of being too good at the game and not getting enough playtesting.
You cannot view this attachment.

Inventory equip key non rebindable
When using the inventory screen, you use the X key to equip an item. This should be rebindable but I never thought to check that it would be affected by changing the game action key to something else. This is a very quick fix but again would have been found by more testing.

What's next
Bug fix release (v1.1)
The next step is to fix any serious bugs in the game and release v1.1 of the game. If you know of anything that is broken or needs fixing let me know. This release won't add to or enhance the game but should resolve any game breaking issues or inconveniences.
 
Enhancement release (v1.2)
After the bug fix release there will be v1.2 which will include any useful enhancements that the game would benefit from. For example, every level should have score items for you to collect but currently only the first 10 levels have them. I am also most likely to expand the second part of the last level which is currently a single screen level. Assuming there are not any further bugs found then v1.2 will be the final release of the game.

MS-DOS port
As you might have been able to tell I have a fondness for MS-DOS games in the same way I do for the CPC. Something I have always wanted to do is write a game for DOS and this would be a perfectly good candidate for that. So far, I haven't built anything for DOS, but it is an aspiration that I might do it one day.

Things I didn't do
Having started with explaining my idea I thought I would mention a few more things at the end that didn't happen and why they didn't happen.

Many ideas around treasure did not make it into the game. The big thing I thought of doing was to collect the map pieces which would lead you do an X on the island map which you could dig up. Digging up treasure still made it in the game, but digging on the island didn't although you can still dig holes on the island if you want to.

Originally, I had planned for the player's temperature to be more persistent between levels. Initially when you exited a level your temperature would be the same as when you were in the level. However, I realised this would be quite difficult to implement in such a way that didn't get you in impossible situations. Instead, I decided that the temperature would be reset back to the default when you left a level.

As you might notice in the game that the island map has its own temperature. I had envisaged that as you progressed through different castles it would change the temperature of the island and unlock different parts of the map. In the end I did not do this via temperature but there are areas of the game that are only accessible after certain castles have been completed. While it would have been nice to use the island temperature, it turned out to be unnecessary. The important thing is that I ensured that no matter what order you play the levels in you should be able to complete the game.

Final thoughts
Phew you made it to the end (both for you reading it and me writing it). Naturally it is just as long as last year. I am very happy with how the game turned out overall. This is another solid Fitzroy game and while it didn't rank the highest (compared to Fitzroy Dives Deep) it was an improvement on last year and probably is the best Fitzroy game to date.
Looking at last year's post I promised a game with a greater number of smaller levels and that is exactly what I delivered. Maybe next year I can try out some RPG mechanics, but we will just have to see, by the time it comes to write the next Fitzroy entry I might be thinking of something completely different .

[ervin]

Thanks for the amazing write-up. I always enjoy reading about your dev process.
Great game too. I think it deserved to place higher than it did.

[awergh]

I have decided that I have a solid set of changes for a v1.1 release.

I was going to release it last night but when I played it I found out I had completely broken the game with one of my changes. 
When you complete a level it should reset the core temperature and restore the limits to what they were before starting the level or the limits should be increased if the temperature level up property was set. I had previously moved the temperature reset so it only occurred when you die from a level and not every time you exit or finish a level.
It turns out if the temperature is not reset the game gets harder and harder until it becomes impossible.
I played the game with a joystick for the first time and while it was harder it didn't seem impossible for the levels that I tried.

Thanks to Nesu for pointing out some of the bugs to me that I have fixed, especially the game breaking hangs.
The cause of the hang was one of interrupts (this usually is where I have game breaking crashes).

Previously when you die from losing health I used the plant timer to allow the game to wait for the death sound effect to play.

Code Select Expand

if (playerLives--)
{
    levelState = LEVEL_DEATH;
    gameRunning = FALSE;
    player.health = playerStartingHealth;

    // Reset the plant timer to use it as a delay.
    plantTimerCount = 0;

    // Play death sound effect.
    playSoundEffect(SFX_DEATH, CHANNEL_A, MAX_VOL);

    // Using the plant timer as a delay to allow the death sound effect to play.
    while (plantTimerCount < 580)
    {
    }
}
The problem with this is that when you die from quicksand or being outside the temperature limits that this code will be called from inside the interrupts.
This results in an infinite loop and the game hanging.

My solution was to move the code after the level has actually finished (outside the game loop).
It still provides the same effect of the player heating the death sound but it no longer can be called from code in the interrupt handler which resolves the problem.


v1.1 change log (Build 590)
This is the full change log for v1.1.
It only includes bug fixes which was my intention for this release.
There are probably a few more bugs to fix (let me know if you have any) but I also want to make a few more map and difficulty related changes that didn't quite make it into the game that I intended to do.

• Fixed bug where stationary enemies were not redrawn on activating or deactivating the metal detector.
• Allow player to exit final level part A back to the island map.
• Removed broken save code from exit dialog that is visible on the final level.
• Reset temperature limit and border colour on player death.
• Fixed game hang that occurs when dying from quicksand.
• Fixed game hang that occurs when dying from being outside of safe temperature limits.
• Added an extra directional block to prevent dead end on second screen of switches and doors level.
• Selecting an inventory item now uses action key instead of being hardcoded to X.

The updated binaries and source code can be found here if your interested:
https://awergh.itch.io/fitzroy-feels-the-heat/devlog/644174/fitzroy-feels-the-heat-v11

Thanks for the amazing write-up. I always enjoy reading about your dev process.
Great game too. I think it deserved to place higher than it did.

Thanks ervin I appreciate it, its hard not to find judging and ratings a little bit subjective as everyone has slightly tastes and experiences that shape how they enjoy a game.

[awergh]

Whoops, looks like I made a bobo in v1.1 and removed the code to generate save codes. 
Now I could wait for the other things I am working on but I didn't really want to wait for a week to provide this particular fix.

So I am doing what is essentially an emergency fix to resolve the regression from v1.1.

v1.2 Change Log (Build 593)

• Fixed regression displaying save code on exit dialog on island map.

Updated binaries can be found here:
https://awergh.itch.io/fitzroy-feels-the-heat/devlog/644773/fitzroy-feels-the-heat-v12

This time the change is only in Dialog.c

Code Select Expand

// Display the save code when exiting from the island map.
if (currentMap == MAP_ISLAND_MAP)
{
    cpct_drawSolidBox(memory, cpctm_px2byteM0(0, 0), EXIT_DIALOG_WIDTH_, EXIT_SAVE_DIALOG_HEIGHT_);
    drawSaveCode();
}
else
{
    cpct_drawSolidBox(memory, cpctm_px2byteM0(0, 0), EXIT_DIALOG_WIDTH_, EXIT_DIALOG_HEIGHT_);
}
In v1.1 I removed the logic for drawing the save code to fix an issue where an incorrect save code was displayed on the last level.

The v1.0 code was this, for whatever reason I didn't think there was a problem with removing the whole thing instead of only the currentMap is greater than 16 branch.

Code Select Expand

if (currentMap == MAP_ISLAND_MAP || currentMap > 16 )
{
    cpct_drawSolidBox(memory, cpctm_px2byteM0(0, 0), EXIT_DIALOG_WIDTH_, EXIT_SAVE_DIALOG_HEIGHT_);
    drawSaveCode();
}
It only goes to show I didn't do enough testing (same as my other regression that almost made it into v1.1).
Even if I did have automated testing I doubt it would have saved me but maybe it is a case of rushing a little when I shouldn't have, but I really do want to be finished so I can move onto different things.

[awergh]

I am now ready for another release. 
As promised this includes a number of small enhancements as well as some important bug fixes.
Turns out the game also had some more game breaking bugs that were a bit more subtle to find.

Important: Previous versions of the game had game breaking bugs for temperature progression and restoring game codes.
It is recommended to generate new game codes if you have previously played levels adjusting temperature.

v1.3 Change Log (Build 624)

• Reset temperature timer count before starting a level to make initial temperature cycle more consistent.
• Reset border to blue on completing game successfully.
• Display save code for final level B under game objectives on starting the level.
• Apply health bonus to level score before updating game score.
• Allowed enemies to walk on solid mercury.
• Allow save code to be used to restore into final level B.
• Expanded final level B to full size.
• Enhanced victory screen by adding bonuses and treasure sprites to victory screen.
• Allow player only to set explosives on certain empty environment cells.
• Added basic sound effect when walking over a temperature cell.
• Added additional items to all game levels.
• Set the temperature limit level value based on completed castles in the save code when restoring the game.
• Added extra cold temperature potion to ice map.
• Open temperature gun level gate on completing ice level.
• Moved cold potion on first screen of heaters level to prevent temperature damage on heaters level.
• Added temperature damage to difficulty (set temperature damage to 2 for hard).

The updated binaries and source code can be found here if your interested:
https://awergh.itch.io/fitzroy-feels-the-heat/devlog/650949/fitzroy-feels-the-heat-v13


The two game breaking bugs were to do with the way the game progresses your temperature limits.
As you progress through the game the temperatures limits (min and max) will be increased (effectively levelled up).
Due to an oversight on my part with game codes I assumed that there was one more level up then is actually possible.
This means that the game probably wasn't possible past the first 9 or 10 levels.

The second game breaking bug was that when you restored from a game code it did not set the temperature level based on the temperature limits for the player.
The result of this was that if you loaded the game it would have the correct temperature but if your character levelled up it would actually reduce your temperature limits because it assumed the player was on a lower level then they should have been.

Adding some code to restore the temperature limit from the completed castles in the same code resolved this.

Code Select Expand

void restoreTemperatureLimitLevel()
{
    u8 i = 0;

    // Start at 1 to skip island level.
    for (i = 1; i < LEVEL_COUNT; ++i)
    {
        // Check that the castle has been completed.
        // -1 to ensure that when i = 1 that we are comparing completed castles with 1.
        if ((1 << (i - 1)) & completedCastles)
        {
            // Check that the castle has the level up flag set and update the temperature limit level accordingly.
            if (level_objective_action_count[i] & MAP_PROPERTY_TEMPERATURE_LIMIT_LEVEL_UP)
            {
                ++temperatureLimitLevel;
            }
        }
    }
}
However if you have a dodgy save code there's nothing you can do and you have to play the game again to get a good code.
I thought about changing the save code to only include the temperature level instead of the temperatures but I prefer not to break every code (only some of them).

This is probably the final update unless there are some more bugs for me to fix.
I plan to continue my tradition and do a full playthrough on the hardest difficulty in a single sitting.
I suspect it might take a while (both the length of time to finish the game and the number of attempts to do it), probably best not to start now since it is 1:35AM .

[awergh]

Turns out I found another bug that I wanted to fix.
I only found one bug so this is probably the last release for this game.

v1.4 Change Log (Build 627)

• Fixed graphical corruption in the temperature mines level that was caused by the default environment cell being set incorrectly for the level.

The updated binaries and source code can be found here if your interested:
https://awergh.itch.io/fitzroy-feels-the-heat/devlog/672208/fitzroy-feels-the-heat-v14

Of course I can't just leave it there and want to add a bit of explanation about the bug.
Environment cells are used as the background cells in the map such as sand, dirt, lava etc.
The default environment cell is used for hiding things or when a cell is changed.

For example mines are hidden under the default environment cell and opening a door will change the cell to the default environment cell.

The cause of the problem is that the defaultEnvironmentCell was set to 0 for one of the maps.
#define MAP_TEMPERATUREMINESMAP_DEFAULT_ENVIRONMENT_CELL 0

Instead of to a correct environment value.
#define MAP_TEMPERATUREMINESMAP_DEFAULT_ENVIRONMENT_CELL 159

The problem with setting it to 0 is that when the code looks for the environment cell from the map is that it tries to retrieve a negative value from the environment sprites array.
This gives the wrong location in memory.

Code Select Expand

else if (cell & CELL_ENVIRONMENT_FLAG)
{
    // When the player does not have the map equipped it will show the default environment cell instead of the X spot.
    if (cellType == ENVIRONMENT_DIRT_FLOOR_X_SPOT && player.equippedItem != ITEM_MAP_PIECE)
    {
        // Default environment cell contains the environment flag so 128 must be removed from the value to get the index.
        // The extra 1 is because the environment starts at 1 in the editor but 0 in the array.
        return environmentSprites[defaultEnvironmentCell - 129];
    }

    // Draw environment cell (-1 because the spriteset will start at 0 index but the type will start at 1).
    return environmentSprites[cellType - 1];
}

On this screen it doesn't look so bad as you only see it once.
You cannot view this attachment.

On the next screen it occurs quite a few times (lots of mines) which is not so good.
It does however make the screen a bit easier but I still preferred to fix the bug.
You cannot view this attachment.

With the bug fixed all the cells shows regular dirt.

I am still working towards finishing the game in a single sitting on hard but I think it will still take at least a few more weeks.
Turns out you need at least two hours to finish the game (why did I make the game so long?).