The player blocks enemy shots while the sphere is fully charged. Also pictured: some test elevator objects, some wall-mounted buttons that can be pressed by throwing spheres into them, and these two jerks who block the way until some arbitrary condition is met. And a crab.
[ Warning: Lots of waffling ahead ]
Work Since Last Devlog
Actors
Added a second set of rectangle coordinates for actors, to separate the actor’s terrain bounding box from damage checks. This allows the player actor to duck underneath some hazards without allowing it to get stuck in spaces that it wouldn’t be able to walk out of.
Design
Added a small graphical indicator for the player’s sphere shot when it leaves the visible screen. The sphere despawns if it travels further than one screen’s length from the player. Shortly after this, I made the sphere despawn when leaving the visible screen. Undecided on this.
Made a basic elevator platform by modifying a generic box actor that I made earlier. It seems more stable than the floating platforms that were in Hibernator.
I’m not 100% committed to this, but I tried adding a “shot redirection” actor, which upon contact with a player shot, centers it, changes the speed and angle, and sends it off to a predefined destination.
I made the following modifications to the player:
- The player’s shot now hurts the player 🙂
- The player can’t move for about a quarter-second after releasing the shot. I’m allowing the shot to briefly pass through the player after release, so that kicking the sphere at a wall point-blank doesn’t immediately cause self-inflicted injury.
- When the shot is fully charged, but still held by the player, they are able to block minor projectiles, but not melee attacks.
- To discourage the user from just keeping a charged shot at all times, the player slows down slightly after about a second of holding a full charge.
- I was thinking of making the sphere explode as well when the user presses the attack button while it’s bouncing around, or maybe having the sphere be capable of damaging more heavily-armoured kinds of creatures before it has bumped into anything, but I have nothing actually implemented for those ideas yet.
- The game’s time scale slows down for about a half-second when the player loses a life.
Thoughts
This has been a slow week, as I’ve been a little unmotivated lately. I guess it’s not bad to slow down a bit once in a while. I tried to identify the sources of my apathy and fix them, and maybe made a little progress in doing so, but not really enough.
I guess the main issue is that I would boot up the game, and just … not enjoy it. That’s expected, because it’s just a prototype and not finished. The tweaks to movement, self-inflicted damage and deflecting minor shots that I mentioned above were an attempt to make it more interesting for me.
Earlier, I made some quick sound effects for the player’s charge-up, the sphere-throw, the sphere hitting obstacles, and the sphere hitting opponents. The sounds weren’t very good, and they were starting to grate on me a lot. I found myself liking the prototype more when the audio was muted. I tried adding filters, phaser effects, echo, and adjusting the volume levels. The SFX is better now, but I hate that I’m so susceptible to things like this.
I’m growing tired of doing manual data entry for actors and animation, but I can’t get mired in building asset editors right now. Just get this done.
I need more creatures. They need to be the right size so that the user can accurately target them without missing. It takes a lot of time to go from sketch -> still mockup -> animation mockup -> programmed actor, though, and sometimes the results just don’t work.
I looked over my devlog posts from when I released Hibernator. I redesigned the whole game’s 7×8-screen map in a week. That’s nuts. It was possible because it was a single global map, with one background layer, one tileset, one spritesheet, no scrolling, no levels, no lives, and no script triggers. With this game, I don’t think it will be feasible to scrap entire levels and start over from scratch. I’ll have to live with more mistakes and compromises.
Plans For Next Post
- More creatures! Worry about consolidating shared code once you have more tangible content.
- One thing I’m really lacking right now is a sensible sleep-wake, spawn-despawn system for opponents. They should only be active when in proximity to the visible screen. So I need to implement something for this, and I need to do it fast.
- Big oversight in the audio subsystem: there’s no way to specify volume for when playing SFX, except to set it in the associated SoundParams table.
