My devlog posts seem to be getting further apart - I intended to post one earlier but was always either too busy to do it, or not in the mood when I did have time. However I'm here now
Factory level finishedThe factory level that leads up to the recently-added boss fight is now done, making use of the
switch block mechanic that I recently brought back from the dead. I had bursts of level design inspiration mixed with lulls where I had no idea what to put down - but got there eventually. I consider the level to be just a first pass as it'll likely have some polishing at a later date, but good enough to move on from for now at least.
Red Eye event timer sequencesThe level also features the also-recently-added
Red Eye enemies, which will possibly be called Eye-Beams in the final game, not sure yet! In the post where I introduced them, I described a problem that I would tackle later:
I'm also not yet sure how to approach the timing of the enemy's behaviours. Most projectile-throwing enemies in the game - and also cannons and missiles - are currently driven by a global timer. Each enemy/cannon can be configured with a pattern that describes how often it fires something. This also goes for moving platforms. This allows me to synchronise various features of a level in a nice way.
It would be nice to be able to do this for the red eye enemy too. For example, first fire from tube entrance A, then after 2 seconds duck into the tube, come out of tube entrance B and fire again after 1 second, etc. This would all be synchronised to the same global timer, so I could create interesting but fair patterns that combine the red eye's energy projectiles with moving platforms or other projectiles. However, it would need some smart behaviour where once the enemy becomes active - by the camera moving within range of it - it would need to check the global timer and spawn in the correct place for the current moment, which could be at any tube entrance or even part way through a tube. I would also have to manually mark up each tube entrance that the enemy could appear at. I'm not sure if I'm explaining this well, but the simple takeaway is that I'm not keen on it
It's a problem that I'll tackle in the future when I actually work on a level that uses this enemy.
I'm not sure how good my explanation was back then. The initial version of this enemy would go through a routine where it fires at Leilani, ducks into its tube and travels through it until it comes out of another exit, then fires at Leilani again. It had a certain rhythm to it - it had a fixed time between coming out of the tube, then firing at Leilani, and another fixed delay before it went back into the tube again. But none of this could be synchronised with other elements of the level, such as moving platforms or cannons firing missiles. The timing of the enemy would depend on when it came within view of the camera and became active.
This isn't always a bad thing, however I occasionally want to be able to control this and sync it up with other level elements. I came up with a solution to achieve this relatively simply.
Previously I have described the
Event Timer system - this is what drives the synchronised patterns of other entities like the firing cannons by scheduling a sequence of actions on the level's global timer. Here is a visualisation of this system being used on a cannon:
The grey text shows the next action that will be taken when the pink circle has shrunk to the middle. White text indicates that an action has just been triggered. I could place multiple cannons with the same event sequence and they'd all fire in unison, regardless of when they became visible on-screen.
It makes sense to try and apply this to the Red Eye too to achieve what I want. But the series of actions it performs needs to be aware of which position the Red Eye is currently in in order to synchronise properly.
I had the idea of placing invisible entities at the tube entrances, each with their own sequence of events - these events are then relayed to any Red Eye entity that happens to be at the tube entrance. Here's an example both with and without the visualisation of the event timings.
All of the event timer sequences - the two at the tube entrances and the one for the cannon - have sequences of the same length, so they will all remain in sync. At the topmost tube entrance, nothing happens other than an "In" event telling the Red Eye to pop back into the tube. At the lower tube entrance, there's a series of four "Fire" events, then another "In" event that sends the Red Eye back into the tube - just in time to return to the top entrance and receive the "In" event up there, beginning the cycle again.
This is fairly simple to set up but gives me a decent level of control over the behaviours. It does have some issues, though - which I mentioned in the paragraph quoted above - but I basically decided not to solve them. This rather long gif demonstrates the problems:
The red eye is positioned at the topmost tube entrance when it is first activated, because that's where I placed it in the editor. It's not smart enough to recognise that it should actually be at the lower entrance at the current point in the sequence - so it sits idle in the top entrance and misses all of the first set of "Fire" events until it gets back in sync on the next cycle. This isn't worth solving in any complex manner as there are some simpler workarounds that could improve this:
- Don't use such long event sequences, so it takes less time for it to sync up.
- Position the entity at the tube entrance that they're more likely to be at, so when the entity activates it's more likely to be in the right place for the current part of the sequence.
- In this particular case, spamming multiple "In" events on the upper tube entrance - throughout the part of the sequence where the Red Eye isn't meant to be up there - would be a good bandaid solution for sending it through the tube to where it's meant to be.
Later in the gif, the same issue happens again but it's caused by Leilani rolling into the tube and bumping the Red Eye backwards, interfering with its pattern. The same fixes as above could again help here. But what I'm more likely to do is to prevent the player from interfering with the pattern by capping off the tube entrances so Leilani can't go inside. Easy
Rope Level finished!Finally, I also finished another level since the last time I posted. This was in fact an old level - one which made a long time ago and was mostly playable - but was severely lacking polish and had various issues. There were four chips to collect when there should be three, it used old outdated tilesets, and changes to the rope mechanics (you can no longer roll uphill on a slanted rope) had broken parts of the level.
I polished it up all nice nice and also gave it a complete visual overhaul - it used to be a beach with an underground cave, but now it goes from canyon, to cave, to beach, to match my rough plan for where it should be located on the world map. I added some wooden supports around the level too, for the ropes to attach to - it looks weird when they just stick straight out of a rock wall!
Here's a before and after - in the first picture I'd already partially re-themed the level, but I then added the new wooden support tiles and a 'new' background (it's not entirely new, but just edited from pieces of another cave background already in the game).
That's probably all I'll show of this level - my aim at this point in the project is to reserve as much as possible so that the final game has plenty of surprises to be found! This may mean that I sometimes don't have much to show in the devlog - but I'll try to find a good balance.
Thanks for reading
Community
