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.