More Villains: part 4 - Cymbal Monkey

As an homage to our first game, Alpha Chimp, it was important for us to call back to that game in some way. The most clear way that we were able to do this is (while maintaining a unity of the whole) was to include a cymbal-banging monkey.

To be sure, I am not so certain that this character is necessarily a Christmas themed toy, but it is a toy, nonetheless. I think that there is something terrifyingly real about toys coming to life, and attacking. I imagine that all children might dream of what their toys are doing in the middle of night, while everyone sleeps. (I'm sure that there have even been movies exploring this theme, but none seem to have been memorable enough for me to recall on the spot.) More than the snowman, the rocking horse, or the teddy bear, I have the feeling that all cymbal monkeys have a certain quality that makes them inherently scary, even when they haven't become evil, as the toys have done in The Elf Who Killed Christmas. Therefore, I didn't want the design of the character to be especially scary, since the toy seems scary enough, as it is!

One note must be made regarding the animation. One problem that had to be solved is how the character would move. Most of the real toys simply sit and bang away. Making him walk seemed awkward, so we decided that he would jump in order to move. With each jump, and each slam of the cymbals, the player would hears is sure of the doom that approaches!

Visit the game's website, and download the demo!
http://elfwhokilledchristmas.com/
http://giveupgames.com/

More Villains: part 3 - Rocking Horse

While this game was basically completed in the last few months, the idea and first concepts and initial prototypes for this game were first developed in 2010. However, the concept and plans for the game were shelved for a long time... until 2013, when we really decided to produce the game. Only a handful of those prototypes survived into the final 2014 version of this game, as we started from scratch. One such survivor from 2010 is the rocking horse.

One very attractive feature (from the developer's standpoint) of the rocking horse is its simple animation: it rocks back and forth! That means that we didn't need to develop a walk animation, or a much else. It rocks, moves, and falls. There is only one dynamic bone (or joint) that controls the animation. This compares to 17 such bones in the typical character in The Elf Who Kills Christmas. Despite the fact that I actually do like this character, it was almost necessary for us to use it in the game for no other reason than because it was so easy to animate.

Visit the game's website, and download the demo!
http://elfwhokilledchristmas.com/
http://giveupgames.com/

More Villains: part 2 - Teddy Bear

Among the other enemy characters in the game, knowing the course that the game would follow, we knew that we wanted to include toys as enemies. (Perhaps an influence for this idea might have been Tim Burton's A Nightmare Before Christmas.) One character that makes this idea concrete is the Teddy Bear.

Again, going with the villain nature of the character, he would need sharp teeth, claws, and mean eyes; it doesn't hurt that his sweater has Freddy Kruger colors.

That said, I really love the design of this character because of the material flaws all over the character. That is, his ear is ripped, and the player can see the stuffing coming out, as well as on the lower left side of the head. This is also coupled with the rips in the sweater, under which you can see the outer fur of the teddy bear. Obviously, the most conspicuous material flaw is his left button eye that is falling off, barely holding on by the stitching. I think that all these features actually lend a sympathetic nature to this character, which for me, is important in all villains. I admit that all the characters in this game don't always elicit the most sympathy, but it is a goal, one that is best reached in this character.

Visit the game's website, and download the demo!
http://elfwhokilledchristmas.com/
http://giveupgames.com/

More Villains: part 1 - Snowman

Since the game is called The Elf Who Killed Christmas (here), it made the most sense to begin this development blog talking about elves (you can review those here). However, there are several more villains in the game beyond elves. In fact, the first enemy that is encountered in the game is a snowman.

We figured that since this was a Christmas game, there must be a snowman! It is easy to recall, when we were children, all the silly stop-motion animated films that would play on television during the Christmas season. Among those shows, the Frosty the Snowman stands out in my memory. As can be seen, we clearly did not go in the direction of that film, but we knew that, being a villain in the game, we would have to get a design that sold the character as a villain. 

In this detail, you can see it was important for us to get the sharp teeth, the crooked nose, and bow-knotted tree limbs as arms. We thought that these were all important features to include for a scary character. However, some of the more classic elements of the character that we included are the top-hat, and the scarf. One limitation regarding the scarf, though, was that if we kept it hanging down, long, then it would be that much more difficult to animate. So a hanging scarf was cut out altogether. I faced a similar problem with the pieces of coal that might have represented coat buttons going down his torso. Even though these elements do go missing, I think that I prefer this pared down design a bit more, and it fits into the game quite nicely. 

Visit the game's website, and download the demo!
http://elfwhokilledchristmas.com/
http://giveupgames.com/

Video Game Self-Publishing

Publishing is always a challenge for indie videogame developers. Ultimately, the problem here is how to get the game that we worked so hard to make into the hands and screens of players out there.

On our first game, the solution was known from the beginning. We published "Alpha Chimp" (here) on Xbox360's indie marketplace. However, even though we knew this was the publishing avenue, there were still challenges that posed a barrier to entry. (Just one of these barriers was that we had to be approved by the community group of developers, that is, our competitors.) I won't get into too any more of the problems that marketplace publishing option posed, but there were many, and we knew this would not be an avenue to pursue with The Elf Who Killed Christmas.

There were a diverse group of choices that we could have pursued in publishing. One is that we could try to find other marketplaces similar to the Xbox marketplace. Well, that would just bring the same sort of barriers as before.

Another option might be to self-publish. The problem with this solution is that we would then have to develop the infrastructure to make our game available on our own website. Such necessary infrastructure would be securing internet bandwidth, as well as developing an e-commerce site. Another significant challenge with this is how we would might get random internet traffic to our site.

As a college professor, I often tell students that whenever they are offered a choice between two alternatives, then best solution is probably a combination of both alternatives. And so this was the avenue we pursued in publishing our game because it offered the best of both worlds.

AMAZON.COM just began offering a service such that independent developers could utilize their infrastructure and marketplace to sell their products. After exploring other self-publishing marketplaces (that fell through for various reasons), the AMAZON.COM solution was the one that best suited our needs.

We were able to make a FREE DEMO VERSION (here) of  "The Elf Who Killed Christmas" available in January. Now that the game is complete, the FULL VERSION (here) of the game is also available on Amazon for less than a buck!

Visit the game's website, and download the demo!
http://elfwhokilledchristmas.com/
http://giveupgames.com/

Mountain Level Design: part 3

Here are bird's eye views of the whole level.

As a whole, you can see how we implemented the ideas expressed in the previous descriptions of our plans for the level design. After entering the level from the island-like area, the spiral and curving-back theme is clear.

At first, I thought that it would be easy to implement the level as a whole, like it is presented above. However, as I described before, this presented problems by forcing the system to render the whole level, even when all that work is not necessary for the computer to perform.

Therefore, we had to optimize the level, and how it would be presented to the system.

These are just some of the examples of how the level was broken up, and delivered to the engine in chunks that were easier to process and process. This greatly optimized the stresses on the system, and increased the performance of the game in measurable ways. By giving the engine different blocks that made up the level, it would then be able to turn off certain parts of the level when it was not in view. The best examples of this can be seen in the top two images, when the player enters the upper sections of the level, which we called the Igloo Village. The player would not have been able to see further behind him since the ice-block walls were too high to see beyond. 

Visit the game's website, and download the demo!
http://elfwhokilledchristmas.com/
http://giveupgames.com/

Mountain Level Design: part 2

Besides giant snow boulders rolling down the mountain, there were other key ideas we wanted expressed in this first level. One such level feature that we wanted to include in this first level is a large field of vision. What that meant to us is that we wanted the player to see features of the level that he would run across in the future, as well as looking back to see where he has come from. What this means for level design is that instead of a fairly straight, linear path that that the player would traverse, we instead designed a path that would spiral, and/ or swerve and curve back over itself.

In the image above, the player could see clearly where he is now, and the immediate setting. It happens that this is a plane area, with reindeer pens in the back, and a large rock wall framing the area. However, while the player is looking just above the brown rock wall, he can see that second level, where he will be running as soon as he finishes off these enemies before him. We realize that the player might not yet realize that he will be running up there, but he will notice it soon. One thing that he might see now is the giant snowball boulder that is falling. We hope this will make him excited to see what is coming, and where that boulder is falling.

This screenshot above is seen by the player in the first moments of the game experience. Right away he can see that he is going to have to go through a cave, and perhaps he can make sense that he will be running up that slope in the near future. He is helped to this conclusion by seeing that there is a fence that lines the slope. Or maybe the player doesn't come to that conclusion regarding the slope. He will know soon enough.

Indeed, a few moments later, after killing this onslaught of enemies, and rounding the corner, and dodging that giant snowball, the player will find himself on the mezzanine of that reindeer pen area, and the player is able to look down upon the place he was previously. There are several places in this first level where this feature of the level design is manifest.

Above, the player is looking down that slope that he might have noticed at the beginning. He can look all the way back to the point where he began the game.

However, as game development was wrapping up and coming to a close, it became clear that such level design might have actually worked to our detriment. That is because the resolution of the assets in the level were high for our system. The best solution is to be able to turn off such assets when they are not in view. However, this is not a viable solution if we want to maintain this large field of vision. That is to say that if we want the player to look over a cliff to see places where he already passed, then we can't turn off those previous places!

Well, it so happened that the level design was such that, in fact, there were places to travel where the player could not see earlier places in the level. Therefore, we were able to exercise the best solution, and turn off certain parts of the level (just not to the degree that we wanted to.)

(Perhaps the reason there are so many games that have levels where the player travels from room to room is so that the engine can turn off all the other rooms that are not in the field of vision. We would explore this sort of level design in other levels (primarily the factory/ prison level, and the palace level). Further, now we know that our level design in future games will try to optimize the field of vision so that we can turn off elements that are not currently in view, and thus, that don't have to be rendered.)

Above is an example in this first level where we wanted a bit of a break in the feel of the level. This break is clearly demarcated by laying out fences that divide the previous parts of the level (the reindeer pens, and then up the slope) to this new portion of the level, the Igloo Village. The player can already see that there will be igloos here, and that the main borders of the path will be icy blocks instead of rocks, or the sides of mountain.

Of course, just because this is a new section of the level, it does not mean that we wanted to abandon our original ideal of seeing parts of the level that are coming up. In the screenshot above, while fighting through the igloo village, the player can see the mouth of the cave that is coming up, that might just be around the bend.

... and so, the player arrives at the entrance to the cave. Again, we wanted to clearly illustrate that the player would be entering a new section of the level, and so there is a fence that welcomes (or not) the player to what is coming next, the cave, which is the first part of the game where the player is completely surrounded, and does not have a large field of vision. This is where the player faces the boss, and finishes the level.

Visit the game's website, and download the demo!
http://elfwhokilledchristmas.com/
http://giveupgames.com/

Mountain Level Design: part 1

Somehow, early in the development of "The Elf Who Killed Christmas," we decided that we wanted the protagonist to begin in a mountain level, where the hero would shoot his way up the before getting the level boss, then onto the next level.

Mike was very clear that he wanted certain game mechanics in this game to be introduced in the first level. Earlier versions of the game included slippery ice, deep chasms to jump over, and large snowballs to dodge. As games develop, lots of things change.

It so happens that the one such environmental element that survived to the final version of the first level of "The Elf Who Killed Christmas" was the giant snowball. If this hits the player, the player dies. However, the snowball could be dodged, and even be shot out of the way.

With certain goals (like environmental elements, and the mountain setting) in mind, this helped us solve the problem of level design. In the case of this first mountain level with giant snowball boulders, this meant that we were designing a level with ramps for the player to hike up, and for the ball to roll down.

Visit the game's website, and download the demo!
http://elfwhokilledchristmas.com/
http://giveupgames.com/