News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

CPCRetrodev 2022 : Fitzroy and Confounding Labyrinth

Started by awergh, 13:02, 13 November 22

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

awergh

Fitzroy and the Confounding Labyrinth
As is my usual tradition it is time to write a "short" post (definitely not a whole essay :) , this is a lie :P ) about my thoughts about how I went this year in CPCRetroDev as well as what to do next and any bugs to fix. I don't think I'm ever going to submit an entry that doesn't have at least a few problems that I need to fix. Hopefully you can let me know about the problems I need to fix.

I did not do quite as well as last year, but I feel as satisfied with this game as last years, however there are as always areas that could be improved. Some of the things will be improved in the upcoming updates.

TLDR
This is my game for CPCRetroDev 2022 and I am detailing my thoughts on how it went this year. Following this post there will be a few updates and probably some technical discussion about the implementation and the bug fixes. (There is a lot of technical detail in this post as well.)

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-and-the-confounding-labyrinth

Original Idea
This game was inspired by the labyrinths in the Jack West book series by Matthew Reilly. Starting from a non-gameplay idea can sometimes be problematic as this is what I did for Fitzroy Goes Sweeping which didn't work out in terms of resulting in a compelling game. However, building a game about labyrinths translates to a CPC game much more easily than the more abstract idea of sea mines.

I didn't deliberately build this game with any particular game in mind, but I was probably influenced by the following CPC games which I played a bit while I was developing my ideas. These games include Gothik, Gauntlet and Deeper Warrens.

Initially I wasn't sure if the game was a puzzle game or an action game. I think it leant more on the action side of things but there are puzzle-based elements that must be figured out in the levels.

Development Process
The overall development process didn't change much this year, but I did write a prototype experimenting with jumping in a top-down perspective (I talk more about this under the Abilities heading). Actual development started at the beginning of July, and I worked on it consistently until the deadline, I find that it eats more and more time as I approach the deadline.

I wrote the game in C making use of wincpctelera for debugging.
I used Retro Game Asset Studio to draw the graphics and load the graphics into my map editor.

I wrote a map editor specifically for this game to design the levels which are then exported to the game source tree.

The map editor has a feature where I can quickly export the level as an image, I have gone into the git history and exported the first level into 10 images and made it into a gif (hopefully it isn't too fast). This should give you a little idea of how the level evolves over time. (I figure as it is the first level, I am not really spoiling what is in the game by showing the full level.)

You cannot view this attachment.

Wincpctelera
I cannot do a post without mentioning wincpctelera by Arnud. This always saves me a lot of time debugging and it has much better compiler times. The SDCC build time started to get a bit long by the end which was exacerbated by two things:

1. Using these compiler flags (thanks for last years tip) made the build slower but it saved almost 1KB memory, this downside was worth it as I did not encounter any side effects apart from a few warnings.

Z80CCFLAGS := --peep-file ${CPCT_PATH}/tools/sdcc-3.6.8-r9946/peep/z88dk_speculative_peepholes.def --max-allocs-per-node 10000 --opt-code-size

2. I almost always do a clean build as in the past I have had issues where I would get odd behaviour if I only did a partial build.

make cleanall all

The only thing to be careful of is that the wincpctelera version is slightly faster so something that is possible in the CPC version may not be possible in the Windows version however it is not intended as an official port, so this isn't something I've tried to fix.

You cannot view this attachment.

Bugs I know about
Sound crash
There is an intermittent bug where the game will crash back to basic, and the sound is messed up when it happens (last year had a similar bug). This year I used Arnaud's newer interrupt safe code, but I did wonder if the issue was related as it appears similar. (I did not try Arnaud's code last year as I had a workaround that solved the issue.)

You cannot view this attachment.

Hedge cell draw bug
The player uses a machete to destroy cells in the hedge maze. I intentionally added a delay to prevent the player from accidently destroying cells. You can see in the screenshot below the blended sprite of the machete and the hedge block (first time I have used blended sprites). The bug occurs when the blended sprite is cleared. Once it is cleared the game will redraw the cell in the map every time you change room (only once when you change room, so this is a very minor bug).

You cannot view this attachment.

Hedge Maze uncompletable
In the hedge maze level (level 5) it is possible to get into a situation where you cannot finish the level. To finish you must use every machete to destroy certain hedge blocks. However, it is possible to end up being one short and not be able to finish. Unfortunately, this happens near the end of the level which feels a bit unfair. This is more of a map design issue rather than a bug.

There is a slight conflict in the design on whether the player having to figure out the solution is a bug or a puzzle. I am leaning toward bug because of how late it happens in the level. A similar thing happens in the first screen of the level but it's the first screen (see previous hedge maze screenshot), so I don't feel that I need to change it. Feel free to tell me that I am wrong though. This was on the list of things to fix until the end where I decided it wasn't game breaking and could be fixed later.

Projectile drawing bug
There is an issue with drawing over the projectile trails. The way the projectiles work is that it will save the graphics memory that the projectile currently resides in which will be used to restore the background as the projectile moves. The problem is that if projectiles are on screen and the player dies this saved graphics memory will be redrawn on the screen when you respawn at the start of the level. I suspect this was caused by a late memory optimisation, but it wasn't severe enough for me to investigate it.

Improvements over previously
I noticed that there were some things that I had done in previous games but improved on them this time. I have a general goal to always be improving but it is interesting to see some smaller areas where I made improvements. Still plenty of room for improvement with some of these though.

Colour palettes
This is the first time since Fitzroy and the Power Wells that I have included multiple colour palettes in the game where different levels use different colour palettes. I was moderately successful, but I did end up with some graphics that are only useful in one palette. It would be better if I could reuse more graphics across different palettes and save a bit of memory.

An improvement this time was that I included the palette in the map (this is an index 0-2) which is specified from the map editor. The more I can specify in the map editor the better as it gives me greater flexibility.

There are three different palettes that were intended to drive the theme of the levels: sand, natural and lava.
The first 8 colours are the same for each palette, the 9th colour is the background colour for the palette. I use this colour for the background of the player and item sprites instead of masked sprites. The next five colours are specific to the individual palette (although as you can see there is some duplication between the different palettes) and the last two for colour cycling the lava and water.

You cannot view this attachment.

Here is the colour palette with the full set of graphics (there were minor changes to this set of graphics but mainly for the hud graphics).

Some of the graphics did not get used in the game and I will probably remove some of the unused graphics to fit an extra level into the game. Another challenge was that there are some water sections in the game which I wanted to use with multiple palettes and have graphics that fit the water theme.

Sand graphics
You cannot view this attachment.

Natural graphics
You cannot view this attachment.

Lava graphics
You cannot view this attachment.

Green palettes
Something I like to do is support the green screen monitor (GT64\GT65). Realistically most people don't use the green screen and only a few people use it some of the time. However, as I have a GT64 sitting on my desk I like to support it properly. To test it I wrote a little bit of code to display all the graphics in the game and then cycle between the colour palettes (the screenshots above and below are from this). I naively thought that I could get away with one green palette, but it turned out I had to have three green palettes, one to match each of the colour palettes. It took me about four hours to determine the colours for the palettes. This would have been fine except I left it to the last minute (because of course I did).

CPCEC is pretty good for displaying green screen (better then WinAPE) but the ultimate verification was the real GT64 where the issues are slightly more pronounced than this. (I would not be surprised that if every GT64 is slightly different, but I didn't check on my other GT64.) In the screenshots below you can see the before on the left and the green palette on the right. It was mostly playable without the changes except for water where black and blue are way too close to each other. The game is hard enough without making sharks and sea urchins invisible :P .

Sand graphics in green
You cannot view this attachment.

Natural graphics in green
You cannot view this attachment.

Lava graphics in green
You cannot view this attachment.

Palette Colour Cycling
I used palette colour cycling to animate the water and lava. I have done this with Fitzroy in the Dark but in that instance, I cycled four colours in the palette instead of only one here (two if I could both water and lava as they each use their own one colour). The effect works OK but probably looks better with lava then water. The crumbling screenshot includes the water palette colour cycling (framerate is a little bit lower though).

Timer
I implemented a game timer in Fitzroy and the Missing Chair, but I ran out of time to determine the amount of time for each level. Instead, I turned it off as it was not core gameplay. This time I succeeded at adding the game timer for each level. When implementing a game timer, it is important to add it as early as possible to be able to test the levels with it instead of trying to add it later. The level time probably needs more work as I got very good at the game and have enough time but someone new to the game may run out of time. I handled this partially in difficulty options by giving you more time on easy when collecting hourglasses, but more work is required.

Enemy Projectiles
Both this game and Fitzroy and the Power Wells included turrets. Turrets shoot projectiles which means that both the player and enemies need to support projectiles. This game uses a simple array to store the state of the projectiles.
Fitzroy and the Power Wells made use of a doubly linked list to dynamically create and destroy projectiles. The lesson from then (and applied in every game since) was that replicating higher level constructs and object-oriented programming is not necessarily a good idea.
However, I still make use of a few structs that emulate inheritance in the form of Player and Enemy structs that inherit from the Actor struct. This is useful as it allows greater reuse of code between Player and Enemy. (No linked lists though  :) .)

For the projectile state array, I limit the game to four projectiles where the first element is always the player projectile. This ensures the player can always shoot but enemies may not if there are many on the screen. This is not a real problem though as there is too much slowdown with three or more projectiles on screen.

Crumbling Blocks
Fitzroy in the Dark had the concept of cracked tiles that you could only travel on once before they became blocked. I thought that was a cool feature, but I doubt anyone encountered it as it was in the last level. (I don't think anyone actually completed that game from start to finish, myself included.) In this game I had the concept of crumbling blocks that would crumble to something dangerous (chasm, water or lava) the more you moved on them. (I only realised the similarity to the cracked block feature much later.)
You cannot view this attachment.

To support this feature, I implemented a simple queue. I mentioned the dangers of higher-level constructs earlier, but a queue was the right choice here. Every time the player moves onto a crumbling block the map positions are added to the queue. After some interval the cells are transitioned to the next crumbling state. The queue has four elements (the number of cells the player can occupy at a time), when the queue becomes full it will transition all the cells before clearing the queue and adding the new cell. The result of this is that when you move across a group of crumbling blocks it can transition the cells through the states fairly quickly.

You cannot view this attachment.


I had originally envisioned the cells crumbling when you stood still but I had problems with that implementation and found I didn't really need more reasons to hurry the player. There remains some inconsistency with this feature, when moving across a group of crumbling blocks it may not have the same result every time (this was particularly obvious when testing a screen multiple times during testing) but with sufficient testing this is manageable. One solution to this could be adding cells that clear the crumble queue, but I don't think I need it at this stage. (Tinkering with core gameplay features is something I would want to be very careful with.)


Continues onto post 2 as I ran out of attachments.

awergh

Things that might have gone wrong
I can't only talk about where I made improvements on what came before. A major part of this writeup is to think about what went wrong. The reality is that I learn more from my mistakes then my successes. If I try too hard not to make any mistakes, I could easily end up playing it too safe and end up with a game that is too samey.

Graphics
Graphics have never been my strong suit as I am far better at the technical details then the more artistic details. There were a few different problems that I had with the graphics.

Finalising the graphics
I left finalising the graphics until far too late. It was about 2am on the final night when I considered the graphics final. This was partly because I wanted to adjust for the green screen palette, but I had also planned to update a few of the graphics such as the main spike graphic which was recycled from last year. In the end I didn't update or improve any of the graphics except where it enhanced green screen support. Getting the graphics done earlier would have saved me from allocating precious time at the end that could have been used for something else. However, as much as I would like to design all the graphics at the beginning sometimes the best ideas do not come until later which means I am usually adding new graphics at least until the last month of work.

Dullness
I had a concern that the background colour was too dull. I thought the lava grey was good and the natural green was fine. However, I was not completely happy with the pink sand background. The reason is that some of the screens seemed a bit dull to me and maybe I should have used orange or a different colour instead. Ideally, I should have been able to use a light yellow sand colour but as Fitzroy is partly yellow and some keys are yellow this does not provide good contrast.

Pink background
You cannot view this attachment.
You cannot view this attachment.

Orange background
You cannot view this attachment.
You cannot view this attachment.

Pastel Yellow background
You cannot view this attachment.
You cannot view this attachment.

Pastel Magenta background
You cannot view this attachment.
You cannot view this attachment.

Garishness
It is funny that I can talk about both being too dull and too garish with the same graphics. I briefly worried about this but figured it was either not much of a problem or I had so little time remaining that there was nothing I could do about it. Turns out at least Xyphoe thought it was a bit garish, I think the problem is mainly with the green background colour. Perhaps I should have focussed more on this as I agonised over the sand (pink) and didn't think much about the green.

Difficulty
Last year I made a game (Fitzroy Dives Deep) that was a little bit too hard. This year I repeated the feat by doing the same thing again. I suspect that the game might be more difficult than the last one, but other people will be a much better judge of this. The game has less levels than the last year (only six as opposed to nine or ten) but the levels are fuller resulting in greater difficulty because I don't want empty levels (Fitzroy in the Dark had this problem). The first level is the easiest and the last level is definitely the hardest, but I suspect that the difficulty curve is on the steeper side.

Spikes
This really extends from difficulty. I think I relied on spikes as a crutch for difficulty. I tried to always give you an option to line yourself up, but it seems people have a tendency not to notice that route and try for pixel perfect precision to get through tight spaces. Also, some of the spike traps can kill you almost instantly if you're not paying attention. I'm not sure if this is a bug or a feature, on the one hand I should have enabled the invincibility timer for spike traps but on the other hand it allowed for a greater variety in gameplay.

After I made the first two levels I added a dangerous plant, this is much like standard spikes, but you can shoot them with your arrows. This helped improve the game immensely as I could give the player an alternative to navigating the level correctly (and shooting becomes much more important). Unfortunately, they don't show up until level three as I did not return to make any changes to the first two levels after making the later levels.

Abilities
Initially when thinking about the game design I wanted to put in jumping. Turns out if you create a top-down game and add jumping it means you need a height map and track Z coordinates. This seemed like a lot of work so instead I added one-way blocks to divide sections of the level in the same way multiple heights would.

As a replacement for jumping, I considered as a short-range teleport ability (blink). The idea was that the player could blink across certain dangerous areas to solve the puzzles in the level. While I thought about this I never got as far as to start implementing it. If I had another ability for the player I may not have needed as many spikes in the game. We will never know if I was right or wrong, but player abilities are something to consider in future.

Overly similar to last year
I don't think this ultimately was a problem but earlier on I was concerned that this game was a bit too similar to Fitzroy Dives Deep.

There are quite a few similarities between the two games.
·        Both games make heavy use of lining yourself up to avoid the spikes.
·        The levels are made up of 3x3 screens where you usually must solve a particular screen to progress the level.
·        Similar interactive features such as switches, doors and spikes.
·        Four directional movement (only in the water sections of Fitzroy Dives Deep)

I don't ultimately think they are that similar, but it was a concern during the project that I might be playing it too safe by leveraging off last years success. As it happens, I think that if you are good at one game you will be good at the other because of the way spikes work in both games.

Movable blocks
The game includes a mechanic where you pick up a block and drop it to fill a chasm or activate a pressure plate. I intentionally put extra detail about this on the itch.io page and the user manual as I found this feature slightly clunky. It might have been improved by having a separate key for dropping the block from the action key, but I also found the design where you had to drop the block before you could use an interactive object or shoot was interesting.

Feedback would be useful here as I feel this is the least obvious feature in the game. The original implementation was a block that you could push around but I changed it to an item to save memory (1.5KB). (See the itch.io page for screenshots of this.)

Possible lessons learned
I wrote a section for lessons learned last time but I'm not sure if I can say I have learnt them unless I successfully apply them to next years game instead of making the same mistakes again. Think of these as possible opportunities for future improvement.

Finalise graphics and palette(s) earlier
I should be focussing on bug fixing and levels at the end of development and not be spending time adjusting the graphics. I should be more definitive about graphics and not dither on whether to make changes. I either end up doing it at the last minute or skipping it because time has run out.

Build a real level sooner
It is normal to build test levels to try out all the level features but until you make a real game level it is hard to get a feel for what the game is like. I didn't start the first real game level until the 9th October. By doing this it means there is no time remaining to fix the game if there are serious design issues. I think I got away with doing this (and last year as well) but if I could have had a real level much earlier, I might have had an opportunity to take the game in a different direction.

There is the problem that not everything is implemented but it just so happens that the first level of the game only has a small subset of all the game features so this should not be a blocker.

Difficulty
There isn't much more to add that I haven't already said but I somewhat ignored some advice that parts of the game were too hard because when I build the levels in mid-October, I really don't have time to make any changes.

What's next
The immediate thing to do is fix any bugs in the game. I have listed the bugs that I know about, but I'd like to know of any others in the game that should be fixed. I always want to get the game in the best state before I move on from it.
After bug fixing, I have some features that got cut at the last minute because I ran out of time.

Checkpoints
Last year I added checkpoints to the game to make the game easier without redesigning the game or levels. I think checkpoints would work again but there are two things to consider.

1)      The player needs to have sufficient time to complete the level from the checkpoint position they spawn into the level. This can be resolved by ensuring the player gets a confirmation whether they want to resume and giving them the same amount of time as when they started the level.

2)      The second problem is that some of the player's actions cause changes to the environment of the level (eg crumbling blocks preventing the player going somewhere). The only real way to handle this is carefully placing the checkpoints in a position that prevents the player getting in an unwinnable position.

Neither problem looks insurmountable so I will implement this in v1.1 or v1.2.

Item variety
You might notice that I tend to use the same item repeatedly in the level. What I really need to do is go through each of the levels and add some item variety. It is a bit boring to only have pears on one level and corn on another. This is easily fixed and some of the unused items can be given a purpose in the game.

One more level
I had envisioned making a game with seven levels. My original plan was for a final level that came after the lava islands level. Turns out I made the lava island level super hard which meant it served perfectly as the last level. I still have an idea for a new alternative level which can fit before the lava island level but will not be as big as a normal level. The game does not need more levels, but I have a level feature I want to use (but haven't used in any other levels) for a small (2x2) level before the last level.

Projectile Colour
Turns out with a red projectile when you shoot it over the lava it isn't very visible. It is only a slight problem on one of the levels, but it is something I want to investigate.

Time adjustments
Time was a fun thing for me to add but it does make the game a bit harder for a newcomer. I need to adjust time to provide a bit of extra time on normal but maybe less on the hardest difficulty. I am also considering a practice mode that has either significantly more time or infinite time.

Other editions of the game
Easy version
During development my niece and nephew played some of my test levels. They thought these were wonderful, but they don't really provide much in the way of gameplay. The actual game levels are too hard for them as they tended to die to spikes or run out of time. I plan to build several more levels for the game that are easy enough that they will be able to complete (or make significant progress).

However, as these levels will not fit the game (not enough memory and does not match the difficulty of the other levels) I will instead build another version of the game with the new easy levels. I probably only need 3 or 4 levels, but this will probably take a decent chunk of time and will happen after I have fixed the bugs and added the feature I want to add.

I haven't looked into how I will do this yet, but I was hoping to use a build variable to enable some guards (eg #ifdef EASY_VERSION) which will allow the game to be build both as the standard version and the easy version. I am not under any circumstance maintaining multiple codebases.

Any suggestions on the name are appreciated, in many ways this is like a second episode for the game like many shareware titles used to do.

Community version
I have had this thought for a while. I like to build an editor for each game (I'm sure you have noticed this 😊 as I usually mention it somewhere). I could provide the editor for other people to use. In theory people could build a bunch of levels and I could create a cpcwiki version of the game.

The trouble is that building levels takes a lot of time and you really need to be able to playtest a level. This means that to be effective you really need to export a level and compile it into the game yourself. While I can compile levels for anyone who wants to do this, I suspect it might require a lot of back and forth. I doubt there would be enough interest for this to happen but maybe one day we can make it happen. Let me know if your interested in doing this.

MS-DOS port
As mentioned earlier I have a Windows version of the game using wincpctelera but it would be nice to actually port it to another platform. For me the platform that interests me would be an MS-DOS port using Allegro 4 as a replacement for CPCtelera. I have no idea if I will commit to doing this but maybe one day it will happen with this or one of my future games.

Final thoughts
Congratulations you made it to the end, this was even longer than last year. I am happy with what I produced, and I think I succeeded at implementing my original idea. Even though I am slightly disappointed this is still my second most successful game (at least if you consider the ranking the indicator of success). Hopefully next year I can learn from my mistakes and produce a playable first level much sooner. I have an idea for a game with a greater number of smaller levels, but you will have to wait until next year to find out.  ;D

Nesu

Congratulations for your new game!

Quote from: awergh on 13:02, 13 November 22Sound crash
There is an intermittent bug where the game will crash back to basic, and the sound is messed up when it happens (last year had a similar bug). This year I used Arnaud's newer interrupt safe code, but I did wonder if the issue was related as it appears similar. (I did not try Arnaud's code last year as I had a workaround that solved the issue.)

I think the problem could be the same as last year  :) :
You are using PLAYER_ARKOS_STOP_IT() outside interrupts. PLAYER_ARKOS_STOP_IT() and PLAYER_ARKOS_PLAY_IT() are meant to be called inside interrupts (or having interrupts disabled). For callings outside interrupts use PLAYER_ARKOS_STOP() and PLAYER_ARKOS_PLAY().

I think you just need to change stopSound() at Sound.c to
void stopSound() {
soundMode = SOUND_MODE_OFF;
PLAYER_ARKOS_STOP();}

Also noticed in a compiler warning that comparison is always true in line 977 in dropBlockItem() at Player.c.  "If (cellY>=0) ..." cellY is a u8, always >=0. Comments suggest it should be something like "If (cellY<255)". Anyway, I don't know if the check is really needed.

ervin

Wow @awergh, that's a heck of a write-up!
Budding developers can learn a lot from it.
I wish I had the discipline to keep that sort of info about my dev process!

awergh

Quote from: Nesu on 19:54, 13 November 22Congratulations for your new game!

Quote from: awergh on 13:02, 13 November 22Sound crash
There is an intermittent bug where the game will crash back to basic, and the sound is messed up when it happens (last year had a similar bug). This year I used Arnaud's newer interrupt safe code, but I did wonder if the issue was related as it appears similar. (I did not try Arnaud's code last year as I had a workaround that solved the issue.)

I think the problem could be the same as last year  :) :
You are using PLAYER_ARKOS_STOP_IT() outside interrupts. PLAYER_ARKOS_STOP_IT() and PLAYER_ARKOS_PLAY_IT() are meant to be called inside interrupts (or having interrupts disabled). For callings outside interrupts use PLAYER_ARKOS_STOP() and PLAYER_ARKOS_PLAY().

I think you just need to change stopSound() at Sound.c to
void stopSound() {
soundMode = SOUND_MODE_OFF;
PLAYER_ARKOS_STOP();}

Also noticed in a compiler warning that comparison is always true in line 977 in dropBlockItem() at Player.c.  "If (cellY>=0) ..." cellY is a u8, always >=0. Comments suggest it should be something like "If (cellY<255)". Anyway, I don't know if the check is really needed.
Whoops, that makes sense. Last year I used stopSound in interrupts and I used the interrupt safe version without realising I made a mistake. I have only encountered the problem occasionally so I will assume that will fix it. Thanks for once again pointing out the solution to my game crashing bugs although it was a bit easier this time ;D .

I have a bad habit of ignoring compiler warnings. < 255 or even < 240 should fix the warning. I don't think it can happen in any of the game maps because I usually have a border at the top of a map but it was probably possible in the test levels.


Quote from: ervin on 06:32, 14 November 22Wow @awergh, that's a heck of a write-up!
Budding developers can learn a lot from it.
I wish I had the discipline to keep that sort of info about my dev process!
Thanks, I didn't expect to write quite this much. I started with a few headings and then I had further thoughts to write about so it kept expanding.
While I did write this over the weekend I am fairly disciplined about how I make code changes and track what I am doing as if it was a software engineering project which probably makes it easier to detail my process and what went into the game.

andycadley

I'm not sure you have to have a full height map and z-coordinates to handle jumps. Often you can cheat because the effects of jumping are only limited to certain types of tile. So if a player steps onto a hole they die, unless the "jumping" flag is set. Similarly, stepping into a crumbling tile triggers it unless the player is "jumping" at the time. If the consequences are that limited, you can easily get away with a simple flag and logic applied to specific blocks.

awergh

Quote from: andycadley on 10:31, 14 November 22I'm not sure you have to have a full height map and z-coordinates to handle jumps. Often you can cheat because the effects of jumping are only limited to certain types of tile. So if a player steps onto a hole they die, unless the "jumping" flag is set. Similarly, stepping into a crumbling tile triggers it unless the player is "jumping" at the time. If the consequences are that limited, you can easily get away with a simple flag and logic applied to specific blocks.
Yes you're probably right that I could have cheated to do this.
Jumping over a chasm could work fairly easily, my idea for split levels is what I would have had trouble implementing, the jumping itself could have been done.
As long as the player sprite changed when they jumped it should provide enough feedback to the player for it to work.

I would still need a z velocity for the player which would drop to zero over the course of the jump but I could check if the player is in chasm cell and z velocity is > 0 then player can continue moving. Sounds like I was a bit hasty to dismiss it but thats OK I can revisit the idea again sometime in the future.

awergh

The game is now ready for the v1.1 release.
I have fixed the bugs that I know about. I haven't added any features or improved the difficulty as I prefer to get the bugs out of the way before I get onto the interesting stuff. The danger here is getting bogged down in bugs and getting demotivated but they were not difficult to fix and I did not spend too much time on it. Having spent so much time on the original release it is important to have at least a bit of a break before working on updates.

I have attached the game here for the lazy but you can grab the updated game (v1.1) and the source code from the itch.io page. Hopefully I won't take too long to do the v1.2 updates but it remains to be seen. If there are any bugs please let me know.


v1.1 Change Log (Build 531)
  • Fixed bug where entering mid bottom screen of hedge maze with a machete caused hedge maze level to be uncompletable.
  • Fixed bug where a projectile shaped hole would appear in item when dropping an item block on top of a projectile.
  • Changed projectile to yellow when over lava.
  • Fixed bug where projectile background drawn after player death.Prevented dropping an item block across a room boundary.
  • Fixed bug where the player would disappear if they tried to move over screen edge at top left of map (first and last levels).
  • Changed to PLAYER_ARKOS_STOP in stopSound() instead of PLAYER_ARKOS_STOP_IT to fix arkos related game crash.

Quote from: Nesu on 19:54, 13 November 22Also noticed in a compiler warning that comparison is always true in line 977 in dropBlockItem() at Player.c.  "If (cellY>=0) ..." cellY is a u8, always >=0. Comments suggest it should be something like "If (cellY<255)". Anyway, I don't know if the check is really needed.
Thanks for your suggestions and it turns out the code here didn't do what it was supposed to anyway (stopping you from dropping the block across a room boundary).
It should instead have been this to:
if (cellX < SCREEN_TILES_X && cellY < SCREEN_TILES_Y)

awergh

The game is now ready for v1.2. This is a bigger release then the previous one.
This is update is focussed on improving difficulty (both in terms of making it easier and scaling the difficulty) and adding checkpoints which got cut from the final game due to running out of time. A decent number of bugs have also been fixed.

The game is probably still a bit hard but with the addition of checkpoints, extra difficulty options and some softening of the difficulty it should be easier to make a decent amount of progress. I didn't quite get everything I hoped done such as an extra level but I ran out of memory so that remained cut. I would still like to make some easy levels in a extra version of the game but I haven't started anything for that (had to finish v1.2 before I thought about that).

This is probably the final standard version unless there are some bugs I don't know about.
Let me know if there is something I should fix requiring a v1.3.

I have attached the game here for the lazy but you can grab the updated game (v1.2), user manual and the source code from the itch.io page.

v1.2 Change Log (Build 580)
  • Fixed bug where you could get through a door with the wrong key.
  • Fixed bug where score was not restored to level start score if checkpoint was rejected.
  • Change border to orange when all the artefact pieces are collected.
  • Only give time bonus on normal and harder, double the time bonus on brutal.
  • Update game score with current level score on exit game with escape key.
  • Display high scores at end of game session after updating scores.
  • Allow use of interactable while carrying block.
  • Initialise projectile queue values to 255 to fix turrets not firing projectiles due to conflict with first enemy index.
  • Retain level score on resume from checkpoint.
  • Update game score with current level score on game over death.
  • Changed hourglass time to 22 seconds on brutal difficulty.
  • Changed hourglass time to 30 seconds on hard difficulty.
  • Changed hourglass time to 38 seconds on normal difficulty.
  • Changed hourglass time to 50 seconds on easy difficulty.
  • Changed starting lives count to 3 on hard difficulty.
  • Changed starting lives count to 4 on normal difficulty.
  • Changed starting lives count to 5 on easy difficulty.
  • Added greater item variety to all the game levels making use of previously unused items.
  • Trigger invulnerability timer on colliding with spike traps if difficulty is normal, easy or practice (hard and brutal will not trigger invulnerability).
  • Added remaining level time as a bonus on completing the level.
  • Added practice difficulty with extra time for hour glasses (as compared with easy).
  • Added hard difficulty (this is the same as normal except with checkpoints disabled).
  • Added brutal difficulty (this is same as the former hard difficulty except with checkpoints disabled).
  • Optimised difficulty selection code to save memory.
  • Reordered levelState if statement to fix level respawn on death bug.
  • Adjusted crumbling blocks to make lava island level slightly easier.
  • Add checkpoints to all game maps.
  • Add additional time on restoring checkpoint if remaining time less then starting amount for the level.
  • Display restore dialog on started level from checkpoint.
  • Added checkpoints (including graphics) to save your progress in the game levels.
  • Removed unused tile graphics.
  • Removed unused environment graphics.


awergh

As with last year I decided to complete the game on brutal difficulty in a single sitting.
This turned out to be a little bit harder then last time (especially the last two levels) as I took 14 attempts over a month to do it. ;D
You cannot view this attachment.

I did it without losing a life and collected all the coins so I got the bonus (nice to know this feature works for real).
You cannot view this attachment.

As with last time here is the WinAPE recording of the playthrough of it.
So if you have an hour to spare and a keen interest you can watch it including my mistakes (I don't really expect anyone to watch it but I like having a recording of it).
fitzroy7-v1.2-winape-recording-brutal-complete.zip

Level codes
In case anyone is interested here is a list of all the level codes.
You can find out what you were missing if you didn't finish the first level but the later levels are much harder.
1 (Intro) aevcz
2 (Switches) eizgd
3 (Teleporters) imdkh
4 (Water Island) mqhol
5 (Hedge Maze) qulsp
6 (Lava Island) uypwt

Powered by SMFPacks Menu Editor Mod