Archives: Games

Earlier this month, I participated in the 0h Game Jam. The objective of this game jam is to develop game from 2am to 2am during the daylight savings time change. For the United States east coast, this occurred on November 5, 2017.

I had previously created games for this game jam three other times, in 2013, 2014, and 2016. The first year, I just created a simple grandfather clock simulation, where you could move the clock hands around with the arrow keys. The next year I made a simple game where you click the clocks to turn them back one hour. Last year I made a space shooter, where you use a clock wind-up key to blast the clocks.

This year, I wanted to do something different again. I watched a lot of game shows on television when I was a kid, and one of the things I wanted to be when I got older was a game show host. The game show host thing never happened for me, but I thought this would be a good chance to remake one of those old game show games. One of the game shows that I watched regularly as a kid, was The Price is Right with Bob Barker.

One of my favorite games on the The Price is Right was Plinko. The contestants would guess the price of items, and if they were correct they would win discs to use on the Plinko board. The nice thing about the game was that there was a skill component (guessing the price of items) and a random component. The player would go up a staircase to the top of the big Plinko board, and drop discs one at a time. The board was filled with pegs, so the discs would always take a random path to the bottom. At the bottom of the board there were slots, each containing a different monetary prize. The biggest prize was always the center slot, but it was surrounded by two zero dollar slots. That made the game seem more exciting, because the difference between winning big and winning nothing was so close. I suppose that the position that the player dropped the disc also required skill, but it seems like the ending position based on the drop location was essentially random for the most part. If the player dropped the disc on the far right of the board, it probably would not end up in one of the slots on the far left. However, dropping the disc in center could definitely result in it landing in the far left or far right sides of the board.

I’ve been thinking about what makes games fun lately. I’ve come to the conclusion that there are two components to making a game fun. The first is the skill component. The player has to feel like they are contributing to the success or failure of the outcome. However, purely skill games feel boring, repetitive, or like they are a test or quiz. Therefore, there has two be a randomness component. Getting the balance between skill and randomness is the key to making a game fun. If the game is purely random, the player doesn’t feel engaged, because their contribution to the game does not impact the outcome. Roulette or “the big wheel” on The Price is Right are examples of games that are essentially completely random (although some could argue that the amount of force applied to the wheel could affect the outcome). Roulette isn’t a horrible game, but it’s not something that I would want to sit and play hours on end. I played through Yakuza 0 (龍が如く０) earlier this year, and the roulette game was one of the most monotonous minigames included. However, the hostess club game was one of the most exciting because it had random components (the types of people entering the club and their requests) and a skill component (matching the correct girls to the customers and fulfilling the requests).

With my newest Turn Back the Clocks game, I tried to recreate the Plinko game. It also includes mechanics similar to Peggle, in that the objective is to activate all of the pegs on the game board. The amount of skill required is minimal, as you only have the ability to control the horizontal position of where you shoot the ball. The ball takes a random path toward the bottom, enabling the pegs along the way. As a peg is enabled, I change the material of the peg from the red “off” material to the green “on” material. Also after a peg is hit, I have a function which loops through all of the pegs to determine if they are all enabled, which then transitions to the win state. As a ball is used, a counter of the total number of balls used is incremented as a way to keep score. Another component to making a fun game is having a way to determine if you are getting better at the game.

I decided to use Unity again, but this time I did not use Playmaker. The installation of Playmaker alone can take about 10 minutes, which are very valuable for a one hour game jam. My opinion of Playmaker these days is that it makes the easy things easier and the hard things harder. If I want to make an object spin, I can easily do that with Playmaker in a matter of seconds. Doing the same in code will take at least a couple of minutes to create a new script, assigning the script to the object, and then writing the few lines of code to make the object rotate. You also end up with a big mess of scripts for doing relatively simple tasks. On the other hand, trying to access other game objects, apply a complex trigonometry function, get a variable from another component script can be a nightmare in playmaker. A one line mathematical function in code can take minutes of adding Action boxes to your state, and you’ve got to get the ordering of the Action boxes correct or things will go wrong. Plus, accessing script variables in code is so much easier than having to define variables in Playmaker, especially when trying to access to variables from other game objects. Playmaker does provide a way to call a script (using the Call Method action and dragging in the script component), but trying to access Playmaker variables in other FSMs in other game objects in code can be quite messy.

Since my one hour game was quite plain, I decided to update it this weekend. I improved the physics, graphics, and music.

First of all, I made the ball object and collider half the size, because it kept getting stuck between the pegs. This actually reminded me of the old Plinko game when the disc would get stuck, and Bob Barker would have to get the hidden cane to push it loose. I’m not sure why he couldn’t just tap it with his hand, but I guess using a cane made it seem more legitimate. From what I remember, when a disc was stuck on Plinko, it was delivered back to the contestant and they got a do-over. The balls in my game still felt a little flat after changing the size. I changed the mass in the RigidBody of the ball, but it didn’t make too much difference. Then I learned that I need to create a Physics Material, which can be assigned to the ball’s Sphere Collider. In the Physics Material, the amount of bounciness can be changed. I also added a board around the pegs, so that the balls would not leave the game area. This worked really well, although the cannon which shoots the ball could still leave the game area. To fix this, I added a RigidBody to the cannon and freezed the position on all axes except for x, and froze the rotation on all axes. This worked well, but the balls could push the cannon when they collided with it, but setting the mass of the cannon to something large (I used 200) fixed that problem, and now the cannon is not able to exit the board area when it collides with the sides of the board. The board is a mesh that I created in Blender, which uses a Mesh Collider, without a RigidBody. I turned on Continuous Collision Detection for the ball prefab, which did seem to help prevent the balls from going through the walls of the board. Another problem with the original version was that if the ball hit exactly to top of a peg, it would not roll which makes sense. Therefore, when the ball is instantiated I add a random torque force to the RigidBody in the range of -500f to 500f. It seems like after a certain point, apply more torque really doesn’t have much of an effect, but having at least some torque makes it more random and keeps the ball from getting stuck.

I created and texture mapped a cylinder object in Blender to make a clock, which are the pegs. I created two texture images in Gimp. One texture is red and set to 2am (the non-activated peg) and a green texture set to 1am (the activated peg). The activated texture is assigned as a public Material in the clock script, so when the peg is activated I just get the clock mesh object and seting the material property of GetComponent<Renderer>(). I made an additional texture using a publicly available image of clock gear for the background of the game board. The texture was duplicated, and a normal map was generated with the new texture using the internal Unity normal map generator. Usually, this makes the image look better, especially when it interacts with light objects. Another addition I made was a light prefab, when flashes green for half a second and then destroys itself. It is important to only let the light live for a short period of time, because having two many lights can severely impact performance, or even worse Unity may stop rendering point lights if there are too many which looks bad.

In the background I created a half sphere object using the same clock gears texture, but with a different hue. I created a function in my LevelManager class which calculates the player’s progress through the game, by diving the number of active pegs by the total number of pegs. I multiply this zero to one value by a speed factor, and apply that as the rotation of the background. This gives the appearance of the background spinning slowly at the start of the game, and it gradually speeds up as the pegs are enabled.

The original one hour version of the game did not have any music. I liked the theme that I created for my last Turn Back the Clocks game, so I checked out the GarageBand project files for that game from my code repository. I loaded it into GarageBand on my MacBook Pro, and I change the instruments but kept the melody. I also changed the key from C to G. That makes the song sound new and fresh, without having to create new melodies.

There are a few other things that I would like to add to the game. It would not be too difficult to make it take advantage of my leaderboard API. I could have it submit the number of balls used after the player wins. I could also have the game keep track of time elapsed, and use that as another score metric. I could also make different configurations of pegs, so that the player has to complete each level, which would dramatically extend the gameplay lifetime. There could also be pegs with different properties, like exploding pegs. Objects could also be added to the game board to make it more difficult to reach certain pegs. The ball and cannon objects could use new models as well. I was thinking about having a semi-transparent ball with an hourglass inside. I don’t have any ideas for the cannon, but I could reuse the key mesh from my previous clock game.

 

Released November 19, 2017November 19, 2017