Introducing Larry the Zombie

Well, now that the levels are coming together, it’s time to introduce the epic main character of our game, Larry the Zombie!

Larry is just getting a little discouraged because there’s just no zombies allowed with the humans. Those humans are just so mean. All Larry wants to do is hang out, and be one of the guys. You know, and maybe nibble a brain here or there. No biggie!

The actual narrative for Larry to go after these people is really pretty fluid, depending on if we want to go the more “serious” zombie route of Larry just trying to get to the juicy brains of the people inside, or perhaps he’s just a party-going zombie who just wants to hang out a little, but people don’t much like having him around.

Maybe he needs to take a shower.

In other updates, the rope-pulling and success/failure coding is coming together quite well as George and Anurag put their code together, and we’ve got templates in place ready for Jeff’s backgrounds, to be swapped out as soon as he gets back. Things are looking good, and we should be right on schedule for next week.


Working Environment

Alright! After that brief meeting with the Executive Producers, things are starting to take shape. This is the basic background for the first level, which will teach the basic mechanics of the game. This first level will not implement pulleys at all, but instead will teach the simple mechanic of choosing a place to pull, and the consequences of choosing incorrectly.

(Even though the pulley selection interface is working completely, and for the purposes of presentation, we inserted the pulleys to show how that would be done.)

The three selectable areas will be the concrete wall (which will pull the zombie’s arms off), the light (which will pull off and break), and the gate (not pictured, but the correct answer).

We’ll show the humans hiding in the background, and make the zombies look all silly, and add in some blood. Awesome.

Jeff is working heavily on the backgrounds, looking to implement sprites as stand-ins for the prototypes. Hopefully, the humor juxtaposed from the “cartoony” zombies placed on the serious background will shine through. (I’m excited for it.)

George has implemented the drawing mechanic, and is currently working on disallowing the player from crossing the rope for the purposes of our prototype.

In that same vein, Anurag is hard at work grappling with the physics of the game, making sure that the formula holds true, as well as implementing his solution to the collision mechanic.

What he’s illustrated to me, is a plan to make the rope adhere to the pulleys after the path is drawn, which will force the player to plan out the rope in one line, but at the same time that’s helpful because if the player is just guessing, the pulley path will not work, and the zombie will die in some way. It may be best to show this in pictures.

THIS:

WILL TURN INTO THIS:

All in all, things are looking good. We may be scaling back from the original five levels down to just three, but with the extra week of time that “Fall Break” offers, we may actually have a little more time than we’re anticipating, which could help out significantly. We’ll see where we’re at on Wednesday, and adjust accordingly.


Buttons!

Things are coming along nicely, but unfortunately, the images are a little “too” prototype, so I’ve decided to throw up some buttons to show some progress. The basic interface (that George is working furiously on) will utilize a “item basket” approach, as well as a interface similar to drawing with the Photoshop Brush tool that will “stick” to the pulleys automatically. (Anurag’s code is looking good, so hopefully we’ll be looking at a working environment next week.


Paper Planning Platform

In lieu of using an EXCEL burndown system, Karratti has decided to implement a simple system of writing down tasks, and taking the ones that the developer is working on.

It’s simple, and will be added on to as time goes on, but for now, it’s looking to do the job. Pictures of progression will be posted for reference throughout the creation of the game.

If required by upper management, however, another system can also be implemented in parallel to this one, if desired.


Paper Prototype

Today we met together and planned out the five levels that we’d like to put together for our prototype. We’re looking to build a simple level “platform” in XNA, with the physics in use. While this will likely add to the initial set-up time, the hope is that as soon as we have the platform ready, we’ll be able to quickly implement new levels in a “rapid-fire” fashion.

To plan out our levels, we used the paper prototype that we created (using tacks, a tackboard, and a string) to simulate the puzzles that we’d like to use to teach the player the basic mechanics of the game. After due discussion and deliberation, these five levels are as follows:

1) PULLING MECHANICS – This level will focus simply on showing the player what will happen when she attaches the rope from the ZOMBIE to an object to be pulled. We’ll provide two attachments points, one on a movable gate, and one on a brick wall. Should the player choose the gate, and then press “Pull,” the Zombie will open the gate and be able to get to the people inside. Should the player choose the brick wall, however, the Zombie will pull, and rip his arms off, thus teaching the mechanic and showing the “consequence” for an incorrect choice.

2) REDIRECTING FORCE – Using a single pulley, the player will learn to re-route the rope so that he can pull in the correct direction. The idea here is for the humans to be huddling inside of a treehouse, and for the player to attach a pulley below it to pull the floor out from under them.

3) BASIC PULLEY SYSTEM – This level will be the first to introduce the mechanic of cutting the weight in half by utilizing a two-pulley system. The idea was to use a tree and a house, and to attach a moveable pulley on the house to create the system, which we simulated with our paper prototype. The Zombie will pull the roof off of the house, the walls will fall down, and the humans will flee.

4) MULTI-PULLEY SYSTEM – The goal for this level is to introduce the player to the concept of “the more pulleys, the less weight, but the more rope you’ll need.” Level 4 will introduce hazards behind the Zombie, which the player will have to take into consideration. This will add a new wrinkle into the puzzles, in that if the player’s pulley system is too complicated for the task at hand, her Zombie will be able to easily lift it, but the Zombie may fall off a cliff. (Other ideas included getting hit by a truck, landing in a fire, or other silly death animations.) The maxim here is basically “Give them enough rope to hang themselves with.”

5) COUNTER BALANCE – Teaching the mechanics of how elevators work, the goal here is to create a puzzle where the player will have to create a counter-balance. This will help to incorporate all of the skills that the player has learned so far, and will act as the “Final Level” of our prototype. Details will be forthcoming as we go forward.

All in all, we’re looking good and on-track.


Meeting With Mark Howell – Pulley Lab

On Friday, we met with Mark Howell, our client representative, who has been very receptive to helping us out on this project. Team ZWP stopped by at noon to take a look at the “Pulley Lab” that the Mechanical Engineering department uses to help their students to understand how pulleys work, as well as the processes and math involved with trying to make everything work.

Mark looped together the pre-built frame, and showed us some pulley possibilities, explaining how when a pulley is used, there are several kinds, and each will contribute to the weight distribution differently. He gave us a number of limiters and notes which we might be able to use, which I’ll list below:

  • With Pulleys, Weight = Force x distance, which means that essentially, every two pulleys will mean twice as much rope being pulled, but half the force would need to be exerted.
  • Also, we learned about the “horizontal rule,” in that when utilizing working pulleys, draw a line across the pulley system , and however many lines you cross, that’s how much easier the work is. (For example, crossing 3 lines would mean 1/3 of the weight to work ratio.)
  • Crossing ropes could cause a rope to break, forcing the player to really think about where her ropes are being placed.
  • Ropes themselves do have a tensile strength limit, and so an extremely heavy load would require a pulley system that could distribute the weight evenly across the different sections of the rope.
  • Pulley diameter doesn’t really matter, other than a theoretical inertial concern in getting the pulleys started and stopped. Because the rope is travelling the same distance regardless of how large the “wheel” itself is, any differences in the sizes are relatively negligible.

For testing the force needed to lift a weight using the small pulley structure, (featured here, in red), Mark used a basic fishing scale to see how much weight was actually being lifted. This seemed like a very useful tool, and perhaps should be implemented into the game to help students to understand the math a little better in a less dialog box-heavy way.

The meeting was very productive, and really gave us some good working ideas for the upcoming projects. For Monday, we’re looking for a workable environment from Anurag and George, some viable concept designs from Jeff, and a paper prototype of the system from Karratti.

Finally, we looked at some extremely complicated pulley systems, and talked about how those ideas might come into play as advanced levels for the game. These ideas included using multiple moving pulley systems, two zombies pulling on different ropes at the same time, so having to equalize the weight, or even equalizing the tension on the rope by using specific pulley systems to redistribute the strength. All in all, the ideas for basic mechanics adding onto one another make me think that this idea is turning out better and better.

 


Discussion and Presentation

After meeting with the representatives from the Mechanical Engineering department, we took time to discuss around what kind of game that we’d like to make. There was a lively discussion as we first thought up as Jeff thought of a cannon game that involved throwing mechanics in defeating a moving mechanical robot trying to destroy a city. We also started talking about a second idea involving friction and a train, and we even discussed this idea at length, but ultimately decided against it.

The final idea that was chosen was a pulley game involving zombies trying to open a cage filled with human victims. The player would have to set up a working pulley system in order to make sure that the (brainless) zombies could pull on the rope and open the cage without ripping off their arms, or pulling it too far and falling off a cliff.

With that basic premise, we began working on the presentation. George and Anurag both went to work looking into the viability of how to utilize XNA to get it to do what we’d like, and Jeff went to work bringing us an excellent concept sketch for use during the presentation.

The actual presentation itself went very well, and we received a very warm response to our concept. Both the client and the audience seemed quite pleased with the idea, possessing both a simple and well-defined physics concept as well as a visceral element of humorous violence.

All in all, we’re on track and the pitch seemed like quite the success.


Follow

Get every new post delivered to your Inbox.