next update notes

 

 

Some notes for myself on a potential next update:

Have just been thinking about how to add some progression without a scoring system, because I hate scoring systems. And also how to handle moving to new areas without needing to add an entire world map like I'd originally planned. I may just have a level-based system, where you progress through a linear series of levels (each with their own name, as in 'Now entering: The Gluttonous Garden') that have different objects or spawn conditions in them, and add additional complexity or difficulty over time. 

This is handled by having fuel pickups that drop from destroyed enemies and asteroids. Gathering enough of them will charge your hyperdrive and let you jump to the next area. This means learning how to do room transitions, so it may not be easy. It also might mean adding a UI element, to show how much fuel needs to be collected. 

---

And instead of working on any of that, I added a new enemy type. Simple thing that is just a hostile version of the player, minus all the special abilities (of course, that would be insane). Still quite dangerous. It was easy to implement because of the IFF system that each object already uses. And because I did all of the tedious copy-pasting already when I made the friendly version of the same object. 

Next, I'm thinking about adding a conjurer. Just a dude floating in space who continuously summons floating eyeballs that circle around him, increasing the size of their orbit over time. I've sort of decided to throw theming out the window. Besides, this guy will be part of the space horror faction, for which there are no rules. I wasn't looking forward to trying to figure out how to make one object circle another, but actually I think I can get around that by just having the conjurer set the eye's initial facing and direction, then having the eye continuously rotate and accelerate each step. I can alter his orbit distance by moving him in 90 degrees to one side according to his image angle. Problem is, it also means I'll need to alter rotation speed over time to compensate for the larger circle this should create. Of course, this only sounds viable because the conjurer won't be moving at all. I may change to a simpler pattern if this proves too difficult, but the general idea is to have an object that is continuously spawning new enemies if you don't destroy him quickly. The circle pattern seems like a good idea because it will show that increasing density clearly, and what its source is; and it means the eyes won't need to wrap around the screen to keep them from despawning too quickly. 

Speaking of replicating enemies, I just remembered the mines in the old version of the game. That same implementation isn't going to work here, but I could try something similar. 

Other thing I still don't have is a slow, 'zombie-like' enemy. Essentially, something low threat, but very high health. The chompy guys are too fast to and squishy to fit that, although their behavior is otherwise identical. I had something like this in the original version, and while they aren't particularly interesting on their own, they have the side effect of forcing the player to relocate, since it's easier to avoid them than kill them. Of course, that may be less interesting here, because the teleport ability makes relocating trivial, and there's already so much happening that it's frequently necessary anyway. However, this enemy also negated the player's shield, which could prevent cowardly players from turtling in place.

A couple of notes, if I can remember them: 

Nope, I can't. Wait, here's one. For the hostile starfighter (player ship), maybe we should have them spawn differently. Instead of random spawning, let's have a fighter bay that can spawn anywhere offscreen. It will periodically produce enemy starfighters until it's destroyed. The rate won't be randomized, it will have a set interval, but the initial value for the spawn timer will be shorter each time it resets. And give the bay a fair amount of health, so that concentrated fire is required to destroy it. This game is already impossibly difficult, so let's make it even moreso. 

There was something else, but it has flown away.

---

If I ever need to add a save system (which I might if I actually get around to adding levels), I would instead like to add a password system. I want to do this for three reasons:

1. It'll be much easier.

2. I like password systems.

3. I'm tired of people trying to justify draconian save restrictions with faulty arguments. If I get to add one to my own game, I want to make it trivially easy for players to cheat.

---

I want to add turrets to my little credits object that shows up when the you die. They will shoot at anything that moves. 

Kind of did this. The turrets look stupid, so I might remove them and replace them with something else entirely. The shots themselves are cool.

Started working on the player missile launcher instead. Started with the other missiles already in the game as a template, but they need to be reworked a good bit to feel nice. I made them much smaller and faster, and gave them contrails from the moment they fire. I've also thought about adding a turn rate to them, so that they arc in a satisfying way. I may or may not do that. Seems like a pain. Also still need loading and firing sound effects. The loading sound should raise in pitch with each missile, because that would sound better and also give more indication of when you can actually fire. 

Further progress on the missiles. I got them arcing the way I wanted without adding an actual turn rate. I just made it so that they curve out after firing, prior to being able to lock on to anything. Aside from more visual and aural feedback improvements, the main issue remaining is that they currently fire in a random pattern, which ends up looking weird. They should fire in a consistent pattern, three to the left and three to the right, but that means a lot more than one line of code, which I'm too tired for right now. I also think they should have a higher speed, so I can make them turn more quickly without getting in the player's way. Right now, it feels like shooting missiles at yourself, if you happen to be moving forward already. 

I'm also considering adding a targeting reticle object over any object one of the missiles locks onto. Should hopefully be simple. The missile creates a reticle in its own create event, but the reticle is set to hidden by default. Any step where the missile is locked on to an enemy, it will place the reticle at the enemy's position, and set the reticle to be visible. Almost totally pointless as a source of information for the player, but might look cool. It's also UI territory, but whatever. If it looks neat, keep it. 

I thought more about how to add levels, and I don't think it will be that difficult. I think there is a pretty simple way I can do that, because right now there is no code that needs to be persistent between rooms. Trying to add exceptions to the existing code based on the current level seems like a huge pain, especially since I didn't write any of it with that in mind. I think an easier approach will be to just make a duplicate object intended to be placed in a particular level. So for instance, if I send the player to level 1, I need an instance of the game object in the new room. So instead, just have an additional object called GameLevel01, with any spawn code that is unused for that level commented out, and a few tweaks to the default timers. If I end up needing code that is constant between levels, I can add a new object type to control that, but for now, I think everything can just reset in every room. I can do the same with the player object, if I want to easily disable certain weapons. That means having a set loadout for each level, rather than actual dynamic pickups like I might eventually want, but that seems fine for now. Easier is better.

 

More thoughts on how to handle progression: Scoring systems bore me, so I think there are two main options for how to handle difficulty. The first is for things to work as they do now; where the game resets when the player dies. When I have additional levels, I will probably want them to go back to the level start instead of the start of the whole game, since it is really easy to die in this. 

The second, and maybe more interesting option that just occurred to me is to have the level just keep going, and the player just gets to respawn, like one might in an old coinfed arcade game. I thought about just having infinite lives, and then just having the game tell you how many times you died at the end. That's essentially how something like Metal Slug works these days. There could even be a fake credits/coin system, although that seems kind of cheesy. 

A better way might be to just take advantage of the existing fuel system (that I plan to add). You have to collect enough fuel to jump to the next level. So dying doesn't reset the level state, but it does put your fuel counter back to 0 (not sure if there will be a hateful UI element for this). This way, the player feels like they can keep going, while still being punished for dying. You don't go back in time, you just have to stay in the current level for longer before being able to advance. With that in mind, it might be worth just having a timer that would tell you completion time at the end of the game. 

 

Other ways to make the game a bit more forgiving would be additional powerups. Right now, the only powerups are upgrades to the functionality of the existing equipment. Some temporary buffs might be interesting, too. Most important idea is a Sonic-style shield that just boosts your health, and is destroyed when it takes enough damage. Represented with a glowing outline, so that I don't have to add a health meter. Should be fairly easy to implement. I would need a new object, but only for the sprite. This object would just be an overlay on the player that would only be visible when their health is above the default value. Having it present all the time, but hidden, would be easier, I think, because I don't have to worry about the code creating copies of the object. It would just check the health value each step, and set that object to be visible any time HP was over the default. All the code would be on the player, though I might need some on the other object to make sure it stays in place. 

Finished adding the missiles for the player. They look and work as I imagined them, so that's good. Still feeling kind of meh about it, though. Not sure what I want to add next, if anything. Need to finish up with the changes to the game over object. 

Note on a bug that I'm too lazy to fix right now. Like everything else, missiles target an object's x, y position. The front and back parts of the company cruiser have their origins outside of their collision boxes, so they'll appear in the correct spots when attached. I'm sure this is a minor issue for anything that targets those objects, but it's very obvious for the player missiles, now that they place a targeting reticle directly over the spot they are targeting. Also, they sometimes end up flying in circles right in front of the cruiser's detached engineering section, trying to hit an object that isn't there. For the missiles, the easiest fix for this is probably to add an exception that tests what type of object the target is, an alters the trajectory accordingly. That doesn't fix inaccuracies for other objects, though none of the others are very noticeable right now. Only making a note of this because I'm too lazy to fix it. Squashing a minor bug is boring and tedious, when I could be adding something fun.

The past couple days, I've been trying to think how I could turn this into an open world game. Contrary to that stuff I wrote in this very entry about having a linear set of levels. Unlike my original concept, which involved randomly generated stages and a strategy layer, I'm imagining this as a set series of areas for the player to sandbox in. This would likely involve a large amount of new art assets, not exactly my strong suit. I think the first step to it would be having a way to transition to interior areas on foot, which means a new set of mechanics to support that. 

Have been thinking some about a potential soundtrack for this, for a couple of reasons. One, I've been playing The Friends of Ringo Ishikawa, and it's excellent, and the music is excellent. Also, been listening to the Hyper Light Drifter soundtrack while working on the game, and it actually kind of works. For a while, I didn't think music would fit with this project, because it would hide the sound effects too much. But actually, if it's just ambient chords, it provides some nice background but still leaves everything audible. So that might be the way to go for the sections of the game in space. If I ever add some on-foot sections indoors, the music could be more rhythmic, because there would be fewer things happening. And it could also sound like whatever might be playing in the area. 

I keep adding random thoughts to this entry for some reason, so I'm just going to go ahead and publish it as is. And apparently, the entry looks weird on the main page unless I upload an image, so there's one of Mr. Tums at the top, just for fun. 

This blog layout is really quite awful. I may have to address that eventually. Just move it my neocities page or something. Or use the itch.io blog feature instead, but meh.