next »

[vdapps]

Cool bubble level. I agree with JobLeonard. IMO, maybe few cute clouds or something subtle, but it's ok if top part is more clear. So eyes are naturally always focusing on action.

[Ishi]

Red eye enemy

The name is placeholder, but this week I added a new enemy type! The enemy pops out of tubes to fire energy projectiles directly at Leilani.

The energy projectiles should work as an easy way of adding some pressure to the player to keep moving and be wary of their surroundings, in a different way to the other projectiles that are already in the game (bouncing spanners and boomerang-like blades). Interaction with these energy projectiles is very simple - they travel in a straight line, and you dodge them.

In contrast, the tube aspect of the enemy should provide a lot of interesting options with how the deal with them, as well as how the enemy can move throughout a level! This is the kind of fun interactions I like in the game, where the player will have a lot of flexibility in how they approach a situation.

I kept gif progress of the development of the enemy, so I'll go through its implementation one by one.

1. Basic aiming behaviour

The enemy's design is really simple - like a lot of enemies in the game it's basically a ball. I keep the robot enemies visually distinct by using different patterns of the yellow and purple colouring.



The first thing implemented was aiming at Leilani by rotating and turning to follow her. I drew 8 different frames of the animation for rotating - which are flipped left to right. The enemy can only turn around at the top and bottom of the aiming range, so there are just two animations for turning.

2. Support for different orientations

Next up was expanding this code to support the enemy being in different orientations. This didn't require new animations as the sprite is rotated at runtime.



Having enemies that stick to walls/ceilings isn't entirely new to the game but isn't used often. It's done by using a special hacky state for the enemy that applies gravity in a different direction. This is by no means fully supported - a normal enemy or Leilani couldn't walk around on the ceiling, for example - so there won't be any weird antigravity mechanics being introduced into the game. But it works in this case because the enemy's behaviour is very simple.

At this stage, the enemies didn't have any special handling for being attacked, so they get into a weird state where they bounce around still with their hacky sideways or upside-down gravity applied.



3. Visual improvements

I tweaked the rotating anim to keep the body of the enemy stationary, rather than rising higher/lower out of the tube which looked a bit weird. Also, I separated the hands out into a separate sprite which is rendered above the tubes, and the body is rendered behind the tubes. This allows the enemy to be visually 'inside' the tube in all orientations.



4. Going through tubes

Next I added the behaviour for the enemies to duck back into their tube. This needed two new animations - one to prepare to duck into the tube, and one to grab onto the exit of the tube when coming out of it. I also had to add the rolling animation, which is used when the enemy is inside the tube.



5. Compatibility with No-Entry tubes

Some tubes are no-entry: they have a cap on the end, and things can come out of them, but not go in. I wanted these enemies to be an exception though, since thematically they're already inside the tube so the cap shouldn't prevent them from entering it. In code terms though, the enemies are not actually related to the tube at all - they just sit on top of the entrance of the tube. So when you put them on a no-entry tube, it both looks weird, and it prevents the enemy from entering the tube.



Two hacks were required: one to force the tube's cap to be visually open when this enemy is at the entrance. This is a visual thing only and doesn't affect the ability for anything to go into the tube. A second hack allowed this enemy to enter tubes even if they are no-entry.



6. Attacking the enemy

Next up, correctly handling being attacked! The simplest form of attack is to jump on the enemy or roll into it in a way that just stuns it or makes it roll away much like a normal enemy.



The second way to attack is is similar to before, but forcing them enemy back into the tube - it'll roll through the tube and pop out of the other side, stunned.



Finally, you can roll through the tube yourself to attack the enemy from within! In this case Leilani is bounced back at the point of stunning the enemy, to help make the enemy's grip on the tube entrance feel more substantial.



Once the enemy is stunned, they become an inactive object that can be kicked around. They can never recover. This avoids dealing with the situation where the enemy recovers but is not on top of a tube that they can enter.

7. Projectiles

At last it was time to add the projectiles! This was the first pass - very simple spawning of the projectile.



8. Aim adjustment

I did some behind-the-scenes work to adjust the way the enemies aim at Leilani. Normally, they aim at the centre of Leilani's collision box. However I wanted to encourage the enemies to fire projectiles at direct horizontal angles where possible - this helps to avoid the projectiles being on awkward nearly-horizontal paths. If the projectile is on an exact horizontal path then it provides moments where Leilani might be able to roll or duck underneath the projectile, which is nice.

This works by aiming horizontally if Leilani's collision box lines up horizontally with the enemy. The debug view here shows a line representing the enemy's aim direction.



This also applies vertically - which is a less common occurrence.



9. Firing anims

I added firing animations to the enemy. There's a pre-firing animation - a pretty simple one with the energy building up around the eye - and then a post-firing recoil animation. Each animation has 8 variants, one for each angle of rotation.



10. Projectile effects

Finally, some effects to make the projectile more visually appealing.



Phew! I'm happy with how it turned out. There are still a couple of outstanding things to address - I need to add audio for the enemy, and want to add particle effects at the point the enemy is attacked to make it a bit more impactful (probably some nuts and bolts plus the enemy's hands falling off).

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.

For the time being I do have another enemy that I'd like to work on, so I hope to start on that this week!

Thanks for reading

[Earworm]

Really great work! The idea to stick to horizontal/vertical trajectories if possible is an interesting touch. I really like that Leilani can enter the tubes to stun the enemy too! Maybe it would be possible to jump from one tube directly to another. Makes for some interesting gameplay options.

[JobLeonard]

Well that was a little masterclass in implementing an enemy

[oahda]

Counted quite a few hacks there, but it all looks so good!

[Canned Turkey]

 

[Suttebun]

Do they aim at Leilani through a local intelligence (relying on their own peripherals)
or do they use global information to point to an established position?

I'm currently studying the difference between local AI and global AI. (own words)

[Ishi]

Do they aim at Leilani through a local intelligence (relying on their own peripherals)
or do they use global information to point to an established position?

I'm currently studying the difference between local AI and global AI. (own words)

I do have enemies in the game that do their own checks to 'see' Leilani, and react to that by throwing projectiles / chasing her etc. So that's the local type of intelligence. Typically their vision is relatively short range (maybe 6 tiles at most). These new enemies just track Leilani globally, since I wanted them to fire from longer range and Leilani could be going in/out of their vision range quite often.

For enemies that go about their actions regardless of Leilani's position, I give them two eyes in their design. For enemies that react to Leilani's position, they have one eye, normally blue but it turns red when they're in the 'alert' state (when they can see Leilani). So for these new enemies I just gave them one eye and it's always red to indicate that they know Leilani's position. This design scheme also luckily works nicely to use their single eye to fire the projectile from!

[JobLeonard]

Took me a moment to realize that you switched from "AI concept of perception" to "visible depiction of an eye on the sprite" 

[MondayHopscotch]

Took me a moment to realize that you switched from "AI concept of perception" to "visible depiction of an eye on the sprite" 

I did the same thing... was trying to figure out what 'the second eye' was from an AI perspective.

[Ishi]

Good point, it is a bit confusing to read The second paragraph is just about the visual design of the enemies, which I didn't make very clear, but thought it would be interesting as it relates to the way the 'AI' for that enemy works. Basically, the number of eyes indicates whether they are capable of reacting to Leilani's position, and the colour of the eye indicates whether they're currently aware of Leilani's position or not.

[Suttebun]

@JobLeonard from an AI's perspective you could consider a second eye to be it's global nature

That's cool Ishi, good idea!

[JobLeonard]

The third eye is meta-knowledge about the game system's inner workings?

[Suttebun]

haha

[Ishi]

The third eye is meta-knowledge about the game system's inner workings?

This might be a bit philosophical, but the AI already is one of the game system's inner workings... does the AI know it exists?

Totem Enemy

I'm here with another new enemy, the totem. It's basically a big tower that gets in the way! Once again I saved a lot of gifs throughout the implementation process.

1. Mockup



The totem is on the left. The idea is it can be built out of a range of different sections, very similar to the end-of-level machine tower. Using the same visual language of yellow duct-taped sections indicating that the sections can be destroyed from that direction.

2. Tiled placement / entity setup

Most enemies in the game are a single entity - one object, with one hitbox. Some are more complex - e.g. the boss tank which has an invisible controller entity that moves around all of the individual parts of the boss which are all separate entities.

The totem behaves like the boss. Each section of the totem is a different entity, as is the head at the top. The controller entity is responsible for the overall movement of the tower, and collapsing the sections downwards when ones below are destroyed. In this case the controller entity isn't invisible, because it's represented by the little piece at the bottom of the tower with wheels/tracks on it. This section isn't collidable though.



Here the totem sections have been placed in the Tiled editor. The controller entity isn't placed manually. Instead, the game looks for a totem head, then steps through all of the tiles directly below the head until it runs out of totem sections. The controller entity is placed at the base of this stack of entities and is given control over all of them.

3. First in-game sprites



Initial set up of the in-game totem section entities. No head entity exists yet.

4. Basic collision



The totem has basic collision set up - it's solid, basically each section is a moving platform. Explosions can destroy the sections at this point (I have a debug feature where pressing Delete creates an explosion where Leilani is ).

5. Directional destruction



The weak parts can now be destroyed by hitting them from the correct direction. It's not shown here but explosions can also now only destroy sections when the explosion is coming from the correct direction.

6. Collapse



The sections above the destroyed sections fall down to fill the gap!

7. Head added



First addition of the head entity. At this point the code is a copy of the red eye entity from a couple of weeks ago - this seemed like a good starting point because it's a stationary entity, which is essentially what I needed for the head. While the middle sections of the totem are moving platforms, the head is more like a normal enemy - you can bounce off it, for example.

8. Head bop



I added some proper sprites for the head. Bouncing off the head destroys the section below it.

9. Movement



Initial movement of the totem, including a turning animation for the head. The turning animation is intentionally a bit extravagant, to make the totem look a bit more lively.

The totem stops and turns around when it's 1 tile away from a wall, unlike other enemies that will walk right up to the wall. This prevents the totem from crushing Leilani (and other enemies) against the wall, which would lead to instant death. Note that, since the totems are solid objects in their own right, it means the totems naturally stop 1 tile short of each other as well.

10. Spikes animation and damage



I added animations for the spikes, and the damaging effects of them.



As always I kept the spike hitbox as small as possible to avoid any unfair damage. If you're trying to destroy a neighbouring non-spiky section of the tower, this helps you to do so without accidentally taking damage from the spikes.

11. Head interactions



Next I considered some of the other interactions that can be done with the head - walking or rolling into it, and other enemies bouncing off it. I wasn't quite sure how I would handle this at first, but settled on this wobble/rebound, which feels right to me.

12. Damage effects



Here I added some more polish with animations for the base tracks, a lot of particle effects, as well as some visual damage states for the sections when they have been hit and are about to explode. The head of the totem also pops off when the whole thing is destroyed.

13. Fireball interactions



I was playing around and realised that, since the head shares code with other normal enemies, it's possible to instantly destroy it by rolling into it with Fire Leilani in her fireball state. I decided to keep this and made it automatically destroy the whole tower piece-by-piece.

Fire Leilani can also smash through the weak middle sections of the tower without rebounding, allowing her to instantly get to the other side without having to demolish the entire thing. Unlike the instant-head-kill this one was intended.

14. Damage pause



Finally I made the tower pause in its movement briefly when being damaged. This helps collisions with the tower to feel a bit more predictable - if the tower keeps moving towards you after you roll into it and rebound off it, it can feel unfair if you take damage from the tower's spikes.

That's about it! Next up I'll be trying out this new enemy with some level design. I'm planning on using it in the Fire Leilani tutorial level, as it's an obstacle that is much easier to deal with if the fireball is used well.

[JobLeonard]

This might be a bit philosophical, but the AI already is one of the game system's inner workings... does the AI know it exists?

Time to link this classic early John Carpenter scene again:





Anyway, it's always super-satisfying to see you implement these enemies step-by-step, and this one is no exception.


What's missing in this gif is what happens if an enemy rolls into the spikes of the totem. Do both the enemy and one spike level get destroyed perhaps?

[Suttebun]

The way that the head bounces behind the layer is very nice.

[Ishi]

The way that the head bounces behind the layer is very nice.

If it looks like the head goes behind the blue wall, that's just a coincidence! The head just pops out of existence after a fixed time.

What's missing in this gif is what happens if an enemy rolls into the spikes of the totem. Do both the enemy and one spike level get destroyed perhaps?

The spiky sections don't count as weak points so can't be destroyed in that way.



Some enemies like the maca here - which are killed by spikes - will be destroyed when touching the spiky sections. Robot enemies like the drill bot aren't hurt by spikes and so will treat it like a normal solid surface e.g. getting stuck in the wall and dying.

[JobLeonard]

Ah, check. So that makes mechanical sense, but it does look a bit odd to see it stuck while the spikes are spinning around...

[Suttebun]

easy fix

nothing is broken, your fixed point is JobLeonard's opinion

edit:

I’m just trying to help out, but not if it causes issues

stop stop, don't do that.. It's good to muddle! It's how we learn.

My response was to put out there that your comment was leaning towards what you liked.