New level, some corrections, and versioning

New Build is up here!

This week I corrected a sound effect issue, I fixed a UI issue, and I created an pretty interesting new level. I also got my project versioned, which is something I'm very rusty with, having not touched versioning in about two years.

I started out wanting to make a level that used boost plates, but I then decided it would be cool to see what I could do with more of those rotating hexagonal bounce walls. I ended up doing neither of those, but I did make a pretty interesting and challenging level.

The object is to bounce all the way around the dangerous kill wall to attack the enemy there are a few angles you can do this from, which makes the puzzle feel open and flexible. You have to keep an eye on both your bounce angles and those of the enemy projectiles, so despite the fact that the puzzle isn't hard to figure out, you do need to work a little to actually solve it.

The charging-up noise is, again, by Javier Zumer. I use and modify this sound effect using this license.

One new level

New build is up here

Not much of an update this week. I noticed that warp walls and boost plates still don't get that much love in the latter half of the game, so I added a level that uses warp walls.

I'm also starting to look into finally getting this project versioned. I've been working this entire time without any kind of versioning software whatsoever, which hasn't really mattered to me that much so far, but which may be important in the future. It'll definitely become true if I ever want to contact an artist or sound designer to help finish the aesthetics of the game.

Charging-up sound is by Javier Zumer. I use and modify this sound under this license.

Just some text changes

New build is up here

This week I didn't add anything other than some text to the screen which pops up when you clear a level. It'll now tell you about how many charges you used, and compare that to the lowest number of charges needed to complete the level.

I also created a game object in each level that holds a script which tracks and reports that level's stats. Currently that is only the number of charges the player has taken and the minimum number of charges required to clear the level. I'm sure there's a smarter way to do this than making an object in each level which tracks this, but I didn't want to make some kind of static class which had information on each level because I didn't want to have to keep track somehow of what level index corresponded with what level, especially looking at how often I add or rearrange levels.

This is the kind of change that I really need a playtest for. I can't gauge how well this is working at all until I see how players react to it.

As always, charge-up noise is by Javier Zumer. I use and modify it under this license. I really got to get someone to just whip up a version of this noise that I don't need to endlessly cite.

A New Level And Some Rearrangements

New build is up here

Not much time spent on the game this week, but getting back on the wagon always takes me a few weeks. I wanted the player to play around with switches and linked goals a little bit longer before introducing them to bounce walls, so I made a new level that uses movement, linked goals, and kill walls. I also did some minor rearrangement of levels. I think I may have deleted a level? It's late at night and I'm not sure anymore.

I've been thinking a lot about one piece of feedback from the last playtest I had. Someone wanted to be able to see what the optimal number of charges was for the level they were playing. I really want to be able to reward players for solving the puzzles in the lowest number of charges... I was also thinking about the issue I have where players can simply charge back and forth to clear any goals that require three or fewer hits. I realized that if I limit the number of charges a player has in a level, I increase the difficulty of the game, I increase the chances that people will stumble upon WASD movement, and I inform players of the optimum number of charges while preventing the exploit I mentioned above. However, I would need to clearly communicate the limit that's being imposed on the player, and I would be forcing people to restart levels a lot when they run out of charges. It would both frustrate the player and interrupt their flow, if they had any. I think what I want to do is call out to the player what the "Par" is for the level they are on, like a golf course. Maybe the win screen can inform players of how many charges they solved the level in, and how many charges you can solve the level in. This doesn't prevent people from doing anything, it keeps the game as difficult as it is, but it allows players to more easily seek the "perfect" solution, if that's the kind of gameplay that appeals to them.

Well, enough rambling. The charge-up noise is by Javier Zumer. I use and modify it under this license.

No new post Today

Sorry, I didn't get much work done this week, though I feel like I should have. One thing I looked at this week was limiting the player's ability to rapidly charge back and forth. This was problematic because it meant players could easily bypass all "hit this goal three times" if they focused on just charging three times. I thought of a couple of unsatisfying ways that might have worked as solutions, but eventually I decided that it's not worth fixing. It only comes up three or four times in the entire game, and it's pretty clear that you need to be pretty familiar with the game already to pull it off...

I still want to look into restructuring levels this upcoming week. I've almost finished pushing the exciting bits (movement, switches, kill walls) so it's important to fill in some space with new levels. I'm not sure if I have a greater strategy for what I'm doing right now other than that the game feel better with these concepts frontloaded before the second (and eventually, third) wall types are introduced. Wall types can be combined with existing wall types and all these other concepts to start making very very complex levels, so I should have a good breadth of complexity to draw from now, instead of just killing time before I get to the next basic concept I need to communicate.

Rearranging the Start of the Game

This week's build is available here!

So I wasn't so happy with the maze-like levels I had in the build previous to now. They were certainly cool, and I could make them impossible to complete without using WASD to move... but I didn't like how different those levels looked compared to the other starter levels. When players move on to a new level they have to understand what they're looking at, and when you make a level look very similar to the level that came before, players only need to worry about understanding the differences, which is helpful when you're trying to make it easy for players to learn something new. So I've changed the starting levels (well, levels 3-7) so that they look like this:

The first picture is level three. Goals and blue walls have already been taught by then. Level three introduces normal walls and getting around them with blue walls. The only difference here is that the level goes horizontally now, like levels 1 and 2.

Level four and five would be the maze levels, where I encourage players to use WASD, then require them to use WASD by introducing kill walls and switches. I decided that one way to teach WASD is to show the player that other things can move. The hope is that when players see other things moving, they'll wonder if they can move too (without charging). Moving obstacles also deserve to be introduced earlier in the game. You still can't solve level four easily without using WASD, and level five still introduces kill walls and switches.

Level six and seven are about expanding knowledge of switches and testing the player on all the things taught so far. For some reason I had these levels go vertical again. I'll probably leave it since these testing levels should feel different from the teaching levels.

That's all for this week. Again, the charging-up noise is by Javier Zumer, and I use and modify it under this license.

Just some minor adjustments for now

Here's the new build for this week!

Nothing much to report this week. I wish I had done more work on the game, but it didn't shake out that way. I did, however, address the issues I highlighted in red last week. I was very pleased to fix that charging bug, since I was able to fix the issue by editing down my code. And having the player automatically look in the direction they wish to go when they charge is a very small but very satisfying change. It just feels right. Also, it lowers the "gulf of execution" by a bit. A very important bit.

Additionally, I rewrote that tutorial text I mentioned a few weeks ago. Now it says this:

I still hate telling the player to do something when it's the only thing you ever speak to the player about. Maybe I should work on a more robust tutorial system that I can bring up in more levels. That way it doesn't stick out like a sore thumb when I use it here. Again, I'm hoping it's a little charming in the way that it appears word by word as you perform charges.

Finally, I played around in BFXR to see if I could finally replace the sound effect I keep citing at the end of these posts. I was not successful, as evidenced by the below:

Charging-up noise is by Javier Zumer. I use and modify it under this license.