olrabiesabe / capman Goto Github PK

When the player is stationary by walking into a wall, they continue to animate. This looks silly.
The player should switch to a neutral sprite when this happens, but detecting it might be nontrivial.

I've just noticed some sprites being semi-transparent even though they shouldnt be. I have no idea.
It affects zombies and the score screen background. It also affects the score screen text...

Thought: it might actually affect all sprites. The ones listed above might just be the only sprites that regularly overlap with other sprites.

My guess for a culprit is that prepackaged menu system i added in.

Enemies can only move in discrete increments, like 1px, 2px, 3.5px.
If a wall is 2px away, but they're currently moving at 3px per step, then they just can't move that way.
This leads to enemies getting stuck in corners and T junctions at some movespeeds, since they cant get close enough to the walls to navigate the turn. It may also happen in other situations.
Currently they're configured to only move a good movespeeds, and frequently snap to the grid just to make sure.
Obv, this is a brittle solution. It would be better to have some kind of system where enemies can tell if they're in some such situation, and move a smaller amount to navigate the turn.

After dying to a zombie, the player is supposed to be moved back to the start location. This location is indicated by an obj_player_start instance.
Simply put, this sometimes works, sometimes fails. When it fails, the player just resumes from where they died. Idk why it fails.

When the obj_player dies, it changes its p_isAlive to false. This flags obj_logic_gamemanager to set gameIsOver to true, which flags obj_logic_supermanager to call its p_restartLevel(), which calls obj_logic_gamemanager.p_restartLevel(), which calls obj_player.p_reset().
obj_player.p_reset() is what's supposed to move the player to the obj_player_start instance.

Looking at this, it's obviously spaghetti code. This whole process needs to be simplified. Resetting the level on death is supposed to be a in-game sort of thing, so I think supermanager probably doesnt need to be involved at all.

Because there's multiple enemy types, they have a parent-child relationship with a master generic enemy. They override several of its events including Create. But because how Gamemaker handles overriding, this means if i make any change to enemy.create, I need to copy that change to every enemy type. This is tedious and annoying.

I could theoretically circumvent this by moving all enemy functions out of Create and into independent scripts which would be shared by all enemy types. This would require a lot of refactoring though.

I've been putting object functions in the Create event of said object. This is a cluttered and undesirable way to do things. Instead, I should have been putting most or all functions in scripts. Where possible, I should start moving functions into scripts. In theory I should be able to do this pretty quickly.

Sometimes after a player death, enemies fail to respawn.

I can see their debug text, they're getting stuck in the OOB waiting room outside the screen.

The screenwriter is writing all its text above the scanlines. This is not desirable.
Need to look in to how to fix this.

If the player eats a powerpill, and then an enemy comes out of its spawn room, the enemy wont be feared. This is correct, it means powerpills have limitations.
However, if the player then eats a second powerpill, it will fail to fear the enemy. This is incorrect, consuming a powerpill should apply fear to all enemies in the instant it's eaten.