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>


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!

Doesn’t seem like much, but a lot has changed

I finally re-organized the start game methods so I could add a title screen. Right now it’s pretty plain but eventually Tim will make some awesome title-screen art for it. Speaking of Tim …

He sent me this AWESOME concept sprite of Hipster Dad. I can’t wait to put it in the game.

So in adding a title screen I got rid of all the surrounding text boxes and put that information in various menu options. I also programmed in custom controls, which are still kind of buggy if you click away and click back, or if you try to set a key twice, but pretty awesome.

The gun shoots! Next I need to make it do damage. I’m not sure if I’m going to have to write another set of collision detection code, but I think I will and that makes me sad.

Next I want to add achievements, because honestly, those are awesome. Achievements bring up the point of save data, which I don’t want to think about yet. I’ll have to figure out how to make a cookie and store it in there I guess.

Health, Gun, Re-Organziation

I added Room a variable for money, health and added a fire that you take damage from if you run into it. I think I’ve thoroughly settled on an 8-bit theme for the game since all the sprites I make/steal are in that style. I also added a gun item, but it doesn’t shoot yet.

I changed the way the player sprite works, and to illustrate, here it is:

So the four images are your up/down/left/right then below that are all the different “sprites” a player can have. Those are the items you can equip that change your sprite. Then the next column is all the same sprites, but in a different outfit. The objects shouldn’t be inverted, but it’s just for demonstration purposes. Tim says he’ll have a concept for the player sprite to me soon.

I also changed the return results from the collision detection to include type-specific elements and positions. So instead of just .pos returning the position of an element you’re in front of, it gets that element’s type (mobile, exit, container, etc.) and sets .mobilePos instead. That accounts for your needing to get data about two elements you’re interacting with at once.

Tomorrow I have a long train ride and I’m going to try to get the gun shooting.

Inventory and rooms complete

You can officially move from room to room now. It took forever to implement because I realized that not only does the door element have to store the information for the next room, but it has to sync up with whatever door you’ll be coming out of in the next room. Doors now have ids, titles and classes to account for all this. Here’s a comment I made to myself when writing the door code:

Rules for creating new rooms/doors: you must have the following classes: exit, roomX, and door-XX. The roomX is the room number the door leads to, and the door-XX corresponds with the connecting door in the next or previous room.

Inventory is also done. When an element you interact with has a class of “mobile”, it grabs the element from the room and puts it in the first empty inventory li and strips the positioning information. Then it sizes it down and centers it. I might have to change the sizing code since if the object’s width and height are bigger than they should be it will only account for one dimension. I don’t think I’ll have an objects that will be that big though.

A lot of changes …

I haven’t updated this blog in a while but I’ve added a bunch of stuff:

  • Added rooms and the ability to (potentially) move in between them. Still have to work on this.
  • Re-organized a lot of the player and element initialization code so it was out of the way.
  • Made the room look more top-down by adding a inset border around the room.
  • Added element properties to return a message when interacted with.
  • Added a “Data” box to display messages and information to the player.
  • Designed an inventory system. I’ll be doing that today.

Art on its way

I just spoke with my friend Tim Giusti, who says he’d love to do art for this project. I told him to come up with a concept for a “Hipster Dad.” I’m finding it hard to add more elements to the game without proper sprites, so I’m just adding the things I have. The game now has 4 bookshelves.