Games

Lawyer Guy: Sweet Dreams

Note: this article is the postmortem for a Lawyer Guy level. To download the level itself, head on over to the Lawyer Guy website!


With the first level finished, I thought it would be useful to try and quickly iterate on it, and produce a follow-up as soon as possible. I spent a few weeks coming up with ideas for levels and game mechanics – some of the ideas I came up with in this period wouldn’t be implemented in the game until years later.

The first level was a random mess of ideas, I’d simply thrown everything I had implemented into one level to see how it played. For the second level, I wanted to begin a process of curation, and reduce the number of moving parts in the level a bit. I also wanted to add a few new features and address some player feedback from the first level.

Making The Level

Everybody, at some point in their life, looks at a blank piece of paper and says ‘well, now what?’. Over the years, I’ve come to develop a process that I’ve come to use for pretty much everything – writing, music, graphic design, etc. Any time I have an idea (walking to work, taking a shower, in a dream, etc), I write it down, somewhere. These ideas are normally non-specific and lack any kind of context. If I’m short on ideas, I will start doodling or free-writing. The process of actually making the thing is one of curation – can I make a level out of what I’ve got? Are there any common elements in the things I’ve made? Regardless of the medium, there normally is.

This time, I doodled a block that the player could toggle on and off by shooting it, which appeared in a lot of my rhythm group ideas, and ended up probably being the single most-used mechanic in the entire game – it’s used in almost every single level. It’s also the most obvious piece of design in the whole game – there’s two ways that lawyer guy can interact with things, by shooting them, and by jumping on them, so it makes sense to have blocks that respond to both. There’s tons of different scenarios where you can use this object – it can be toggled by the player and enemies, and toggling it can be either advantageous or disadvantageous. If anything, I regret not using it more in this particular level.

This level also introduces three new enemies – the chomperbot, an enemy that shoots arcing projectiles, the walkerboyd, an enemy that walks along with physics, and the time bomb, a stationary object that creates a deadly explosion if left on screen for too long. At this stage, all of the enemy designs (and names) are strictly temporary. I used these enemies because I thought they interacted with the level’s main mechanic in interesting ways. The chomperbot sets off the toggle blocks – it can shoot the floor out from underneath lawyer guy, which creates some interesting gameplay. Because the projectiles arc, chomperbot projectiles only end up toggling one or two toggle blocks, which keeps them from being too difficult. I picked the walkerboyd because its movement is affected by the layout of the toggle blocks, though, in retrospect, I don’t think that mechanic got nearly enough use in this level. The time bomb puts a constant time pressure on the player during the final section of the level, which is a structural idea that I will return to in future Lawyer Guy levels.

Goals For Designing Enemies

After I think of an enemy, I will typically try and think of some scenarios in which it might be used. The more scenarios I can think of, the more likely I am to actually implement that enemy in the game. This process came about because if my my mistakes in designing several enemies, mostly for this level, which sounded really cool but which ended up being useless. I had the idea for an enemy which you could only destroy by dashing through it. This proved difficult to tutorialise, and not very useful. In most situations dashing has no drawbacks and can be done additionally to whatever else Lawyer Guy is doing. Any situation in which dashing would be difficult or disadvantageous is just going to end up being frustrating. I never used the enemy, although I accidentally left one at the bottom of the level, and if you leave the game on for several minutes without moving, he will float up towards you and generally get in your way. He is affectionately now known as the dilly-dally ghost.

Another unused enemy idea was for a slime-like enemy that coated walls and floors in noxious goo. Not only was this goo a pain in the ass to implement, but I again had a problem – there are really not many uses for this enemy. Besides, if the goo is permenant, the enemy has the ability to make the level permenantly unbeatable, whereas if it isn’t, there is instead a rather drawn-out process that involves Lawyer Guy hanging around and waiting for the goo to dissipate. This enemy is probably the thing in the game I wasted the most time on, but at least he helped me to never again fall into that trap.

When designing enemies, it is useful to think of them as part of a system that includes other instances of themselves, the level and its shape, other objects in the game, other enemies, and Lawyer Guy himself. The more interactions between the different parts of these systems, the more interesting and versatile the enemy will be. All of the enemies in this stage have a way of turning the toggle blocks on and off, and all of them have behaviours that are affected either by Lawyer Guy’s position or by the level geometry. This means that encounters with these enemies never feel exactly the same, as long as you vary the layouts and level geometry.

A universal property of enemies in Lawyer Guy is that they have long wind-up animations for when they’re going to do something (normally shoot a projectile), and if you shoot them while they’re in this animation, it will cancel the wind-up. This is a great piece of game design, because it means that the player may try and adjust their priorities on the fly, prioritising enemies that are in their firing animation, or keeping track of time and planning to shoot enemies to interrupt all of their animations. However, I can take no credit for it, it was a total accident. When an enemy in Lawyer Guy is hit, it briefly turns white. This isn’t a shader or anything, it’s a separate animation, and if another animation is playing, it’ll override that animation. Enemies firing projectiles are timed directly to their animations instead of any external timer because it’s easy. So there you have it! My laziness finally paid off!

One other note on enemies: flying or floating enemies are cool and very versatile because you don’t have to worry about them falling into pits, so you can use them in precarious locations. But in Lawyer Guy, I am also more likely to implement flying enemies because I don’t have to implement collisions between the level geometry and various blocks (which vary on an enemy-by-enemy basis). Also they don’t need a walk cycle or anything. Man, these things are great.

Unexpectedly Emergent Properties

When I first designed the vertical area in the middle of the level, I’d intended to use the ‘cannon’ enemies to destroy the blocks. The idea was simple: you had to make the cannon shoot the floor out from underneath you, and drop down to the next level. The walkerboyd enemies were constantly spawning in up above you an pouring down, so you had to act fast.

However, when I tested out the area, I found that shooting the walkerboyds made a hole in the floor. Why? Because when I created the eyeblock object, I set it to be triggered by just about every projectile in the game, and, weirdly enough, this included the explosion sprite that appeared when enemies are destroyed. But, as it turned out, this way was a lot more fun. I removed the cannons entirely (making the cannon in the previous section feel a bit out-of-place).

This actually led to some bugs. An explosion will always generate a 2-block wide hole in the floor, but another explosion adjacent to it will generate two one-block holes in the floor. Lawyer Guy can walk over these holes without falling down them, because he moves at a speed of two pixels per frame, and his hitbox is as wide as the holes (they’re both 32 pixels in width). However, if he’s hit by an enemy, he enters a hitstun animation in which he moves at only 1px per frame, and is thus able to fall down the hole. This might sound like an edge case to you, but it happened to several playtesters. Imagine all the weird edge-cases they haven’t found! Where’s that stock image of an iceberg when you need it?

There are two ways of fixing this. Either change the enemy physics, or Lawyer Guy’s physics, or the block logic, so that it can’t happen (difficult and fiddly), or put spikes on walls so that the player can end themselves. The second is the coward’s way out, which means it’s what I’ll inevitably do.

Increasing Intensity

The previous level kind of petered out and just ended when it ran out of ideas. For this level, I wanted to implement some kind of final challenge, a kind of culmination of what had come before. I looked into ways to make a section of the level more intense, somehow, and I ended up using the tried-and-true method of a time limit. I added an ‘enemy’ called a tick bomb, a stationary object that you have to destroy before the counter reaches zero. Obviously, because Lawyer Guy shoots horizontally, this would have to be a vertical section. For some ungodly reason, instead of making the whole section using the toggle blocks, I opted to use horizontal moving platforms instead – which worked well, but I can’t help but feel it was a bit late in the game to introduce them.

This section did what it set out to do, and I was so pleased with the structure of the stage as a whole that I used this idea (difficult bit at the end) in the next two levels as well. I also used the specific motive of the horizontally moving platforms, but expanded, in the next level. However, with the benefit of hindsight, I think this section might have been a bit too difficult, particularly the middle part. In a level full of toggle blocks, this should definitely have been more of a toggle block challenge.

Ladders Bad

The core movement system of Lawyer Guy is very, very similar to that of the NES Mega Man games by Capcom. As I mentioned in my previous article [link to that], vertical movement in those games is dominated by the ladder, because there is no vertical scrolling. If you’re at the border between two screens, all the action pauses, and then the screen scrolls, and then it restarts, so jumping up between screens wasn’t used either (though falling is, a few times). Lawyer Guy has no such limitation – so are ladders even necessary? After all, it seemed like their only purpose was to make vertical screen transitions easier.

The short answer is no, ladders are not necessary, and you can build a better game without them. Ladders are boring. When moving along ladders, Mega Man is very slow. The developers seemed to acknowledge this, because he moves faster up and down ladders in every successive Mega Man game!

Ladders are also dull, because they give you only one degree of Freedom. In normal gameplay, you can move left and right, and move up and down by jumping. On ladders, you can only move up and down. There are only so many bits of fun gameplay you can make with this, and in addition, getting knocked off ladders just feels bad.

Most importantly, designing vertical sections is fun! They offer some unique gameplay. Downwards vertical sections are interesting, because you normally have to destroy or circumnavigate some kind of obstacle that’s preventing you from falling. Upward vertical sections are nice to design, because you can make them a bit more difficult, platforming-wise, than other parts of the level – if the player falls off, they’ll likely land on a platform that’s lower down. And the methods of upward locomotion in Lawyer Guy are all fun to interact with. This level uses four – toggle blocks, springs, moving platforms and tractor beams. Each one poses a unique gameplay challenges and possibilities. However, I think I went a bit overboard – I don’t think having both springs and tractor beams adds very much, gameplay-wise.

Playtester Feedback

This level was tested more thoroughly than the previous Lawyer Guy level, and it probably shows. However, before I talk about the feedback, I should mention that almost all of it was backported to the previous level, so it might seem even more obvious to you now.I added screenshake to the game. Screenshake is really fun! It can make pretty much anything feel impactful, and it makes the game fun to interact with. I also added a shower of debris that comes form enemies when you destroy them, which I like to think of as a kind of visual reward for taking out enemies. People in game design circles have recently started referring to this as ‘juice’. One problem: the screen used to shake uncontrollably every time Lawyer Guy shot his standard issue Lawyer Pistol. At the request of playtesters, I took that out, but I increased the amount of bass on the gun sound effect to compensate.

I mentioned the healthbar in the previous article, so I won’t labour the point here. The healthbar flashing white was inspired by Cave Story, and really helped players more easily get a grasp of how much damage each enemy did. The white creates an area of contrast that draws the eye toward it like a magnet (be prepared for that simile, it will return).

The widescreen aspect ratio actually came as a result of trying to design this area:

This wouldn’t fit on the screen properly without a widescreen aspect ratio. Even with one, it’s more than a little cramped. In retrospect, this area will definitely not be appearing in the final game. It’s cramped, and there’s just too much stuff going on.

Some other things that were changed due to playtester feedback:

  • Initially, the toggle blocks did not flash white when they were toggled, and the sound effect was more subtle. A white flash might not seem like much, but it draws the eye to the block like a magnet. In a future version of the game, I might experiment with giving the block a different design, or making it change colour. It might seem like a nitpicky change, but this game moves very fast, and there’s a lot of visual information to digest – if it’s not instantly readable it will likely get lost in the mix.
  • Projectiles that hit Lawyer Guy are now destroyed. In theory, having an enemy that can shoot the floor out from under Lawyer Guy is cool. In practice, it’s frustrating, because first, Lawyer Guy will get hitstunned, and then the platform will disappear before he finishes his hitstun animation – leading to instant death. To players, this felt unfair. The hitstun animation was fairly long, and a hit would normally lead to death regardless, but destroying the platform felt like rubbing salt into the wound. When I made projectiles stop when they reached Lawyer Guy, I noticed that players didn’t change their behaviour – they still attempted to dodge, rather than taking the hit. They also still often encountered platforms being destroyed, which they were standing on, had just been standing on, or were going to jump to – so the effects of the mechanic were made more tolerable, but were still interesting enough.
  • Speaking of, I reduced the duration of the hitstun animation by about 1/3rd. Previously, being hit while standing on a small platform was pretty much instant death (castlevania style) but reducing the length of the animation made the difficulty feel fairer. I always get flashbacks of Mega Man 3, a game where seemingly the sole purpose of every enemy is to push poor Mega Man into a pit – again, it just feels unfair. The original hitstun duration was 46 frames, and it was reduced to 32 frames. At a rate of 1px/frame, this means that it’s exactly 32 pixels, or the width of a platform. In reality, though, the area of the platform you can actually stand on is much, much larger than that – something I’ll get onto in a future dev,og
  • This section – the one that I ended up changing the aspect ratio for – went through a significant number of revisions. It was originally three times (three times!) as long, and had some rather difficult platforming in order to reach the key, with multiple cannons and enemy spawners along the way. Not only was it ridiculously difficult, it wasn’t clear that players had to take this high route first. After a lot of squeezing, I managed to get into a single screen, but players still struggled, not seeing the key, taking the low route, and running into a locked door. Eventually, I added a ‘shine’ animation to the key, which seemed to fix it, but overall, this is still a rather cramped. overwhelming section of the level, and I wish I’d spent more time reworking it. The ‘shine effect’ on the key is very subtle, but I guess it planted the idea in my head well enough, because making objects sparkle, flash or vibrate is a great way to force the player to look at them, and it’s used a lot in Lawyer Guy, everything from enemy wind-ups to UI elements – so keep your eyes peeled!
  • One playtester managed to get Lawyer Guy stuck in the floor. I looked away for one second, and when I looked back, Lawyer Guy was lodged halfway into the floor. I asked ‘how did you get stuck in the floor like that?’. He said ‘I was just walking along and got stuck in the floor’. I was never able to reproduce the bug.

Everyone Is Bad At Games

People who play a lot of video games often get the idea that they can intuitively understand pretty much any game if you put it in front of them. Particularly a game as simple as Lawyer Guy – after all, it only has three buttons. This is not true, people don’t naturally intuit games, and any time you feel like you’re doing that, it’s because of some game designer who has designed a game specifically to make you feel like you have.

As evidence for this claim, I submit to you the tutorial for Lawyer Guy Demo 2. It has three main revisions. This is how the tutorial looked as of version 3.28:

Players were deeply confused by this. This early version of the tutorial didn’t have a key in it. When players saw a key later in the level, they didn’t know what it was for. You may be thinking ‘well if I saw it, I’d realize’, but I would contest that. People I’d known for years, who played lots of video games, even speedran a few, had trouble with this (that’s why video games have tutorials that say ‘put key in door’). Another big issue with this tutorial is that it doesn’t show that you can stand on the toggle block. In fact, it doesn’t always show that the toggle block does anything at all. Most players ended up shooting the toggle block while going for the enemy, accidentally deactivating it and not even realizing it was a thing.

Above is version 3.33, which does a bit better. The key is there. You can’t get through it without collecting the key, although a few people did accidentally collect the key and move or, or at least fail to recognize it later in the level. The biggest problem with this version was players not  shooting the toggle block. Many tried to jump on it, failed, and moved on to killing the enemy, assuming that it was part of the puzzle. The most common question I got was ‘why isn’t the door open? I’ve killed the enemy’.

The final version of this area removed the enemy entirely. With only one thing to shoot, most players finally twigged that they had to shoot the toggle block. A separate introductory area was added for each enemy.

The point of this rant is not to belittle my playtesters, because they did nothing wrong, they’re not especially bad at games, and they only helped me to untangle a bit of obtuse game design. My point is this: don’t assume that games have a universal language, or that games are things that people will implicitly ‘get’. They aren’t. Communicating all of this succinctly and without words is a challenge, and I know at some point I will need to use words in order to explain other aspects of the game (like checkpoints, which we’ll discuss in the next level’s article). If I do everything perfectly, the best I can hope for is that most people won’t notice, and that’s fine. Because nothing is worse than a wordy tutorial.

Lawyer Guy’s Oldest Bug

The average piece of software ships with 40,000 bugs. I made that number up, but it sounds about right to me. With Lawyer Guy, most of my bugs have been easy enough to track down and fix, because the scope of the game (particularly the physics and enemy behavior) is deliberately pretty small.

With one exception. The infamous toggle block bug, which went unfixed for two entire years, from mid-2015 to mid-2017, when the next Lawyer Guy level shipped.

The bug went something like this. Lawyer Guy uses his Standard Issue Lawyer Pistol to shoot a toggle block. 99% of the time, the toggle block toggles. But sometimes, it doesn’t. It plays the sound effect AND does the animation, but it doesn’t actually toggle.

I spent some considerable time tracking down this bug. I poured over the toggle block. It was a simple object – it held a single variable, the toggle state, which it toggled when it collided with the bullet object. It required a few physics special cases (mostly to do with Lawyer Guy toggling it while he was inside it) but nothing suspicious in the toggling itself. What kind of a world are we coming to in which toggling a boolean doesn’t work?

I tried everything. The bug would never happen in a debug environment, only if you actually started playing the level. When it did happen, the sound effect and the animation made it feel a bit like the game was gaslighting you – ‘oh, you did shoot the block, it was just in the other state before’. As a tester, I began to doubt my own eyes and ears. Maybe there was no bug, and I was just bad, along with everyone else. It wasn’t until I was making the next level that I figured it out. The toggle block logic is fine. However, sometimes, particularly if the player is pressing multiple inputs at once, or multiple inputs in quick succession, Lawyer Guy will shoot two bullets at once. On the same frame. The bullets, nestled perfectly inside one another, collided with the toggle block twice, toggling it twice, playing the animation and the sound, leaving the state unchanged. If you figured that out from my description, congratulations, would you like to come and help me debug the physics simulation software I write for my job?

(A final note: one eagle-eyed playtester did indeed figure it out – but only after I’d already fixed it in a future build. However, he should have kept his mouth shut, because now I’m going to send all my weirdest bugs to him).

Closing Thoughts

I was very excited at the end of the first Lawyer Guy level, because it was the first time that Lawyer Guy had worked as an actual game and not just a test area. But this level is the first level that feels like it’s from an actual game, and the structure, pacing and gameplay ideas within helped to crystalize the formula for future levels.

If you enjoyed this article, please take a look at the Lawyer Guy website, where you can download it (and other levels) for free. There’s also a form you can fill out to send me your feedback, and help me improve the game!


Last updated August 10, 2019.

Filed under: