A/B Testing two Options

After about a month of various trips, from San Francisco to Boston to Milwaukee, I'm finally back to posting! It's been a long, long time. When I last left off, I was in the middle of trying to find a way to make it easier for players to make a series of quick charges while still giving them the time they need to accurately line up shots. I wanted the charge meter to fill up, pause, then fill some more, pause, and then finish filling. I'm not sure why this stumped me for so long, because I sat down with it for a few minutes today and just got it working:

(to see the solution, check out the build right here)

After I got that working, I felt like the game was too sluggish. I increased the rate at which the player's charge meter filled and tried it again. I also decided to test a hypothesis that I had. Previously, if the player smashes into a wall, they're stuck charging until the charge runs out. It felt like an appropriate cost for what is a very powerful ability. But what if that was wrong? Because the missed shot is itself a failure, and because the charge is the main mechanic of the game, perhaps it's wrong to punish the player in this way. My hypothesis was that having your charge immediately end upon smashing into a wall would not only allow players more leeway in quickly charging across levels, but would make the game more fun to play overall without sacrificing the integrity of puzzles. Then I made a build for that mode of play:

(click here to play without the wall-stun penalty)

My guess is that, while the three-step charge is cool, it's a little over-complex. The simpler solution of removing wall-stuns from the game is probably the best way to do things. Even if it's less cool from a UI perspective. 

All this fiddling with the charge mechanic is very unkind to my friend, who is working on the sound effects for that charge. So for now, the sound effect is still by Javier Zumer, which I am modifying and reusing under this license 

Investigating how the player charges

I did a lot of non-game work this week and weekend, so unfortunately there's no build this week. I am looking into some feedback I recently got from some playtesters. I was glad to see that the game has gotten a lot easier to control, and people seem to be getting close to finishing the game in one sitting comfortably.

While I'm managing difficulty fairly well, I could be doing better. There are later levels in the game which, while not too difficult puzzle-wise, are pretty difficult execution-wise, which causes a difficulty spike that I didn't factor in.

I'd love to make it easier for players to charge multiple times in quick succession. I think I want to revise how the player's charge attack builds up and lets off to address that. This also means changing how the force is applied to the player during that charge. I think these changes will actually involve me removing some over-complicated systems, so this might make the game more stable, actually.

There's also a bug I've been getting since updating Unity where the linked goal nodes in just one level won't always fire properly. That's going to vex me for a bit.

Oh! And next week is GDC, so I will probably miss the next two weeks of updates!

Back to the Blog

It's been a while! The new build is right here

Sorry for being out of commission for so long. My computer was out of commission for a little bit a few weeks back and I haven't really been on the ball about doing Unity work since then. To be honest, I'm really considering moving on to the next project for this blog. I'll still work on Pierce of course, I want to release it eventually. But for the purposes of this blog, I really need to be doing something useful each week. And that hasn't been true for a while. I want to use this blog to experiment more, so at the end of this month, after I'm back from the Game Developer's Conference, I'll try to work more on tutorials and experiments.

Not much changes with this build - I fixed three minor bugs, one of which came up as I updated to a new Unity Version. There seems to be another unity bug happening on certain levels. I'll see if I can get it to happen more reliably and fix that bug as well.

The audio designer I have helping me is still working on new sound effects for charging, but for now the charge-up noise is still by Javier Zumer. I use and modify this asset under this license.

More Shader Tutorials

I'm still working at learning shaders. I'm not sure how I'll be able to use them in the game, but likely there will be some kind of application. Maybe a spotlight effect under the player that gets more pronounced the more you charge up your attack. In the meantime, I learned how to do this:

Shader Tutorials Continue, Audio Asset List Created

This week I only had a little bit of time to work on the game. I spent some of that time putting together a list of all the sound effects in the game and where they appear in the project to give over to a friend of mine who is interested in producing some sound effects for me. The rest of the time I spent refreshing myself on what I'd already covered in terms of shader tutorials so far. So, not much forward movement this week. Next week will hopefully be better.

On Contests

I worked very hard on a design test that's part of Wizards of the Coast's "Great Designer Search 3." I definitely didn't procrastinate at all and I'm definitely not just writing this now, at midnight on Sunday.

With seriousness, I apologize for not posting anything this week. If only to talk about the shader tutorials I'm doing, I plan to resume next week.

Sound Designers and Shader Tutorials

This week I got in touch with a friend of mine who was interested in providing sound effects for the game. I'm going to provide them with a list of sound effects that need to be either created or replaced. At the top of that list is going to be the sound effect I keep having to cite each week. Sheesh.

I also continued my slow progress with learning shaders.

No update this week, but shader things!

I unfortunately don't have an update, but I will share that I decided to look into learning how to do some basic things with shaders this week. I was intimidated at first, but of course as soon as I started watching tutorials it became a lot more approachable... Because that's the function of a tutorial.

I'm not sure in what capacity I want to use shaders for this game, but I know that I do want to keep things aesthetically minimalist, staying to simple geometric shapes and more-or-less solid colors. Learning a bit about shaders could really expand my options for look and feel while staying within those parameters. 

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.