NYE Is the Deadline!

(This week's (and I guess this year's) build is up right HERE!)

This week I did some tinkering. I realized that the reason why moving objects are passing right through the player if the player is not moving is because, duh, the moving object itself doesn't have a rigidbody attached to it. It's really only conspicuous in one level, so I only added a rigidbody there. It's possible that that decision comes back to bite me, but it's also the only place in the game where you are advantaged by letting a moving object try to move through you.

But that got me wondering about colliders, which got me wondering about the problem I've been trying to solve for a long, long time - the issue of the player mysteriously losing a ton of momentum after interacting with walls mid-charge. I'd played around with different colliders and things in the past, but I couldn't remember if I'd tried just making the player's collider into a trigger. There would obviously be certain things that would break, but would it solve the issue of momentum loss?

As it turns out, the game runs pretty well even when the player's collider is just a trigger. Most of the logic keeping the player from going through stuff is done with raycasts. And lo and behold, I experienced no loss of momentum on several playthroughs of the game. I won't say that the issue is fixed, because I've been wrong about this before, but it's promising. Of course, I can't just keep the player a trigger all the time, so I just have the player's collider turn into a trigger during charges. It actually works out great that way, since the speed at which the player moves during charges is the whole reason I needed to write the raycasting logic in the first place. As to what was the cause of the issue in the first place, I guess that under certain conditions, when interacting with a bounce wall, the player would turn in such a way that a corner of the player's collider would intersect with the wall's collider, Unity's physics system would then try to stop the player from moving... I think.

We'll see if this solution causes any other issues, but for now all I need to do is to solve some cosmetic bugs caused by this. On an unrelated note, I also need to make boost plates play a sound effect when you go over them. I can't believe I didn't do that yet.

As always, the charging-up noise is by Javier Zumer. I'm using it under this license.

Xmas Eve is the Deadline

(This week's build is here!)

This week's progress is really simple: I added a new level and I made a slight change to the logic of linked goal nodes.

Here's the new level:

As you can see, it's pretty hectic. That being said, there's only one trick to learn in this level, and that's how to navigate the spinning red wall. The other elements of the level are pretty tame. All except the moving boost plates. However, I'm confident that those will be less intimidating to the player because they've already seen that trick before in this level:

I'm not sure what levels are going to end up making up this final third of the game, the part of the game where I want to have a conversation with the player about what all of these mechanics can accomplish in unison, but I'm enjoying finding new ways to combine movement, wall types, goal types, and extra obstacles like boost plates and switches.

As always, the charge-up noise is by Javier Zumer, and I use and modify this asset under this license.

Back next Sunday!

Sorry, no post this week! I had some other things I needed to handle which took priority.

More level tweaking

(This week's build can be found here)

I didn't have much time to work on the game this week, but I did change two levels. One level asked the player to go through some bounce/wrap walls to hit four linked nodes, then hit a switch to be able to do the thing all over again. The switch was totally unnecessary, so I removed it. I might also remove that level entirely later, since I don't really ever ask the player to hit linked nodes more than once in a row in later levels of the game.

However, speaking of using linked nodes that require multiple hits per node, the next level does now use them. Here's what it looks like:

Here's what the level used to look like:

The preceding levels use 45 degree diagonal bounce walls. I thought using two at once would feel like a natural progression, but the solution to this level is uninteresting. There's really only one solution and the level itself isn't that fun to move around in. The level I replaced it with is a lot more fun to move about in. There is a "best way" to solve the puzzle of hitting both linked nodes twice, but there are a bunch of other ways to do it too. If you're fast enough, I believe you can clear this level without even needing to use the bounce wall. My one worry is that it doesn't quite explain what the "trick" of the level is, so maybe it'll be frustrating when people try it.

"Charging up" sound effect is by Javier Zumer. I use and modify it under this license.

Three Red Diamonds

(This week's new build is up here!)

This week was more about level deletion than level creation. I feel like the more levels I design, the better I have an idea for what levels I'd like to cut. I cut the last level of the game easily, because I'd been meaning to cut it for a while, but I also cut two later levels that didn't show off Warp Walls in quite the light I wished they did, along with two earlier levels that were maybe a little novel but not actually pushing the player to do that many cool things. One of those levels might come back, because I still like it.

And then I made this new level, right at the end:

I mentioned this way back when, but I really like starting these later levels with three kill walls arranged as diamonds in the center of the screen. They break the level up in a really cool way, and I can have walls running off of them in what feels like natural directions to further constrain the player while keeping the level aesthetically pleasing.

As always, the charge-up noise is by Javier Zumer and I use and modify that noise under this license.

Why don't I do this more often?

(Hi all, the new build can be found HERE)

Remember when I said, three weeks ago, that I hoped I'd be updating the blog more frequently? I do too! How time makes fools of us all.

I have been working on the game though. I've been at a bit of a loss as to how to tell when I'm done with this game, and how to tell what levels are good or not, or when I've managed to create enough levels, but I think I've had a small breakthrough. The first third of the game should be teaching wrap walls (the blue ones), bounce walls (the purple ones), kill walls, switches, goals, enemies, and linked goals. It should also introduce the fact that these elements can sometimes move about the level on their own. This is the core of the game. Warp walls (the green ones), and boost plates get added on top of that in in the second third of the game, and the final third of the game stops teaching new concepts and focuses on finding new combinations of existing objects. There are a lot of combinations I haven't even gotten around to trying yet, like parenting a bounce wall to a rotating game object:

This level has two relatively easy puzzles to it, and both simply involve finding a good place to position yourself and then bounce yourself off of the bounce wall. The enemy can be killed with a simple bounce, but the linked goals require you to also travel through a warp wall. It feels good that the level forces you to move around it. Or, it would if moving objects interacted with players correctly. Currently walls won't affect you if you're standing still. I feel like I was going to investigate that long, long ago, but never did. Oh well. Attaching game objects to game objects is super basic, and I don't know why I haven't been doing it up until now. This is what I think the last third of the game could preoccupy itself with.

Oh, I also deleted some levels, and adjusted others. Last build, I had this:

Which was just, far too complicated. The warp walls attached to the center triangle moved back and forth even though you were turning the kill walls off, and not circumventing them. That got me thinking. What if the idea was you needed to circumvent those walls, instead of switching them off? I removed the switches, and I also removed the moving walls, as this level would be hard enough without them. Here's what I was left with:

Okay, it looks hardly different, but it plays a lot better.

I may not keep to the formula I laid out above, with the thirds and everything, but I'm starting to have ideas about what kind of mechanical arc I want the game to have. And yeah, the arc I'm describing is a totally obvious one, but it somehow feels more concrete in my mind now.

As always, the charge-up noise is by Javier Zumer. I use and modify the asset using this license.

Level Deletions, Level Edits, and a return to the blog

(This week's build is available RIGHT HERE)

Hi! It's been a while! I was very busy for a bit there. Hopefully, I can update the blog a little more regularly from here on out.

This week I changed a lot of level stuff. The seventh level now much more closely resembles the eighth level, in order to more smoothly transition into linked goal nodes. The way he seventh level used to work was not really doing the job.

I also made a new level that looks like this:

I like the look of it a lot, but we'll see how fun it is to play. The solution to this one is actually really simple, so I think it'll be good as the new tenth level. It's kind of an end-cap to all the stuff that comes before we introduce bouncing walls and the puzzles get simple again.

Oh, and the ninth level, which used to look like this:

Now looks like this:

The walls hanging off the sides were unnecessary. This level is just supposed to do one thing: be impossible to solve if you hold down the charge button fully every time you charge. It should be as simple as possible beyond that. Not to mention this design is far more aesthetically pleasing.

That's it for this week! As always, that charging-up noise is by Javier Zumer. I use and modify the sound under this license.

Smooth Operator

This week's build is available here!

The biggest change I made this week actually took very little time: I made it far easier to move with precision:

I tried to just have the player move via transform.translate whenever it wasn't charging, which did not work at all. From there, I started digging in to the movement code I had written, and I realized that a previous fix that I had attempted had not worked (or had seemed not to work) because of how the movement code interacted with the turning code. I'm never certain if these movement updates will finally make the game feel less frustrating to play, but I hope to get positive feedback on this change.

Other than that, I tested out the effects of having moving objects stop their movement while the player is charging. The result is that certain timing based puzzles are ruined, and even the ones which are improved become kind of boring to solve. Maybe that's the right level of challenge, but that's not how I want to get there. So I undid that change and instead slowed down some of the more problematic timing puzzles. I also implemented something I had been meaning to do for a while: allowing moving objects to pause at each point they move to. It's not used a lot, but where it is used it makes things slightly more player-friendly.

I experimented with placing spotlight over places on the level where it is helpful to stand. It might have worked, except Unity's lighting ignores some lights if they are too close to other lights, and all goals are already spotlit, so that causes a placement problem. I could probably just mark all spotlights as "important" but I feel there must be a better way to get the effect I want.

As always, the "charging up" noise is by Javier Zumer. I use and modify it under this license.

RE: Cursive Additions

This week's build is up here

This week I didn't have much time to work on the blog, but I did have enough time to change the cursor. The goal in changing the cursor is to simply bring people's attention to it and help them visualize where they will end up going. I at first thought I would just go about changing how the cursor displays itself on the screen. I thought perhaps I could change it to something like this:

I don't know what I was thinking. I guess I wanted something that looked like a bulls-eye but not so boring. Anyway, I needed a way to make sure that the new cursor reverted back to a normal mouse cursor while over certain UI elements. That wasn't hard to do, but I didn't want to go through all the UI elements in the game (including the ones that appear attached to objects like goals and the player object itself) and flag each one for the cursor to recognize or ignore.

I also wanted to have the cursor react a bit to mouse placement. At the very least, I wanted the cursor to be like an arrow indicating what direction the player would be moving once they released their charge. That's when I realized the player object itself is an arrow and remembered I can just have an object in the level move about according to mouse movement:

Still not the best, but much better.


As always, the charge-up noise is by Javier Zumer and is being used and modified under this license.

RE: Cursive Design

I always love going to gaming meetups and getting some testing done. It's gratifying to see changes that I've made begin to have their intended effect, and it's motivating to see the problems that I still need to fix, and the tweaks that need to be made to increase the effectiveness of other features. There's no new build this week, but I thought I would share some of the notes I took this weekend:

• Players are finding it difficult to aim at 90 degree angles
• The movement of the player arrow is simultaneously too sticky and too slippery.
• Mouse dexterity is a skill that needs to be taught. I can't ask too much of the player off the bat without teaching them things such as how to be comfortable moving the mouse as you fling yourself forward
• The levels I have which intend to teach players mouse dexterity are still too hard. Players understand what they must do, but it's taking them too long to do it.
• The yellow line which predicts the player's attack path should always be accurate. In the case of moving objects, it's often inaccurate because objects will have moved in the interim. I might freeze moving objects while the player is charging to prevent that.

I believe I need to just scrap the way the player currently moves and do something simpler instead. Pushing the player with physics results in a really natural flow, but unfortunately it's not good for stopping on a dime. The current way that I make the player stop on a dime also causes the player's acceleration to feel abrupt and uncomfortable.

The first thing I want to do to address the problem of mouse dexterity and players being unable to aim at clean 90 degree angles is to give the mouse cursor a makeover. If the mouse cursor were easier to see all the time, then I believe that players would have better control over their attacks. I'm considering also adding a dotted line that always draws to where the mouse is. this might clash with the yellow extendable line which predicts the player's attack path though. A second thing which would help would honestly be to just put objects in the level which encouraged the player to go to a specific position and look in a specific direction. Maybe just a spotlight would do.

Adjusting for time

There's a new build this week!

Hi there everyone, sorry for not posting more, but the last two weekends have preoccupied me with:

1. Traveling to a convention and doing a lot of convention things
2. Attending a wedding and doing a lot of wedding things 

I did a tiny amount of work this week:

1. I decided that the review at the end of each level should just be time based rather than charge based, and that it should just compare your most recent time with your best time for each level.
2. I decided to change the color scheme of all the tutorials in the game

I'm afraid that doesn't make for a very snappy screenshot

I initially implemented the review at the end of each level because I wanted to provide people with the feedback of knowing when they had completed a level as well as can be done. I'm changing it because I didn't like the idea of people finishing a level and immediately being told "you can do better!" I knew I didn't like it from the start, but I decided to let it sit for a while. While letting it sit I also came to the conclusion that "number of charges" was not the correct way to measure success in this game. I don't want to encourage not charging, after all. Simply tracking time is probably the better way to go. Be as frantic and charge-spammy as you'd like - as long as it gets the level done.

(I think, on a separate level, I wanted the review being charge-based to disincentivize people from using multiple quick charges to clear goals that you are supposed to use wrap walls for, but that's a problem that needs to be solved in another way)

I changed the color of the tutorials of the game because I ran into someone who told me they hadn't noticed them! So now they're blue, and not grey. In hindsight, it's easy to see why making your tutorial the same color as your background is unwise.

As always, the charge-up noise is by Javier Zumer. I use and modify it under this license.

An actual post!

The new build is up here!

Whoa! I'm actually posting again! Sorry, things have been very, very hectic for me recently, but I got just enough time to start looking at my tutorial (or lack thereof) again. So in this build, there's a super-rudimentary tutorial. It waits a set time before fading in. It waits a set time before fading out. This was extremely annoying to set up for some reason!

I should have had it set up in fifteen minutes, but I actually spend a long, long time fiddling over how I wanted the script to have multiple phrases to display, and how it would fade in and out and wait for so long between phrases. Then I ran into problems, decided it would be better to just make something simple, and cut out a lot of what I wrote. I'm already seeing that the way I'm timing my fades is completely backwards and I can do more if I just go about it in a different manner.

This week I'm going to Seattle, and next week I'm attending a wedding, so I make no promises to update for a while. But at least there's this one, brief moment of productivity in the middle of this very hectic time.

And the charge-up noise is, as always, by Javier Zumer. I use and modify it under this license.

No new builds this week either!

This week is another very busy week for me. I was out and about for over twenty hours yesterday! I don't know when regular updates will resume, but I'm not forgetting about the blog - there are just some other projects, some other events, and some other obligations that are keeping me away.

No new build this week!

Sorry, no new build this week! I was busy, then was at a wedding. For next week, I want to take another crack at tutorializing the start of the game.

Bug Busting

This week's build can be seen here!

This week I tackled doing the highlighted tasks from last week. Nothing special! It does always surprise me how rusty I am on the code I myself created. It's been so long now since I started this project. The upside to taking this long is obviously that you can let decisions sit and see how they feel, but taking your sweet time definitely isn't *all* upside. That's its own lesson, I suppose. I have to start researching how I want to release this, so that I can start researching how I want to pay the people I'd like to get to provide art, sound, and programming support.

Oh, and as soon as I get another playtest in I'm taking out those impassable goals. They're just... annoying. And not that fun.

As always, the charging-up noise is by Javier Zumer. I use and modify it under this license.

Boosting Lines

This week's new build is here!

This week I mostly... well, I was on vacation so I didn't do as much work on my blog as I could have with an entire week off. Still, I made a new level and added some functionality which really should have been there from the start.

The new level isn't anything amazing, but it's a very tidy puzzle that walks you though three chambers slowly and then has you exit those chambers quickly to solve the single goal in the level. It's really easy, but it uses later mechanics like warp blocks, so I'm not sure where I should put it in the progression.

I also made it so that extendable lines (yours and your enemies') now follow boost plates. It only took a little while to do, and most of that was just reminding myself how I had the system working in the first place.

I spent some time trying to create a level involving a puzzle with a lot of steps. I scrapped it, but not before finding out that deactivating warp walls doesn't stop you from going through them, and wrap walls that are adjacent to obstructions still let you pop through them. I might work on fixing these bugs for next week.

Lastly, I still want user feedback on having goals be solid to prevent exploits, but I'm deciding that I don't like them. It's really annoying to me to have them be obstacles, and if it's annoying to me I assume it's double-annoying for players.

As always, the charging-up noise is by Javier Zumer. I use and modify the sound under this license.

Vacation!

I'm taking a week off to visit some family. While I'm there I'll totally have time to work on this blog, but I did kind of take *this* week of blog work off.

Impassable Goals... Yay?

This week's build is up HERE

This week I changed the way goals work... pretty fundamentally. I'm comfortable doing so because the changes are easy to undo, but as of now you can no longer simply move through goals and linked goal nodes. You can only pass through them by charging.

This finally prevents people from doing the types of shenanigans I mentioned earlier. Is it worth it? Well, that's what I intend to find out. On one hand, it feels more restrictive. On the other hand, it could allow for some cooler puzzles. I'll let it sit a few weeks, at least until the next time I can get playtesters on it, then I'll decide whether to keep it or not.

Side note: never forget the supporting details which make a thing feel substantial. I could have just changed the code to make sure you can only pass through goals while charging, but I also added what I needed to create a little effect when you bump into them, and to have them visually react to you beginning to charge so that you know you can charge through them:

And finally, as always, the charging-up noise is by Javier Zumer. I use and modify it under this license.

July 4th weekend cheat day!

This week's build is HERE

I'm a day late in uploading this, but it's the 4th of July weekend, so I think a little slack is due.

There are two current exploits that I'm having trouble eradicating. The first is the player's ability to bust through enemies with no effort if they happen to be very close to the enemy upon beginning their charge. I thought I had fixed that when I made enemies reposition the player upon deploying their shield. Turns out, my distance calculations forgot to include the width of the shield when deciding how far away to position the player. This meant that if you were close enough you could start your charge, the enemy would put its shield *through* you, and then you'd just charge anyway. So, I fixed that. I also corrected a behavior where the enemy was allowing players to intersect it while charging up. (as in, prior to releasing the charge). Fixed that too. You can still, however, manage to cheat if you put a wall just behind yourself when nudging up close to an enemy. The enemy will try to reposition you, fail, and then you just tear through it. Oh well.

The other exploit is that rapidly spinning players can destroy enemies by just spinning around a bunch. Because the mesh is basically triangular in shape, every corner reads as a hit. You basically turn yourself into a whirling-dervish-buzz-saw-shuriken of death. This, come to think of it, would be a cool idea for a game all of its own. For the time being, I need to think of a way to stop this from happening. No players have discovered this tactic so far, but if there's one that's for certain, it's that they will. Still considering making goals impassable unless you are releasing a charge.

Other than that, I edited levels. One level went away, and a level I forgot to add last week made it in. I think it was this one:

I originally had two enemies in this level, but that was waaay too hard. This is much better. The walls here are actually really fun to traverse, so expect to see another few levels in this configuration at some point.

As always, the charging-up noise is by Javier Zumer and I modify it and use it under this license.

Loads more feedback, tweaks, and new levels

This week's update is a big one. Play it here!

So I tried to make up for not posting last week by doing a whole bunch this week. I worked on new levels at the beginning of the week, but then on Saturday took the game to a playtest and got a lot of great feedback, which prompted me to make the following tweaks:

Remember way back when I decided to make the player rotate instantaneously upon charging? It felt like such a good idea at the time... too bad it allows players to quickly click their way through a lot of obstacles. Three-hit goal in your way? Just click it three times and you'll clear it no problem, no need to interact with warp walls. I decided to leave things that way and see if it really ruined things and, yeah, it does seem to mess things up. You can also simply run left-right-left over goals and clear them that way. To fix that, I set the default timer for these goals to be shorter. Now you should be able to clear them a bit harder. Pro tip though: If you spin your mouse around the player while holding down mouse click, you become a whirling dervish, registering hit collisions many times a second, and mowing down all goals in your path! Sigh... Maybe I should just make goals impossible to move through unless you're charging? Could be interesting.

I made a few new levels:

The above level preps the player for this one, which is an old one:

I'm trying to get better at transitions between levels. I find the key is to have the player seeing and doing things in the earlier level which resemble things they will see and do in the next level (which is really obvious in retrospect). That's why I transition out of the section on quick, small charges by using this level:

To go into this level (again, an old one):

It's not exactly the same, but in both you start and stop in similar places, having hit several linked notes along the way. One level is square, while the other is triangular.

I also added the following levels:

And I made tweaks to the following:

 (Arms shortened, timer increased)

 (Median solidified)

(Kill walls removed)

I know this game must have potential... I'm still thinking of ways to combine the features I have into surprising new levels. For now though, I think I've posted enough.

Charging-up noise is, as always, by Javier Zumer and I use and modify it using this license.

Oops! Sorry, no update.

Sorry, no update this week. I got distracted. I am, however, taking a close look at how I'm transitioning from teaching one concept to teaching another concept. As always, having the preceding level (containing mechanics the player is already used to) foreshadow the goal or form of the proceeding level (containing mechanics the player is no to) is like giving the player a stepladder to understanding. So I'm trying to make my transitions better through that.

Charge Tweaks

New build is up here!

Following some of the notes I was mentioning last week, I've slowed down the time it takes to reach a full charge when holding left-click. I've also sized-up the meter that surrounds the player as they build up their charge.

Here's what it looks like now:

Here's what it used to look like:

The visual change to the meter is just my hope to bring attention to how the meter can be half-full and still allow charging. Slowing down the meter, however, actually changes the game feel drastically different. It's much, much easier to do quarter, half, and three-quarter charges now. In fact, maybe I should make levels that specifically ask you to do those... Hmm..

Speaking of making levels, I'm looking at what the levels currently look like, and I'm unhappy again with how I'm distributing mechanics. I can use more movement, more switches, more kill walls. I can't, however, get too used to the game and forget that I need to introduce things slowly...

Charge-up noise is by Javier Zumer. I use and modify this asset under this license.

Bug fixes, level adjustments, and a new level

New build is up here!

This week I fixed some issues caused by the change I made last week. This means that the speed dampening I'm doing now works when you have the mouse button held down, and the speed dampening doesn't screw up your charge if you charge while standing still.

I also realized that there's been an issue for forever with charging while moving. Because I don't stop the player's movement just before a charge, you actually move a bit to the side in between the time when you let go of the charge button and the time when you actually charge.

Additionally, several failure menus were totally disconnected and did nothing when you hit the buttons for retrying the level or returning to the menu... Those are now fixed. 

I created a new level, which looks like this:

I needed a triangular level which forced players to do something uncomfortable: to start charges which aren't fully charged. (Man, I'm really being punished for giving players a charge attack that you have to charge up). You can't solve this puzzle by making full charges. At least some of them need to be quick charges that are just aimed in the right direction. It's an important skill to have in the game, and I notice that literally no players ever feel comfortable doing this. Partly, this is due to the penalization of being stunned upon hitting a wall. Something I hope to communicate with this level is that that penalty scales with how long you hold the charge for. Another reason why it felt uncomfortable is because of how slidey the controls felt, which have obviously changed. One thing I'm thinking of doing in the future is making it take more time to charge up your charge (there it is again) so that it becomes more apparent that you can release the meter prematurely. 

I deleted an old level, specifically this one:

I've seen people really like this level and I've seen people really dislike this level. I've never felt strongly about it and I'm not sure that whatever concept I was going for was being communicated very clearly. It'll come back in some form, I know.

I also changed a level from this:

to this:

The kill walls were... overkill for a level this early into the game (by level, this is about a third of the way into the game, but by time it's probably more like a fourth) so I removed them. Then I just had to reposition the center obstacles. This level is another reason why I created the triangular level above. This level requires a quick charge through a blue wall to get one node followed by another charge (or just moving quickly) to get to the second node. Players have no idea that they can do quick charges, so this was frustrating too.

As always the charging-up sound is by Javier Zumer. I use and modify this sound under this license.

Stopping Power

New build is up here!

Part of actually changing gameplay means I get to put puns in the blog titles.

Not a lot changes in this update, but I did act on the feedback I got last week. I changed the orientation of some obstacles in one level to make the solution to that level more intuitive, and I spent a lot of time looking at how I move the player and eventually came upon what I think is the best way to force the player to stop when they let go of inputs.

I tried at first to make acceleration and deceleration be dependent upon time rather than the drag setting on the player's rigidbody, then I briefly considered overhauling how the player moves entirely, but I eventually decided I would limit the player's speed by modifying the rigidbody's velocity directly, which is what I already do in several parts of the game.

The next hurdle was figuring out under what conditions to have the game stop the player. Obviously, when the player isn't entering any input, I need to stop them, but how to detect that got a little fiddly. I use Input.GetAxis() instead of Input.GetAxisRaw(), which means that there's a substantial amount of time where input is "falling off" after you let go of whatever keyboard key you're holding down. I tried a bunch of workarounds until I figured out Unity already had this solved with the Input.GetAny() method.

After I got everything working, I realized that modifying the rigidbody's velocity directly worked, but didn't feel right. Everything was too stiff, it almost gave you an anxious feeling. So I created a drag setting that exists solely for slowing down the player, and now when I want to slow the player, I just set their drag to that number. It seems to work a lot better, and I have a lot of freedom over how stong I want the stopping power of that function to be. Which brings us back to the title of this blog post. Full circle!



P.S. This update caused several bugs, including one which limits your speed if you charge while standing still. I've fixed most of them already, but as this is already a late update, those fixes will be coming next week.

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

And not an update was made!

Sorry, no update this week. I did, however, take the game to a developer meetup and got some good feedback on some levels. I've looked at redoing player movement before, but I keep shying away from making the player stop on a dime, for whatever reason. The game requires a lot of precision, and for me, I've gotten so used to the movement that it feels precise (or precise enough) to me, but it's really turned off multiple people, and that means I have to look at it again.

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.

More Playtest Notes

Sorry, no new build this week, though for the sake of whoever might be looking to play, here's a link to the most recent build of the game.

This week I was busier than usual, and decided not to work on the game until after the Indie City Games meetup, which occurs every two months or so. At the meetup, I showed off the game and got a few people to try playing. I immediately observed some things, and learned even more when they were done playing and I got to interview them:

1)  I need to tutorialize harder. People don't know that you can use WASD to move. I'll need for the game to detect whether you're using a controller or not, so I can have the game mention the analog stick if it is relevant.

2) This level is absolutely too difficult:

A lot of people understand that you're supposed to make multiple charges in quick succession though. A lot of people also understand that you don't have to make full charges. What people don't understand is that the player object takes time to rotate to face where you want it to face. I wonder what would happen if the player rotated instantaneously upon releasing a charge...

3) For the second meetup in a row, people kept mentioning how rewarding it feels when all the goals disappear together. They love the levels when you can solve everything in one go. One person told me they wanted the linked goal nodes to disappear as soon as they cleared all of them, instead of waiting for the timer to run down. I think the lesson here is that hitting a target cleanly is an inherently joyful activity. I mean, we've known this for years - it's why headshots exist - I've just never thought of it that way for this game.

4) This level is intriguing:

There is no one clean solution to this level. I just thought having switches and kill walls in this configuration would be interesting. It seems I was right, because more than one person called it out as being particularly fun or as making them feel clever. I'll have to try to recreate this type of level.

5) There seems to be a bug involving enemy shields and pressing and holding Mouse 0 (left click) while you are mid-charge. This is a bug I'll have to look into for next week.

And that's it! For next week I'll be acting on all this information, prioritizing the parts I've written in red text.

And, as always, in the build linked above the charging-up noise is by Javier Zumer. I use and modify it under this license.