The new projectile attack I’m testing.
Work Since Last Devlog
Design
So I thought more about how the game should look as a finished product, and I think I have a good enough image now to move forward without getting analysis paralysis.
I’ve been playing around with that spherical attack I mentioned last week. I’ve got the charge-up, projectile launch and cooldown parts working, and the ability to change trajectory depending on the current held direction. I like it! There are still some bugs I need to work out, and I’m sure I’ll be twiddling with the velocity and angle parameters for a while. Here are some short demo videos I put on Twitter. @farawaythyer immediately caught the similarities to Sunsoft’s Mr. Gimmick, which I’ll admit is one of my favorite games.
The rolling + bouncing code is a modified version of the “spherical happy face” character I had been testing previously. That character probably won’t end up in the final game, and I think I’ll probably be removing crates and other ‘physical prop’ test objects as well, as I don’t want to spend too much time maintaining them. They’d probably be more at home in a puzzle-focused project.
I had the player ‘hurt’ state implemented earlier, but only got around to the knock-back part of it now. The direction that the player is flung in depends on the player’s X position against the collider’s X position. If the collider is to the right, the player flies back left, and vice versa. In some games, knock-back direction only takes the player’s current facing direction into account. I want certain creatures to have different rules for how they inflict damage and how knock-back is implemented, but that’ll have to wait until there are more functioning opponents in the game.
I changed the jump code to let the player jump over three 16×16 blocks (used to be two), and also added a heavier gravity parameter for when the user presses and releases jump before hitting the apex of their jump. The player is a lot more maneuverable now as a result. I did this mainly because I was finding it difficult to jump over hazards, but also to allow for more coverage when shooting downwards while mid-air.
I drew up some new art for the test enemy being hit in the upper, middle and lower regions of his body, the idea being that you’d select one of these depending on the player projectile’s Y coordinate in relation to the enemy’s Y coordinate. In practice, this causes bunched-up enemies to all show the same hit graphic (since they were all hit in roughly the same location), so I ended up making it randomly select one of the three frames instead. I also drew lots of pink guts, to be spawned when the sphere impacts these characters.
I’d like to have some moments where the user has to defeat a set of enemies before being able to progress further. In some games, like most classic beat-em-ups, the viewport refuses to scroll beyond a certain point until you’ve KO’d everyone on-screen. Other options include having an obstruction automatically open up, or a set of platforms appear, once the right conditions are met. I opted for removing an obstruction, and prototyped a pair of actors to stop progression. The blockade object spawns a decorative secondary actor, who is presented as holding the blockade in place (though in the source code, it’s just being pegged to the blockade, and changing animation frames depending on how hard the player is pushing against the blockade actor.) Once the conditions to progress are met, the decorative actor picks up the blockade, walks away off-screen, and then removes itself and the blockade from the scene. The blockade technically continues to function even as it’s dragged off-screen, until it’s officially removed.
Actor Spawning
Added a second set of offsets in animation frames for when attaching actors to other actors based on their current animation frame. For example, say we have a character who wears different hats which are implemented as secondary actors. We would want those hats to anchor to the character’s head, even when the actor’s head raises and lowers while walking, or when the actor is ducking. These attach XY offsets can be used to place the hat correctly based on information in the actor’s sprite instance, and not the actor’s gameplay state directly. This function takes flipping / mirroring into account.
Thoughts
I put the engine planning page on hiatus as I’ve been focusing more on the game part of the project than the engine part this week. Small annoyances aside (like defining animations in the codebase, and a kind-of-weird-and-verbose way of maintaining actor-to-actor references), it’s been working fairly well.
Collected some icky balloon and relish jar sounds which I’m hoping will be good for the enemy presence SFX. I have some placeholder sounds for the player’s sphere, but they’re not really conveying the correct amount of weight that the sphere is supposed to have. I need something on the lower frequencies, bellowing and thunderous.
Plans For Next Post
- Oops, I nearly forgot about posting this and didn’t get around to filling this section out. That’s twice in a row! I’m going to spend the next week putting together test enemies to get a feel for how the sphere projectile is working, then make a decision on whether to move forward with it or not.
