Detail

Time and Animation Fixes

After the last update, I was hearing that player movement and animation was really weird from a few friends who occasionally play-test for me, so I checked it out on a few browsers. Sure enough, each browser handled the code I wrote differently. I’ve made some fixes that, while they don’t equalize gameplay throughout all browsers (curse you, Firefox), brings me a few steps closer to it.

While I’m talking about Firefox, here is a list of stuff it does wrong:

  • Indoor room border color is radically different than Chrome/Safari. I will probably have to change this to an image and just include padding for the room instead of border. This will be annoying because I will likely have to adjust the top and left values for evaluating where stuff is in the room.
  • You can’t hold down a key to move the player, you have to press it each time.
  • If I leave any console.log commands in, the game won’t start for Firefox clients who have Firebug installed, but the console panel disabled.

As far as the animation fixes go, I added booleans to check to see if the player was already in the middle of an animation. There’s one to check if the player is moving vertically, one to check if it’s moving horizontally, and one to see if the feet are still animating. Then, it won’t execute the same command again until the animation finishes, which accounts for people holding down arrows.

Lastly, I’m thinking about implementing time today in 0.2.3. To start, the only facet of time would be that clocks automatically update to the correct game time when you interact with them, and if the time is between a certain range, the game will let you go to bed and wake up the next morning. I can’t decide if I want time to constantly advance, or if it should advance by a few minutes every time you walk through a door. I’ll probably do consistent time, but they both have advantages.

Swinging arms, walking legs

Even though I don’t have the final sprites set up yet, I decided to go ahead and triple the number of sprites I need (sorry, Tim), and add walking animation. Now when you press a movement key, you slide in that direction instead of just warping there. In addition it cycles between three sprites (standing still, left foot forward, right foot forward) during the same time period of movement. Once again I used concurrent animations, so I hope the way I’m doing it is the best practice, because I’m starting to do it a lot. Here’s the new sprite file:

Player Sprite File

You’ll notice there’s no walking animation when you’re carrying objects, and that’s just laziness on my part. There will eventually be walking movement for every object (sorry again, Tim). I did manage to copy+paste+invert though, for the second outfit.

I also put together a map to keep myself sane with all the room numbers and door numbers. Now I can just reference this without having to double-check everything.

Game Rooms

Concurrent animations

I was having a problem with bullets killing people a few days ago, in that I could animate the person’s death either before the bullet hit the person (directly after the gun was shot) or after the bullet disappeared. This was because I was trying to fit that line of code in with the bullet animate() method somewhere. What I ended up doing was running the death animation on its own delay, dependent on how far the player is away from the dead person. Since bullet speed is directly related to how far it is away from something, it worked swimmingly.

In other good news, The One Electronic has agreed to create original music for the game! I asked him to start out with just a theme song for Hipster Dad, so we’ll see how it goes.

Other things to note with 0.1.9 are:

  • New outdoor areas, mostly just blank
  • Bug fixes on how doors work
  • Dead people don’t talk
  • Dead people don’t come back to life if you shoot them again
  • Hipster Dad’s name is now Warren
  • New “Play Again” button on death, still just refreshes the page though
  • Added placeholder music, which is muted by default
  • Added mute/unmute button

Outfit- and Equip-Dependent Messages and Interactions

Today I added the capability to return different interaction windows and different messages from objects based on which outfit the player is wearing and which item they currently have equipped. The process was kind of exhausting, so I will explain it here.

Firstly in the HTML, the element div has a class of interact or message as usual, but they also need a new class: outfit-dependent or equip-dependent or both. Then inside the div, instead of just having one span that contains the message or interaction, the div contains multiple spans, each of which are tagged with classes that look like this: “interact outfit0” or “message equip1″ where the number on the end of the equip or outfit matches with the player.outfit or player.playerSprite. The program then reads this number and returns the correct message or interactions based on what you’re holding or wearing.

The part that gave me trouble was priority. What if you have an message that needs to be returned for your outfit and a message that needs to be returned for your equipped item? That’s where the order of the spans come in. You enter them from least importance to greatest. So the last span in the div is the most important scenario. I’ll use a real game example for reference:

<div title=”The Earl of Southwestington” class=”stuck message person earl outfit-dependent equip-dependent”>

    <span class=”message outfit0″>”What are you doing outside in your underwear?”</span>

    <span class=”message outfit1″>”Hello. I’m not doing anything suspicious. I am the Earl of Southwestington.”</span>

    <span class=”message equip1″>”What are you going to do with that cake?”</span>

    <span class=”message equip2″>”HELP! A GUN!”</span>

</div>

As you can see, in this scenario, the equipped items take precedence over the outfit you’re wearing. So regardless of the outfit you have on, if you are waving a gun around Earl’s face, he’s going to talk about it. Spans that are both outfits or both equips have equal weight, so you don’t need to worry about what order you put them in.

Beauty in the details

I’ve skimped on some of the finer details of this project and I want to rectify that by adding a new category to this blog: Detail. Here’s a fun detail from the gun element.

When a player picks up a gun, selects it and then hits the action button, the firing method runs. The firing method creates a new bullet object in the projectiles div, which is already styled to look like a bullet. Then the method calculates which direction to fire the bullet and puts all that information into an jQuery animate() call.

The problem initially was the speed. Because the animation was not a fixed distance (always between the player and the edge of the room), bullets took the same amount of time to travel to any edge. I fixed this by making a speed variable that took the distance between the player and the wall as a factor, adding it to the time delay on the animation. The final result is that the bullet seems to travel the same speed no matter where you fire it. FUN!