To Understand Recusion, One Must First Understand Recursion

This week's build lives here!

Not a big function update this week, but I took the guideline-rendering feature I added last week and refined it a little. It now recursively spawns additional guidelines as needed. That is all!

I mean, I'm sure I'll find out later that I did this in a really messy way that I will want to clean up... but for *now*, that is all.

And look, I even have screenshots this week!

As always, the charging-up noise is by Javier Zumer. I am using and have modified it under this license.

Doing Lines

New Build is up here!

A while back I tried to get the guide line that emanates from the player to interact with walls so that it correctly displayed the path you would take after charging. I gave up after trying to figure out a way for this method to recursively call itself. Then a friend of mine suggested a different take on it, which really helped me wrap my head around how this needs to work.

Currently it only works on Wrap and Bounce walls (Warp walls are for next week) and it also only works for one interaction (the lines emanating from Wrap and Bounce walls do not cause the same behavior to occur if they hit *more* Wrap/Bounce walls) so I may need to make this recursive anyway. However, with this first version I have a much better understanding of what it would take to do that. Yay for friends.

As always, the charging up noise is by Javier Zumer. I have used and edited this asset under this license.

Fixing exploits and fine-tuning controls

New Build is up here!

So, in my files, I have this as week 52 of Sunday is the Deadline, which I think must be taking into account all the times I've missed a week on this blog, since really, I started this blog on 3/15/2015, so I'm about 6 weeks over the 1 year marker here. So, 6 weeks missed, give or take, over a year. Not bad. I'll try to do better for next year, of course!

Pierce is looking better, though still needs a lot of work. This week I managed to reduce the ability to instantly kill enemies. The exploit was brought to my attention while I was watching a friend play. She moved really close to the enemy, to the point where she was almost touching it, and then charged forward. The shield was created, but the player was able to pass right through and kill the enemy anyway.

I tried several times to keep this from happening. I tried instantiating a trigger which would push the player away. No dice. I tried the same thing, but directly changing the player's position instead of applying force to the player. This also didn't work. In addition, the trigger was clumsy. It needed to hang around for a certain duration to be readable by the player, but needed to destroy itself quickly enough that it didn't interfere with the player if they were charging from an acceptable distance.

I eventually realized that the enemy already knew the position of the player at the time that the player began their charge. With that information, I was able to have the enemy see if the player was charging from too short a distance. In that event, the enemy repositions the player as subtly as it can, while instantiating the bounce wall just between the player and the enemy. You can still kill an enemy with a direct charge, but it is much, much more difficult now.

Briefly, I thought about having enemies kill the player upon contact, like the kill walls do. I decided that that would be a bad idea. First, it doesn't actually keep the player from using the exploit, just makes it slightly harder to pull off. Second, and more important, I really don't want players to be afraid to charge enemies. Having them die when they touch enemies, and then asking them to successfully charge through enemies seemed like an unintuitive thing to teach.

Finally, I fiddled a lot with the parameters on the player controller. It's been a long time since I've done that. I have a better understanding of how this game should work now, though, and I think it's in a much better spot. You should feel a lot less floaty now. The player should also feel slightly slower, which should actually make charging feel a lot better!

For next week, I plan to keep fixing stuff, and maybe add one more level.

And as always, the charging-up noise is by Javier Zumer. I am using and modifying that asset under this license.

Just one new level this week

The new build is up here!

Just one new level this week. I let myself get distracted early on in the week, and I was unexpectedly sick and busy the latter half of the week. I also found out I accidentally deleted the level and had to remake it just now!

But enough excuses. I'm happy with what I made this week (it replaced the old level 16) though I'd like to see if I could continue to improve it. It's a bit unintuitive, but I really like how the projectiles shot by the enemy give you clues on how to solve it. It's also a little hypnotic, in an aesthetically pleasing sort of way, just to watch the projectiles bounce around and be redirected by the boost plates.

As always, charge-up sound effect is by Javier Zumer. I have used and modified it under this license.

Two new levels, zeroing in on feel and progression

New build is up here!

Wow, we're already up to 50 weeks of "Sunday is the Deadline!" I wish I could say that I'm doing something special for the big five-two, but I don't know what that would be other than releasing this game, which is nowhere close to being done.

This week I worked on levels. I deleted two and added two, both in the latter half of the game. I'm thinking more about which features work better when mixed together, which features have more or less design space to them. Movement, switches, and timers obviously have more. I like the boost plates, but perhaps they're not worth including after all... They do have interesting interactions with enemy projectiles though, which I'll investigate further.

I'll continue to add and subtract levels like this, mentally noting certain improvements I'd like to make for the next couple of weeks. I already know I want to make the enemies telegraph where and when they'll shoot even better, and get your charge line to properly indicate where you will go when you travel through walls.

If I were devoting as much time to this as I was when I was making a game a week, I'd no doubt be done with this by now. My life is kind of full right now though, which is a good thing.

As always, the charge-up noise is by Javier Zumer, and has been modified by me. I'm using it under this license.

Walls and Goals Inherit some Class

New build is up here!

Whoa, a Sunday Is The Deadline post before Friday? Weird!

Well, I'm visiting some friends for the weekend, so this is the only time I have to post. And, sorry to say, even though a lot was shifted around behind the scenes this week, nothing should appear different in this build from last week's build. (If there is something different, then I've messed up!)

A few weeks ago I set up my solution for timers and switches, which used a separate script called "TimedBlink" which implemented the "timable" interface. Timer classes looked for objects with timable components to switch them off or on at set intervals. I realized this was awkward as soon as I went to implement switches. (Switches would need to look for timable object too, and then turn them off).

This week, I ripped the functionality for things to turn themselves on and off (which involves managing particle effects and sound effects) out of the timable interface and put that into an interface called activatableAndDeactivatable (I really hope I think of a better name for that soon). This interface has an Activate method, a Deactivate method, and a Flip method, which will activate the object if it is inactive, and vice versa.

Furthermore, I created a script for default walls (called DefaultWall, go figure) which implements the activatableAndDeactivatable interface. I then made sure that switches and timers still functioned for default walls. Right after that, I had all other wall types inherit from the DefaultWall class.

I did a similar job with goals. The base goal script now implements that obnoxiously named interface, and enemies and linked goal nodes inherit from it. Well, linked goal nodes do. I'll have enemies inheriting from the Goal script next week. And then almost all relevant objects will be able to be switched on and off in a suitably ambiguous fashion!

Charge-up sound effect, as always, is by Javier Zumer. I'm using it under this license. I have modified it.

Switch me on, turn me up

New build is up here!

Okay, switches are working! They were actually easier to set up than I thought they'd be (and I thought they'd be easy - I didn't want to try tackling anything hard right after GDC).

So, what's next? Well, I definitely want to recalibrate the levels that switches appear in... I also consulted a friend and I might have a better, more robust implementation of both timers and switches to try. So that's next.

After that? Well, I know I said I'd be done with features, but I don't think that's quite right. I think some features are going to go away, and some features are going to appear. Here's an example: breakable walls. Breakable walls are an easy, intuitive way to require that a player charge through a certain portion of a level. Breaking through walls would also feel awesome, if done right. Finally, and most importantly: breakable walls would require the player to power-up their charge. A common mistake I find people making right now is that they never bother to power-up their charge, or they're confused about what powering-up does for them. A breakable wall would help illustrate what's really going on there.

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