Trimming the Fat

New build is up here!

So I missed my post last week - whoops! I basically didn't do anything over Christmas weekend except make it so that only the linked goal you are interacting with responds to linked goal node hits.

This week I cut out all levels that involved timers (plus one or two others that just weren't exciting me). I was basically only using timers to make different walls appear and disappear, and while that was interesting, the levels they produced didn't really pull their weight. This is sort of counter-intuitive, since this game is mostly about timing your charges correctly. But even the one timer-based level that I didn't want to cut was improved by removing the timed walls and turning them all into moving walls.

Above you can see the old level. The player has to navigate six timed kill walls. It's fairly easy to get to the switch on the right-hand side, then charge through all the activated bounce walls to hit all the goal nodes. There's a single specific moment when all the kill walls are down. Wait for that moment, then charge.

And here we have the new level, which uses three moving kill walls. The player has to interact with the kill walls in every corridor, though the far right and the far left corridors are the easiest to pass. Once you've hit the switch, you have to be mindful of where each kill wall is. You also need to account for how long your charge is going to take. The two center corridors are the trickiest to time when charging through the goal nodes.

If I had to guess, I'd say that movement is a more effective way to introduce timing-related challenges because it relies on visual information. Humans are probably just naturally better at movement-tracking than they are at internalizing an arbitrary rhythm disassociated from music.

Charging-up sound effect is by Javier Zumer. Use and Modification under this license.

Fancy Linked Nodes

New build is here

This week I deleted this level:

and created this level in its place:

The new level uses boost plates (which I think I'm not using often enough), multiple sets of linked goals (which I've never done before), and linked goals that must each be hit more than once (which I'm doing only one other place).

It's also another level that is broken up int multiple chambers. I think the chambers progress kind of cleverly here, with the first puzzle showing the player how to hit the switch to reveal the next chamber. The puzzle in the next chamber is an elaboration of the first puzzle, using all the same boost plates, which feels elegant. I could make the level use three chambers, but this is already kind of crazy.

In comparison, the old level did a neat thing where it made the player think of their charge as not one instantaneous action, but instead a sequence of events. It's a cool idea, but not enough for an entire level.

Also, all linked goals are subscribed to the delegate which fires whenever *any* linked goal node is touched. This means that the "you've failed" sound effect and particle effect will play for all linked goals in a scene, even if you weren't interacting with it. I'll fix that for next week.

Charging up noise, as always, is by Javier Zumer. Used and modified under this license. 

Deleting old levels and adding new ones. Also, switches now switch switches.

New build is up here!

In short, this week I deleted this level:

And added this level:

The top level is really just a poorer version of the level that comes right after it (the one with the large hexagon). It also looks really... weak. There's not a great amount of balance here and the entire left side of the level is underused. So I got rid of it.

I added the lower level because I realized that the game ramps up to the second to last level (the crazy one with all the walls and projectiles) way too quickly, and I wanted an intermediary level that introduces the idea of the level having passable sections. I was tired of having a switch that you didn't want to accidentally hit twice, so I just made switches able to be turned off and on. This means switches can turn off other switches, and switches can turn off themselves. Very meta.

I also did some behind the scenes fidgeting with the second-to-last level, increasing the interval between projectiles to dull the difficulty a bit. I played around with the order of another level. See if you can notice which.

Charge-up noise by Javier Zumer. Use and modification under this license.

More level reconfigurations

(New build is up here)

This week was spent fixing some existing levels. Most noticeably, I edited that new level from last week, taking out the enemies and the warp walls and making it a very simple introduction to switches. Here's what it looked like last week:

And here's what it looks like now:

As before, you deactivate one wall and reactivate another whenever you hit any of the switches. This means that, one switch at a time, this level sends you in a circle (well, I guess in this case a rectangle) until you hit the goal at the bottom of the screen. As before, only one switch is ever accessible to the player at a time, so even though this may still look complex, it's probably the second simplest level in the game.

The other level I changed this week was this one:

I moved the switch to the center from the bottom right corner because I hated the feel of trying to line up the correct approach to the lower boost pad and needing to be careful not to re-hit the switch. I also have the kill walls at the bottom left starting out deactivated. This means that when you hit the switch, one side turns on, while the other side turns off. This makes the level feel a lot more interesting, since you might have to hit the switch twice to complete it, depending on how you want to solve the puzzle.

Moving the switch to the center of the level also allows the enemies to be able to hit the switch, which I have mixed feelings about. I do want enemies to be able to hit switches, but it's hard to direct the player's attention to the switch to teach them that this is happening. Mostly, you're just confused when a switch is flipped without you doing it...

For next week, I plan to take a look at timer levels, and see if I might want to remove them. On one hand, I can create any timer-related puzzle with enemy projectile launchers and swiches. On the other hand, timing is a large part of the puzzle-solving of this game, and I don't want to always have to worry about whether a switch is in range of some random enemy, or whether the player can mess up the sequence of timed objects...

Well, despite not doing much this week, it looks like I managed to write a lot. Just how it goes, some times. Charge-up noise, as always, is by Javier Zumer. Used and modified under this license.

Level reconfigurations

This week's new build is up here

After two weeks off, I'm trying to get back into revising some of these levels using some of what I learned in the last few builds. I was unhappy with how I introduced bounce walls and unhappy with how I introduced switches, so I created, deleted, and/or edited several of the levels having to do with those concepts.

Here's the new level which introduces bounce walls. The old level immediately combined bounce walls with wrap walls, and I wanted to start simpler than that. I was at first afraid of using more than two linked goal nodes, but then I realized that more goal nodes doesn't always make a level more difficult. In this case, they actually call out what the player is supposed to be doing.

I apply the same idea here. This used to be the first level with bounce walls, now it's the second. I added the northern and southern linked goal node to again call out to the player what it is they're supposed to be doing. It also prevents you from simply moving to the western node, hitting it, and moving around the bounce wall to hit the eastern node.

This is the new introductory level for switches. It really looks insane, but the idea is that only one switch is available at any time, and hitting each switch closes off the part of the level you're done with and shoves you on to the next part. It ends with a switch that turns off the kill walls surrounding the central goal item. I believe I got too fancy by adding the enemy and the warp walls. I may just delete them to make this a bit more reasonable.

All in all, I think these are good changes. These levels are also a lot more aesthetically pleasing than some of the levels they're replacing. Ideally, I want every level in the game to follow the example set by this level:

It's dynamic, it has good aesthetic and mechanical composition, and it uses all or most of the space without creating clutter or overly complex structures. I think if I can have 25-35 levels that do that, I'll be satisfied with calling this game "done."

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

No post this week either

Whoops, I made plans to keep updating this blog through Thanksgiving, but I messed those up. I'll try to have a post for next week for sure.

No new post this week

Yup, I definitely took this week off. For reasons.

Four walls and a roof

Today's Build is up Here!

So I set out to re-redesign that level I talked about in my last post, and the results were really great. I continued to explore what it is that I like about those three diamond-shaped kill walls in the center of the level, and I found that they just break up the level really nicely. They also add an amount of danger to just moving about the level - the player arrow is quite floaty still, so it's not impossible to accidentally run straight into them and die. More than that, I really like what begins to happen when you start putting walls between each of the diamonds:

Earlier in the project, I wanted to be able to add "rooms" to levels. The idea would be that you could add sequentiality to puzzles by forcing people to do one puzzle before another. I actually did this already in the first Warp Wall level:

You have to figure out how to get to the bottom-left chamber before heading out and attacking the enemy. You get to experience the mechanic that the level is about before being quizzed at the end about the correct way to use it. I never figured out until now that, with switches, I can just divide normal-sized levels into digestible chunks. So the image I posted up top can turn into this:

And then this:

Before you know it, you've solved four puzzles in one level without even clearing a goal. So far, this game has had very few secondary goals. Sometimes there was a level with multiple primary goals (clearing linked nodes, killing enemies, etc), but you could complete them all in whatever order you wished. So I'm really happy to have a level that works in a completely different way.

Also, as a side note, the little red arrows that are attached to enemies and shoot projectiles are their own prefab. I've been waiting a while to find a level that they really needed to be used on.

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

Early Update! Revised level and a new level.

This week's build available here!

As I will be out this weekend for Halloween, I made sure to update early this week. I revised the level I added last week, and added a new level on top of that one. I'm still not happy with the level I revised, since it actually is just sort of a worse version of a level I've already done:

Both levels require you to bounce off of an enemy's shield into a boost plate in order to clear yellow goals, then has you using those boost plates to clear the enemies. The above level actually does this a lot more elegantly than the bottom, newer level. So I'll be working on revising that level again.

I did find myself enjoying the pattern of three kill walls arranged in the center of the level though. I had an idea for a really simple level where you just slalom through a series of linked nodes, and it's actually pretty satisfying to solve. These dexterity puzzles are a nice contrast to the other levels, which are almost all timing-based.

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

Continued Guideline improvements, start of a new level

New build is HERE

I didn't add much this week, but I did improve how warp walls work and, by extension, how guidelines work. Last week's final level made me realize that guidelines don't show an accurate path when going through wrap walls (the blue ones) at an extreme angle. This lead me to realize that I'm wrapping from the player's current position, not from the position they will be at when they hit the warp wall. I fixed that, so now wraps should be more intuitive than they used to be.

It at least makes the final level (or what used to be the final level) a bit easier. I played with extending the length of the guideline, but in most cases the current max is the right amount. I might still extend it for specific levels, like the one above, but I also like that there can be levels where you have to dead reckon where you will end up.

I also began work on a new level. I don't like where it is right now, but I wanted to have *something* new for the blog post this week, so enjoy.

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

Busy Weekend, No Post

I spent this weekend running around to events I planned to be at and events I didn't plan to be at. Next week, however, I will be back with an update!

Fun with Moving, switching, bouncing, warping walls!

(New build is up HERE)

So I basically tore up one of the levels I was least satisfied with, and built a new one that extended some of the ideas in another level I wasn't satisfied with. It took me more time than I'm comfortable admitting to do this, but most of that was trying to make the old level bend over backwards to work right until I basically scrapped it entirely and did something new.

I believe the only pieces of this level that were in the old version are the moving, flippable bounce walls and the switch that flips them. The enemy in the center was never really that compelling, and I always wanted to do something interesting with shooting around the level using the bounce walls. So I deleted the enemy and added bounce walls and warp walls that need to be navigated all at once to engage every linked node simultaneously. It's still a bit unwieldy, but I'm much happier with this level than with the previous.

Charging up noise is, as always, by Javier Zumer. I'm using it and modifying it under this license.

Trying to get back on the wagon

(Newest build is up here!)

Sorry for not updating last week! I've not been particularly on the ball about devoting more time to the blog. I'm still fussing with new ideas for levels, and I'm not exactly sure where I'm going with some of them. There have also been an unusually high number of events going on lately.

Today I added hexagonal columns to the game. They function just as walls do, can be timed, can be turned off/on, and come in default, warp, wrap, and bounce varieties. I also added a script that simply causes things to rotate. Rotating hexagonal columns present a timing puzzle to the player, since you have to wait for the right moment to hit the column at the correct angle.

The column will move between the time that you begin your charge and the time that you hit the column, so you'll have to anticipate where the column will be before you begin your charge.

I still want to tweak these most recent levels a lot - some of them are not quite where I want them to be. I think I might need to use more boost plates.

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

Simple Update

(The new build is right here!)

Not a big update this week. Just a really simple new level. I thought the kill wall introduction should start with as few additional mechanics as possible. Additionally, I found a way to focus on a different aspect of the kill wall. Other than the fact that it, you know, kills you, it causes the player to need to worry about the terrain of the level in a new way. The level I added feels a lot more like a race track than any of the other levels have felt. Might be a lot more design space there in the future.

I also want to try to be better at posting more pictures, even when I don't have much new to show. So here's the new level. Very simple:

As per usual, the charging-up noise is by Javier Zumer. I am using and modifying it with this license.

Better Kill Wall Levels

(New build can be found here!)

Just some minor level tweaks this week. Well, not minor. I basically redid two levels because I wasn't happy with the way the game introduced kill walls (the red ones that destroy the player on contact).

Kill walls were introduced as sort of a "lull" in difficulty, but red walls that kill you if you touch them isn't a particularly complex video game concept, and I didn't like that players who encountered them seemed surprised that there would be a lull at that moment. The levels that I added are a little complex, but we'll see how they feel in a week or two.

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

No new post this week. Labor day holiday.

This weekend I spent all my time getting ready for Labor Day weekend. That means no update this week.

Guide Line improvements this week

(New build is up here!)

Not much different this week, I'm afraid. I changed the look of the enemy guidelines because they were far too distracting for my liking. I also fixed a bug I had forgotten about that caused secondary guidelines to remain if the thing emitting them is destroyed.

As always, the charging up noise is by Javier Zumer and I'm using/modifying it with this license.

Enemy guidelines, and an actually accessible new level

(New build up here!)

This week I added guidelines to the enemy's projectile shooting ability... I'm not happy with the way it looks, but I'm positive it's a necessary feature. I'll likely tweak this a lot as I go on. As an aside, I'm super unhappy with how Unity handles line renderers and the accessibility of parameters like start color and end color. You can easily set them in code, but you can't easily read them in code. Frustrating.

I goofed last week and made a build that didn't include the new level I made! Fixed that. As I said previously, it needs work, but it plays with an interesting idea, and that's satisfying.

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

One new level, Enemy Guidelines in the Works

(The new build is up here!)

Hi all, just a small update this week (three festivals are happening this weekend!). I actually had another level planned, and wasn't happy with it at all. So I scrapped it and worked in a new level 22. I made sure to allow enemy projectiles to activate switches, and I'm playing around in that space finally.

One of the reasons I had to cut the other level short was because I realized that I wanted to add guidelines to the enemy projectile shooters, so you would always know where they were going to shoot. Unfortunately, my existing code for player guidelines is a lot less flexible than I remembered. So that will be what I focus on for next week.

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

New sound effects, new particles, and a new level

(New build can be found right here!)

Despite being robbed of several hours of productivity by Hearthstone, I managed to get a little something completed this week. The sound effects I mentioned in last week's post are in, so now a chime plays when you reach 100% charge, and a "bump" sound effect plays when you charge into a wall and are temporarily stunned.

I also added a new level. It was unexpected, really. I meant to make a two-puzzle level that you had to switch between using two switches. Then I played with walls that were both on timers and attached to switches, and then I tried a level where you have to hit several switches in sequence to make it around a circuit. The level I ended up with is simple to complete once you've figured out the trick. I have no idea how difficult it is to figure out the trick, though, so I'll have to get this one tested.

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

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.

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.

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.

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

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.

Womp womp, no update today

This weekend I am in San Francisco helping a friend of mine QA her game for its upcoming release on the PS4! If you like platforming, you'll like it. If you like space, you'll like it. If you like cute animals, you'll like it. And, if you like heart-crushingly tragic yet ultimately cathartic stories, you'll really like it.

This week I had intended to do the treatment I did for the first 5 or so levels on the rest of the game. I began working on this on Sunday, after last week's update was done. I'd planned on continuing work throughout Monday, Tuesday, and Wednesday, but I really only had Monday, as Tuesday is always a packed day for me and Wednesday I spent packing (My trip began Thursday after work, and continues into Monday the 27th).

I also thought I might get some work done on the plane and possibly here, in San Fran. Unfortunately, this is not possible. So, no new build this week. Sorry!

I have come to some tentative conclusions about the progression of levels in Pierce. One is that I want to push the introduction of enemies back a bit. I have wall-based concepts, like Wrap and Bounce walls, out of the way early. And I have goal-based concepts, like basic goals, multi-hit goals, and linked goals, also out of the way early (early, in this case, being before level 5 or so). I have modifying concepts like movement, timers, and switches, but they all kind of show up in a rush towards the end of the game, along with boost pads. Enemies are an important goal-based concept, but I think I can wait a little bit longer before introducing them. Maybe I'll introduce moving elements before then. Expect to see the results of this next week.

Lights, Camera, and Level Polish

This week's build is up here!

No super-visible upgrades this week, except I've made tweaks to a few of the earliest 5 levels (Most notably, levels 3 and 5). I wanted more of the levels in Pierce to have the kind of composition that the later levels have. Visual balance and focus are important, to me. I was going to revise them more drastically, but I held myself back. I think the existing designs still hold merit, and I'll see if I want to trash them later.

In the case of level 5, I think bringing the wrap walls inwards, detaching the bounce wall, and evenly spacing the linked nodes makes each element easier to observe and learn about. I think the following is a bit more visually intuitive than the previous design:

I particularly went back and forth on level 4, which is the introduction to linked goal nodes. I wanted to redo the level so that it matched the layout of level 3, but with linked goal nodes instead of normal goals. This is a technique I use later in the game to teach boost nodes and switches.

On the left, level 14 introduces Warp Walls. On the right, level 15 introduces Boost Plates

I use a level the player has already solved as an environment to introduce a new mechanic. It doesn't seem to work as well for linked goal nodes. I think I want as little noise as possible in levels in which I introduce new goal types...

I made the main camera and directional light which appear in each scene into prefabs. This was something I've been meaning to do for a while. This way, I can make lighting and camera adjustments once, and not have to adjust them by hand in every scene. I've never needed to, until now. I've adjusted the light intensity down in each level by 40%. It's difficult to get a sense of how bright the levels are going to be after they're built. And lights don't build from scene to scene in-engine, so I'm often playing with un-built lighting while I'm working. We'l see how this looks.

Oh and as always, the charging-up noise is by Javier Zumer. It's being used under this license. I've modified it.

A piece of the Panel Pie

New build is up here!

This week I decided to try to better visualize the player's progress towards clearing each goal. I remember there was a player at Indie City Games who didn't recognize that the goal in one level required 8 hits to clear, so I wanted to find a way to call this out more obviously to the player. I decided the perfect way to do this is to re-use the panel I just implemented for linked goals. Here's how it looks:

In the picture above, the player is about to hit a goal that requires 8 hits to clear. Currently, there are two hits, and the panel is two eighths full.

And here the player has passed through the goal for their third hit. The text shows 3/8, and three eighths of the panel have been filled.

And so on and so on.

Next week, I want to re-examine my level pacing. Specifically, I want to see if I can be introducing new concepts at a more structured pace. I'm thinking a new concept every three levels, with a break after every six levels for a more complex, challenging level.

I should also finally decide what happens when you complete a level and then die. Currently, the fail panel overlaps the win panel, so you technically die.

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

Small updates to an irksome level

New builds is here

Not a big update this week. Hardly an update at all - I was distracted during this week and gone during this weekend. I tweaked level 10 (the very annoying one with two crossed timed walls) to try to make it more palatable. The interval at which the walls swap is longer, and I've moved the goals inward a bit. I also made the middle obstacle much larger.

Hopefully this makes the level easier, and the solution more obvious. So far it's been fairly inscrutable.

As always, charging-up noise is by Javier Zumer, and is being used/modified by me under this license.

Visible timers and further bug fixes to lines

The newest build is up here!

Not a huge update today. I implemented radial timers on linked goal nodes so that you can see how much time is ticking down as you attempt to clear that goal. In Gerald Kelley's Abzorb postmortem, he mentioned that in his game players rarely if ever paid attention to elements outside of a very tight radius around the player. If that holds true for Pierce, players won't notice the radial timers I've put in. My hypothesis is that, in Pierce, player's attentions are less focused on the arrow and more focused on the obstacles. We'll see.

I also cleaned up a bug with guide lines which caused guide lines to linger erroneously. It was most noticeable when projecting guidelines through two wrap walls of different lengths. Should be good now!

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

Indie City Games feedback and progress.

Sorry! No new build this week!

I happened to be very swamped with work and other things that needed taking care of during the time I usually devote to working on Pierce. I did, however, take the game out to show to some developers at a meetup called Indie City Games. If you're a game developer and in Chicago, you should really think about going. I got a small handful of people to play, and their feedback was interesting. Here's what I found out:

• The numbers above goals which require X/X hits to destroy need to be more noticeable. Maybe they could also flash when they reset to zero.
• The linked goals should give way more feedback, considering the time limit you have to complete them in is not static from level to level. They also, come to think of it, could use some visual marker to show which linked nodes are linked together. This has been keeping me from implementing levels with multiple groups of linked nodes. It also would clear up some confusion with players believing that non-linked nodes are linked. And FURTHERMORE, if I'm visually showing which linked nodes are linked, I need to also be visually showing which objects correspond to which switch. This was a big bullet.
• Level 10 is by far the most hated level in the game! This doesn't exactly surprise me. The timing puzzle in that level is difficult to figure out. I'm convinced that the puzzle has merit, but I clearly need to tweak it to be less frustrating.
• People seem to like the feel of the game, even watching it, before they've played it. The charging mechanic makes people feel excited. The game, "Pops," one person said.
• People also seem to like the feeling of being able to solve all the parts of a level in a single charge. That was surprising, but not in hindsight. The feedback for bursting a goal seems to be at a good level. People really want to explode those goals, and explode as many at once as possible... Some of my best levels right now can't be solved except in at least two charges... That's probably okay, since I still give people the joy of bursting several orbs in a single go. But it's important to know that in the future a challenge mode could exist where the game counts how many charges you use, and grades you using that number. Kind of like the "par" at a golf course.

Next week: I'll at least have started on addressing those first two bullets.

Linework, Continued

This week's build can be played here!

Not a big update this week. I added the guideline functionality to warp walls, and did some polishing up on how the lines are displayed. Of note, guide lines colliding with bounce walls will more accurately show you where the player is going to go. See, the player is displaced by a distance proportional to its length, so instead displaying the guidelines like this:

It's more accurate to display them like this:

Not as pretty, but I plan to eventually let all guidelines intelligently adjust their start and end widths so that it seems like one contiguous line.

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

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.

Post-GDC Shenanigans

This week was GDC: the Game Developer's Conference! I had a ton of fun and met a lot of great new people. I did not, however, work on Pierce. Next week, expect more developments with switches.

Timers and Interfaces

(New build is up here!)

Hi all! Just a quick update before I head out to the Game Developer's Conference this weekend. You won't see a lot different in this week's build, but timers have been rebuilt. This does mean that the timed walls on level 10 should now NEVER BE OUT OF SYNC. Hopefully that is the case.

I argued with myself over exactly how to implement an interface through which things could be timed. I now have I timable interface (which I should probably rename ITimable) which is being implemented by a "timedblink" script which is attached to default walls. A separate game object, called a Timer, has a script which takes in a public list of game objects and, on a set interval, calls the "DoEachInterval" method of any component of type timable it can find attached to any of the objects in its list of game objects.

I know that there's probably a much neater way to implement this, but for now I'll see how this is working. Switches will likely follow a similar structure, with a switchable interface attached to things I want to be able to switch on and off and also an actual switch object that the player must charge through in order to trigger.

And as always, the charging-up noise is by Javier Zumer. I'm using it under this license and have modified it.

Kill walls and players

(New build is up here!)

This week is just a small update. I added a level which incorporates kill walls, which are a wall type that I made a few weeks ago but never implemented. I realized in making this new level that I might want to figure out what I want to happen when the player dies *and* completes the level at the same time. For now, I've just made it difficult for the player to die and simultaneously complete the level.

I also know that I want to do away with timed walls. Instead, I should just make a "Timer" script that is able to call methods and change properties on given objects. That way I can continue to make timed walls, but I don't have to make *new* timed walls if I wanted to make, say, timed warp walls or timed bounce walls. Or even timed enemies. I can also have one timer be in charge of multiple objects. This way, I'll always know that two or more timed objects remain in sync with one another (currently, the two timed walls in level 10 sometimes become desynchronized).

Finally, I want to create switches which the player can flip by charging through. Three is often a magic number, and if I created switches then I would have switches, timers, and movement as three modifiers that can be applied to walls and enemies. I would also have bounce, warp, and wrap walls as three objects which help the player. And enemies, default walls, and kill walls are three types of obstacles. Finally, regular goals, linked goals, and enemies are three types of goals. Helping objects, hindering objects, and goals, with modifiers which can mutate all of the above. Once I have switches, I might be satisfied with features, and start rebuilding and re-editing levels.

Or maybe I end up not liking how switches play. That could happen too. Anyway, timers and switches will hopefully happen by next week.

Oh, and as always, the charging-up noise is by Javier Zumer, is being used under this license, and has been edited by me.

Oh no! Missed a Sunday!

Ack! I missed a Sunday! Sorry guys, but I moved last week. There was hypothetically time in my schedule to still make an update, but as time went on that window rapidly closed. I even got so busy I didn't update the blog until Wednesday! Sheesh! I should at least have *something* for the blog by this weekend, even if it's just a small update.

Oh, and I'll be heading to GDC from the 12th to the 19th, so it is likely that I won't have an update for the blog on the 20th (hoping to actually get *ahead* enough to have an update ready before I leave on Saturday the 12th though).

Movable Type

(New build can be found right here! Please don't play with your volume turned to max. I'm still trying to figure out how I can fix the way things sound over WebGL.)

This week I added two levels. Well, I modified the latest level and added a new one. I realized that the function of the green warp walls is much better illustrated if you show them bridging an impassable boundary, like a default wall. Then the second set of warp walls shows how they can work over a distance and how they can be used to turn the player.

The new level uses some very crude boost plates. They were really easy to prototype, but I think if I were to finish them I'd need to work on them a bunch more. We'll see how they go.

Finally, I'm not using them in any levels yet, but I made some red blocks which simply kill the player upon contact. Total features so far:

• Charging
• Goals
• Linked Goals
• Wrap walls
• Bounce walls
• Warp walls
• Boost plates
• Enemies
• Timed Walls
• Kill Walls

I think that's about it. There are other things I could imagine wanting to do (like objects which slowly get pulled towards the player, or switches that flip on/off when charged through), but for now I think I need to decide whether or not to cut some features. The recently added boost plates don't do much that can't be done with bounce walls, but they do give me substantially more control...

Charge-up noise by Javier Zumer. Used under this license. Modified by me.

Sick Day today, but WebGL is here to stay!

Here's a link to a build you can actually run on Chrome and Firefox!

Hi all, I've been sick this week, and busy figuring out some things for my upcoming move, so unfortunately there's no new build this week. I did, however, have time to look into publishing the game using Unity's WebGL platform. Expect the audio for certain sound effects to be a bit harsh, and expect shadows to appear jagged. I'll see in future weeks if there's anything I can do about that. Due to the inherent differences between web player and WebGL, there might not much.

As always, charge-up noise is by Javier Zumer, and is being used under this license. It has been edited by me.

Reconfiguring Wall Logic, and adding Warp Walls

(New Build is up here!)

This week I did exactly what the title says - I added a new wall type! Okay, it's not that exciting. I want to play around with a type of wall that simply teleports you to a set location. Not sure if I want to make it a one-way trip or not, though that could be interesting... I'm calling this new type of wall "Warp Walls." I now have warp walls and wrap walls, so it isn't confusing at all.

I didn't get to really play around with them since I spent most of my time reconfiguring how all walls work. I used to have the code governing what happens when a player (or enemy projectile) hits a certain wall on that player (or on that projectile, as the case may be). In other words, it was up to the player or projectile to figure out what it should do when it hit a certain surface. This duplicates code and is a bit counterintuitive. On top of that, it makes the player script and enemy projectile script longer than they need to be. When I realized I really wanted to have the code for the warp walls on the actual wall, I realized I should probably bite the bullet and make the change for all wall types. Hopefully this makes my code cleaner and easier to deal with for the future.

And as always, charge-up noise is courtesy of Javier Zumer under this license. It has been modified by me. 

Getting a Move On (In more ways than one)

(New build can be found here!)

Hey all, sorry about not posting last week. I'll try to continue posting consistently, but I'm actually moving BACK to Chicago very soon, so things might get a bit rocky.

Speaking of moving, this week I decided to take the game up to 15 levels. The 15th level is brand new, while levels 12, 13, and 14 are earlier levels with tweaked goals and node-based movement added in.

I'm not sure how many levels I want the game to have in the end, but I'll probably continue to make several new levels in a week, then edit down. That's what I'll likely do for next week.

And again, the charge-up noise is by Javier Zumer, edited by me, used under this license.

No update this week!

This was a quite hectic week for me, and unfortunately I think I'll be taking Sunday off to recover. No update this week, sorry!

Still mulling over casting. Also, moving things!

(New build is here! 12 Levels now!)

This post comes after a long weekend looking at apartments. I am TIRED! But feeling accomplished. Last week I settled on how I should be handling casting. This week I started making levels which took advantage of that, had some second thoughts immediately. I had an hour-long conversation with my roommate about it, and came away with the resolution to just ride this out.

Both methods produce very similar results, and it isn't difficult to change between the two of them. So I'll just continue to develop the game and see if I run into any problems that make me want to switch. Time will tell if this is a good or bad idea.

On the subject of actually continuing to develop the game, I added a node-based movement script to give objects some simple patrol movement capabilities. I feel it opens up a lot of design space, but we'll have to see just how much in the coming weeks.

As always, the charging-up sound is by Javier Zumer, and is being used under this license. It has been modified by me.

Brand New Year

The latest build is up here!

Well I'm back to work on the game after taking a break for the Holidays. This week, I made a decision about which method of warping I wanted to use, fine-tuned that behavior, and implemented a slight tweak to an existing feature at the advice of a friend.

First, I decided that warping with a raycast oriented to the normal of the warp wall hit was the way to go. Last time, I detailed how I could either raycast backwards from the player, backwards from the surface of the wall we're warping through, or backwards from the player using a spherecast. They each had benefits and drawbacks, but if I raycast backwards from the wall I can actually make the player move in more interesting ways. Hopefully I'll have a new level or two by next week to show what I mean.

Warping in this way can cause the player to drift sideways slightly, so I needed to figure out a way to keep the player from moving too erratically in places where they're looping many times through two warp walls. In cases where the difference isn't too large, the warping will actually use a raycast backwards from the player - since that doesn't cause any drift. So I sort of hybridized the warping.

And finally, I used to have warp walls and bounce walls light up as you are charging forward, but a friend of mine pointed out that it makes so much more sense for this to happen when you're building up your charge attack (the double meaning of "charge" has been a headache on this project). Anyway, walls now change color when you're getting ready to charge, not while you're already charging.

And as always, the charge-up (see what I mean?) sound is a sound by Javier Zumer, used and modified by me under this license.