Dream Build Play – A Change in Plans

This is the last few weeks of the Dream Build Play 2017 competition, and I’ve decided to put my action-RPG game Myriad on hold.  The game just has too far to go in order to make it a completed game and respectable entry.

In it’s place, I’ve decided to make Turn Back the Clocks 4 my Dream Build Play entry.  Honestly, I’ve enjoyed playing it more than any of the other games I’ve created.  I started working on the game in early November, so using it does not break any rules of the Dream Build Play competition.  Plus, there’s a story that goes along with the development game, since it was originally created for the 0hGame jam in an hour.

I’ve spent the past few weeks improving the gameplay and graphics.  I feel like there’s just a little more to do to make it a complete game.  I need to fix the way the balls move in the line as they are shot.  Right now, each ball just targets the position to where it needs to move, but that doesn’t work correctly when the balls are shot rapidly.  I would also like to have the score display for each clock hit, in the color corresponding to the ball which hit it.

The game already has leaderboards implemented, so I’ll just need to remove the screen with text entry to use the XBoxLive services.  I still plan on using my own host to store the leaderboard information, so I’ll just pass the user’s gamertag and score to the leaderboard function.

I also need to do some small changes to graphics.  I want to make the board a little lighter, so that the balls stand out better.  Then I will need to make the inactive clocks darker, so that they stand out against the board.

Modifying the controls to work on XBox One shouldn’t be too big of a problem.  I’ll just need to assign button input events to each of the buttons, like I did with my Kitty’s Adventure game.

Turn Back the Clocks 4



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 (龍が如く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.

 

 

Dream Build Play – Enemy Movement and Level Data

I spent about an hour and a half working on my new Unity game for Dream Build Play 2017.  It’s been a few weeks since I last touched it, since I’ve been busy with updating the web site and other game jams.  A few days ago I decided to change the title of the game to Myriad of Legends, which keeps the “My” of Mystic and “Ad” of Adventure.  Then I thought the title was too long and sounds too much like League of Legends, so I decided to change the title to just Myriad, which I think sounds better.  The only problem is that just a one word title will make it harder to find with search engines.

This time I worked on enemy movements.  I made the Enemy Movement a separate script that is assigned to my Enemy prefab.  I really wanted to keep things like movement countdowns separated from the core enemy attributes like health points.  I keep an angle float variable, which holds which way the enemy should be facing, and I update the rotation on every frame using Quaternion.AngleAxis, using the angle and Vector3.up as parameters.  This is to ensure that the enemy keeps facing the same way, since the rotation can be affected by the physics engine.  Alternatively, I suppose I could have locked the Y rotation on the enemy RigidBody.  I have a function called setRandomDirection, which sets the enemy angle to either 0, 90, 180, or 270.  This is done by generating a random integer from 0 to 4 (exclusive), then multiplying by 90.  I have a countdown which calls the setRandomDirection every two seconds.  Also, if the enemy collides with another enemy, I add 180 to the rotation to both enemies so that they don’t continually bump into each other.

I also created a rock object, which is currently just a cube that I texture mapped in Blender.  I populate the rocks in the game world according to a text file.  This is the same process that I used for Ancient Adventrue and some of my other games.  The text file has pound signs (#) to represent the rocks.  I have the text file stored in the Resources folder in my Unity Assets folder.  Then I assign the text file to a TextAsset object in the LevelManager script that I created.  I can access the contents of the TextAsset using the .text property.  Then I use the Split method passing a new line (\n) as a parameter to get each row, and use .ToCharArray to get the character data for each line.  It’s a quick and simple way to design levels.  Later, I may convert this to something like the Tiled TMX format, which would allow me to store more information, but is a little more difficult to parse.  I also added enemies, which are signified by the letter ‘E’.  I set the enemy movement so that 180 is added to the rotation if it collides with a rock.  Occasionally, there is a bug where the enemy will continually rotate, which I believe is caused by the enemy colliding with two rock objects at once.  I need to fix it so that it will only rotate once per frame and per collision.  As I found out with some of my previous games, a collision can occur over multiple frames (Update calls), and it isn’t finished until OnCollisionExit is called.

I still had the problem with the sword collision box continually colliding with the player capsule collider.  To fix this, I just made the sword collision box a trigger, so that it is not affected by physics.  I think I could have put the sword and enemies on a separate physics layer, but that could make things much more complex.  When the enemy gets an OnTriggerEnter event where the colliding object is a Sword, then the enemy is destroyed.  Probably in the next update, I will make it so that it takes away health points, and only destroy the enemy if their health falls below zero.

Finally, I got rid of the huge ground plane, and added a new ground prefab.  It is the same width and depth as as the rock, one unit in both directions.  However, it’s anchor point is on top of the model, instead of on the bottom like the rock.  This way, if I instantiate a rock and ground at the same position, the rock will sit perfectly in line on top of the ground.  The ground is instantiated for all spaces in the text file, and with rock and enemy positions.