Sunday, July 31, 2016

Back on the Wagon (Sort of)

(The new build is up here)

I had another lazy weekend, but luckily I did manage to finish the work I said I'd get done during the week. I now have a radial charge meter surrounding the player, and the meter turns red when you run into a wall and crash. It helps to indicate how long you have to wait before you can move again:


I do worry that the game has become a little busy for it. I think it helps to convey that there is a maximum amount of charge you can save up. I've been relying on sound alone to communicate that for far too long. For those reasons, I've also included a particle effect that emanates outwards from the player at the moment that they reach full charge:


The idea is that the particle effect is broad enough that you will know you've reached full charge even if you're looking away from the player. Hopefully the the particle effect is quick enough that it's not distracting. All of these moments - reaching full charge, charging into a wall, etc. - need to have sound effects to go with them, and I could really use a looping "full charge" sound to replace what I have. Maybe that will be next week.

As always, the charge-up sound effect is by Javier Zumer. I'm using it and modifying it under this license.

Sunday, July 24, 2016

Lame, No-update Week

Sorry guys, basically I was even more busy this week than I was last week. My time is much freer in the upcoming week though, and I plan to capitalize on it. I expect to at least have the improvements I mentioned in last week's update finished. Maybe not the "stunned" feature, if I decide I want to play around more with how not getting stunned feels.

Sunday, July 17, 2016

Something I Screwed Up Months Ago Is Now Fixed

New build is up here!

I finally figured out what was going wrong with my collision code. The problem is obvious in hindsight. Each frame, Pierce checks for surfaces the player should have hit both between where the player used to be and where they currently are, and from where they are and where Pierce estimates they will be next frame. When that check senses a surface, it checks what type of surface that happens to be, and performs the correct action. I was checking for default walls in one check, but not the other. Dumb! But it's fixed now, so I'm not complaining.

I'm still planning on adding in a "stunned" state (or maybe just a co-routine) for when the player charges into a wall, but for now there's just no drawback to charging into walls. It feels... good. Maybe worth just keeping.

I'm also planning on adding in a power meter for the player's charge. This is one of those features I thought of a long time ago but also forgot about a long time ago. Drawback of doing so little work on this each week, I guess. I was going to make it a radial meter, like the timers on timed goal nodes. I can blame my not doing so this week on my parents being in town, but if I'm being honest, I had other chances and decided to be lazy this week.

Plus, I found a strip of tape on the ground today that was labeled, "NO EXCUSES." You gotta respect that.

As always, charge-up noise is by Javier Zumer. I'm using and modifying it under this license.

Sunday, July 10, 2016

Well, that's funny

No new build today - sorry guys!

So last week I said I wanted to work on providing the player better feedback on when they hit a wall and continue charging into it. I wanted to turn it into a "powered-down" status effect that lasted for a period of time proportional to the strength of the charge. But I found out something funny: My code for hitting a wall seems to only be occurring a small percentage of the time.

This actually makes some sense. The way I handle collisions currently, all I do is cast rays from where the player *used* to be last frame to where they are *this* frame. This lets me sense whether the player has passed through an object that they shouldn't have. It also gives me the information I need to cast rays from where the player is *this* frame to where they should be *next* frame. This tells me when the player is about to enter a warp wall, or a wrap wall, or hit a bounce wall, or whatever.

I... I don't ever actually call OnCollisionEnter or OnTriggerEnter. This is a weird thing to do, but the player is always moving so fast that these methods would likely fail to fire a significant portion of the time. If I comment out my raycast code, the player regularly passes through walls on a charge, for example.

That raycast code is also in charge of what happens when the player hits a wall, which is where I would *like* to trigger this powered-down status effect. I found out, however, that there are times when the player hits a wall and this code just... never fires. I have no idea how this is possible, since other parts of the same block of code *appear* to be firing.

This of course can't be the case, so next week will be spent debugging this, and possibly rethinking how I handle collisions globally... One thing that was suggested to me at the Indie City Games meetup was throwing out the way I currently move the player (which uses Unity's 3D physics) and just use Unity's 2D physics. I'm understandably reluctant to switch over to a new system, but it's worth looking into.

One thing I did do this week was fix up a minor error where enemy projectiles would interrupt the guide line that extends out when you build up a charge. Not worth making a new build for, really. You'll see that change next week though.

Thanks

Sunday, July 3, 2016

Two levels up, one level down.

Here's today's update. Sorry for being late! It's the weekend before 4th of July and a lot is happening in town.

Not much to say this week. I'm trying to restructure the pace of how I introduce new goals and mechanics from levels 1-20. In the process, moving elements appear much sooner in the level progression. I made some new introduction levels and deleted an old level that was no longer necessary.

One thing I keep forgetting to implement is better feedback for when you crash into a wall. I want to focus on that for next week.

I think maybe 20 levels is enough? I have ideas for more features, but I don't know that the game needs them. I wonder how many levels I can have in a row before it gets boring just completing goal after goal. The goals change in nature, but there are no levels where your goal does not revolve around basically the same thing: Hit the orbs with your avatar.

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