Work Since Last Devlog
- Changed jump behavior from a static arc to one that can be shortened by letting go of the jump button. If the user has bumped into a ceiling, and is still holding the jump button, there is now a brief stick-to-ceiling behavior meant to facilitate jumping into tight areas. (Too much and it just looks like they’re floating.) I also capped the upward jump speed to make jump power-ups more reasonable. Earlier with the static arc, upward momentum would quickly get out of hand. Now it’s scaled up only slightly with every power-up collected. This scaling still wouldn’t work for really bogus jump heights, but it should be fine for about eight gradations.
- Added a “grace period” of allowing the user to initiate a jump after they have fallen off a ledge for a certain number of ticks. This should help somewhat if there is input/output lag, though it kind of looks like a bug if you’re not aware that the feature is present.
- Added ladders. After playtesting what I have, it’s clear that I need a controlled method of vertical travel between different screens. In a game where the camera tracks the player, it would be a different story, but in a flick-screen game, this means you have to perform blind jumps and falls whenever you travel vertically. Now, it would be possible to enforce a very strict design, where vertical edges between two screens always telegraph which direction to jump in, and also whether there is danger above or below. It would also be possible to add a brief pause when transitioning between screens to give the user a heads-up. But a simple ladder is so much easier to read, and far more trustworthy. While I also have moving platforms that can be configured to move up and down (and I intend to use them occasionally for vertical transitions), they are not under the player’s control, and long round-trips could leave the player twiddling their thumbs waiting for a ride. That should be an uncommon event. Additionally, it’s possible that a player might not see the moving platform on a screen because it’s located in another area in a given moment.
- More graphical work. Added grassy tiles for the mountain base, snowy tiles for the top, and some variations on the main ground block to try and make it look (a little) less grid-like. I’m happy with the main player art but still unsure about backgrounds.
- I also made some adjustments to the HUD display. The player’s jump strength is now displayed, and the “top altitude” indicator will bump up slightly when a new highest point is reached. Additionally, made the “Alt / Top” indicators change to “Dep / Bot” when the player is below the surface level.
- Added in gates that teleport the player horizontally or vertically within the span of a single screen. I don’t intend to get too clever with this, it’s just intended as a way to provide routes around existing solid structures. (For an excellent 2D game designed around portals, check out Gateways.)
- Added a snake enemy that patrols left and right, and displays a biting animation if the player gets too close.
- Added a water terrain that makes the player float upwards. The faster you land in the water, the deeper you can go before floating back up. To leave water, you hold jump while treading on the surface. I’m not sure if I want to include the possibility of drowning or to allow users to move around underwater for as long as they want.
- Added breakable blocks that crack when stepped on, and then vanish after the player jumps or steps off of them.
- Added mud, which dampens the player’s walk speed and jump strength while being stepped in.
- Added some additional orientations for spikes so that they can be attached to walls and ceilings.
Thoughts
Most of the work this week has been real game stuff, not engine infrastructure. It’s been refreshing. I’m getting more comfortable with this just being a small prototype game. That’s what I need. Get it done, then tear out or fix the stuff that didn’t work well internally, and move onto the next thing.
I tried adding sloped floors, but the engine (not LÖVE, which is pretty great, but my scripts sitting on top of it) and platformer code is too messy to easily reason about correct actor placement while taking neighboring tiles into account. I could probably get it working eventually, but it’s not a necessity, and there are more important things to focus on. Better to figure out an improved system later on for future projects once this one is out the door.
I drew the graphics for another enemy, a hopping spike with legs named “Point Man”, but he may be more trouble than it’s worth. Maybe next time.
Plans For Next Post
- I’m not sure if I will have something fully formed by March 31st, but I’ll try to get some kind of start-to-finish prototype made by then. I still need probably a half-dozen more features implemented before I can build proper levels. Getting there…
