Waiter Extraordinaire

Play online

Chester Servesalot Waiter Extraordinaire is a game created from scratch over 48 hours.

Help Chester Servesalot deliver drink glasses to all of the customers at the tables.  He is an expert at balancing glasses on his serving tray, but his greatest fear is mice.  Bumping into a mouse will cause him to lose balance and drop all glasses on his tray.  At any time, he can return to the orange glass table on the left side of the room to refill his tray with glasses.

There are three types of mice in the game.

  • Green – Moves back and forth in a straight line
  • Purple – Moves in random directions
  • Orange – Chases Chester Servesalot when he gets close.  Run far enough away and he will stop.


Post Mortem

Chester Servesalot Waiter Extraordinaire was my twenty-fourth game created over a weekend in 48 hours.

The most notable new feature that I tried using for this entry was using the Unity Animator for changing between the player animations (standing and walking).  There were basically just two states and a animation float variable called velocity, which is set on each update from the player using Animator.SetFloat.  The key things to remember are to uncheck Has Exit Time on each transition and add a condition using the velocity variable.  Otherwise, the character will slowly transition from standing to walking, instead of immediately walking when a move button is pressed.  It’s also important to remember to create an Animator Controller by setting the Avatar Definition to Create From This Model on the Rig tab of the model.  The Root node also has to be set to the body bone (root/bone_body) of the model.  It seems like a lot more work, but I definitely needed to get out of the habit of using the Legacy animation for imported Blender models.  I also got in the habit of exporting my Blender models to FBX instead of using the default Unity importer, since it seems to be broken in the latest versions of Unity and Blender.  There was also a sitting animation for the player model, which was just used to pose the customers (which used the same model, but a different texture).

Another feature I used that I didn’t have much experience with is the Character Controller.  It does make moving the player easier than using the standard capsule collider and rigidbody.  However, you have to handle the gravity code yourself.  The collisions are also different, and one major drawback is that there is no OnCollisionEnter type method for a CharacterConroller.  You only get whether it is collided on each frame.  One thing that needs to be reworked is the collision code, because there are some checks that are done on each frame (such as collision with an enemy or table), which should only be done when it is first collided.  Since this was a game jam, I just left the extra checks and assumed that any slowdown would be negligible, but I did notice significant slowdown when I tried playing the game on MacOS and Linux.

I wish I could have spent a little more time on the enemy AI.  There are three different types of mouse enemies (all inherit from one base Enemy class).  The first two (green and purple) mice are fairly easy to avoid.  Looking back, if I had more time I would have like to add navigation points throughout the stage, and have the enemies patrol between those points, similar to the ghosts in Pac-Man.  The third enemy is much more difficult to avoid, since it moves to the player’s position if the player is within a certain range.  I made sure to make the player slightly faster than this enemy, so it is possible to run away to get it to stop chasing the player.  One modification I should have made is to limit how far left this mouse could move, because it shouldn’t be allowed to move all the way to the refill table.  That sometimes ends up in a loop where the player is continuously colliding in both the refill table and mouse, which can generate numerous glasses all at once.  It’s actually pretty cool to watch, but does make the game look buggy.

I played through the game numerous times for testing.  One time I noticed on the third stage the player was not colliding with one of the middle tables, and therefore not able to deliver the glasses making the stage impossible to complete.  That bug really had me stumped, and I haven’t been able to reproduce it again.

Another feature I wanted to add is resizing the room as the level increases.  I basically just modeled a room big enough for all levels.  However, the room should be much smaller for the earlier levels, since there are fewer tables.  I think one way to solve this is by adding divider meshes, similar to how large conference auditoriums are divided into smaller conference rooms at conventions.  That change probably wouldn’t take too long to implement, but at the time my brain felt like mush and didn’t implement it.

I think implementation of the glasses went well.  I will admit that most of the local positions of the glasses on the tray are “hard coded”, but there is probably a nice formula that can lay out objects in a triangle more elegantly.  Delivering the glass instances from the player to the customers worked well.  If the customer had a glass instance assigned, then their “served” boolean value was set to true.  Each table had assigned a random number of customers (2 to 6), and I used some simple trigonometry to space them evenly around the tables.  Adding some randomization for the customer textures would not be hard to implement.  However, I do sort of like the customers looking the same, since the attention should be on the player, not the customers.  I would have also liked to add a different animation once the customer is served a glass (cheering or something like that).

The glasses falling when the player hits a mouse worked as I had envisioned.  The key is to set the Is Kinematic property on the rigidbody for each glass to true, until the collision occurs, then the property is set to false allowing the physics interactions to occur.  I used AddForce and AddTorque with random values to make the glass collision a little more hectic.  My original idea was to make the game test the player’s ability to balance the glasses on the tray, but I thought that would be too difficult and not very fun.

Another “issue” with the game is that the player is always facing towards the camera.  At first I thought it looked awkward, but as I played more I started to like it.  I reminded me of old 1980s arcade games where the character is always looking forward.  I probably could have made the rotation “correct” if I spent some time on it, but I didn’t think it was worth the effort.  Plus, having the player quickly spin with the tray of stacked glasses would seem really unrealistic, even for an action style game.  There is some noticeable clipping between the tray and customers, but I just left it as-is for now.  I could have added capsule colliders for the customers, but that would have made colliding with the table (to serve the glasses) much more difficult.  One solution would be to make the player serve glasses if they collide with the table OR a customer at the table, but that would take more time to implement.

I definitely think there is much more that can be added to this game, especially more than three levels.  However, I try to keep my game jam games to be completed in five minutes or less, since most people will be playing 20+ games.  I know I appreciate games that are quick to start and easy to figure out how to play.  This game could add different configurations of the tables, or make specific deliveries to based on each of the customers.  I forgot to mention earlier that the glass delivery system was based on games like Paperboy (and my 3D “clone” called Delivery Kid).  Serving the tables was somewhat based on games like Diner Dash.  I even thought about having different levels of customers along with a satisfaction meters, similar to the cabaret mini-game in Yakuza Zero.




Play online

Help Mr. Digger dig as far as possible into the earth. Pick up the shovel to start digging. Pick up additional shovels to speed up digging speed. Avoid the enemies as you dig. Get hit three times and the game is over. Enter your name for the online leaderboard.

Press left and right to move. Press space while standing still to dig downward. Hold left or right and press space to dig horizontally.
Press Up to jump.

Enemy types:

  • Green – moves back and forth horizontally
  • Light Blue – moves in random directions
  • Orange – moves in a circle pattern
  • Red – shoots projectiles at you.



Post Mortem

It’s been a while since I’ve written a Ludum Dare post mortem, but I decided to write one this time since it is LD48.  Ludum Dare was originally referred to as LD48, due to it being a game jam to be completed in 48 hours.  After doing so many of these, sometimes the post mortems started sounding like I was saying the same thing over and over again, which is why I haven’t written one in a while.

This is my twenty-third submission to Ludum Dare.  I started back in April 2013 when the theme was Minimalism and I created a game called Amish Brothers.  It was a simple game of collecting sheep, but it was my first ever Unity game.  Learning Unity has opened some doors for me in life.  It was one of those things that I never was taught in school or college, where I just had to pick it up on my own.  For this 48th edition of Ludum Dare, I decided to use Unity again, which is now on version 2020.1.  When I started with Unity, it was version 4.5 and things like GUIText and GUITexture have now been deprecated and no longer exist (I’m really starting to sound like an old-timer now).

So this Ludum Dare’s theme was revealed to be Deeper and deeper.  The classic arcade game Dig-Dug came to mind, and I didn’t have any other ideas.  I decided to make a game in the style of Dig-Dug.  Another inspiration was the digging levels in the USA version of Super Mario Bros 2.

One of the first decisions I had to make was to either use a Projection camera or Orthographic camera.  Projection is nice to really make it look 3D, but Orthographic is good to keep all of the ground units the same size.  I decided to go with Orthographic this time, however some of the 3D shading properties can still be seen.  Otherwise, a player probably wouldn’t be able to tell the difference between a 3D orthographic game and a regular 2D sprite based game.

I think I did a good job implementing the basics of Dig-Dug, with adding my own spin on the game.  I considered my Chicken Little game for Ludum Dare 46 to be successful, based on the number of scores that were submitted to the leaderboard.  Therefore, I decided to make another game that was quick and simple to play, that would yield a varying range of scores based on how deep you dig.  As with the Chicken Little game, I used my custom leaderboard code, which handles submitting the player’s name and score to my website.  It works well, but it allows players to enter any alpha-numeric name and the score is validated based on a hash of the name, score, and key.  If someone has enough time on their hands, then can probably figure out how to break it.  However, I do like giving the player the ability to enter anything (aside from the words in the “bad words” file) for their name, which is like the old arcade and pinball machines.  If the player has to create an account to submit a score, then they probably won’t bother.

The ground blocks are basic Unity GameObjects.  When you press space to dig, it uses a one unit ray to check check if there’s a block below, and removes it if it exists.  I also spawned a particle effect for the dirt being dug.  If the player is holding left or right while pressing the dig button, then the ray will be horizontally left or right instead.  Looking at it now, I probably would not have made a button specially for digging, and just perform the dig function whenever the player presses down, left, or right.

Unlike the arcade Dig-Dug, I had shovel collectibles spread throughout the game.  The first shovel sits on top of the ground, and must be picked up first before digging.  This is sort of a throwback to picking up the wooden sword in the original Legend of Zelda.  Each additional shovel increases the digging speed.  I used the clamp method to set a maximum digging speed (or minimum delay between digs) so that the dig delay never reaches zero.

There are four types of enemies in the game.  Unfortunately, due to lack of time they all look the same, just with different color textures.  I did model everything in Blender, so I could go back and add animations in a future release.  However, the enemies do have different movement patterns, but very simple ones.  One enemy moves horizontally to the left and right.  Another moves in random north/south/east/west directions (similar to the Octorok in the original Legend of Zelda).  Another enemy moves in a circular pattern.  The last enemy is stationary, but shoots projectiles at you.  The enemy speed also increases based on your current depth (they move faster the deeper you go).  This is to ensure that the game doesn’t go on forever.  I used proper object oriented style when making this game, by having one Enemy class, which has the basic attributes of the enemies, then four subclasses for each enemy type that control the different movement patterns and shooting.  This way, I only had to write the collision code once for the enemy.  Another difference from Dig-Dig is that there is no way to attack the enemies, and you can only avoid them.

I decided to allow the player to have three health before ending the game.  I could have made it so that the game is over after one hit, but I liked giving the player a chance to recover after making a mistake.  I also added a grace period (now called I-frames in the speed running community) before they are damaged again.  I simply changed the color of the player’s material to red during the invincible period.  I think not having a dig animation for the player is probably the biggest flaw in the game.

The ground blocks are spawned one group (10 total if I remember correctly) at a time.  Once the player digs near the bottom of that group, another group are spawned, and the camera is moved downward.  The camera also follows the player upwards when jumping.  One fix that should probably be made is to limit how high the player can jump.  However, I do like having the ability to trace your path backwards to the start.  When the game is over, all of the block types are destroyed, the camera is moved back to the start, and the game is reinitialized.

As with most of my games, I used GarageBand for composing the music.  I have a MacBook Pro specifically for composing music, then I transfer the files and generated song file over to my primary development PC using a shared folder.  This process has worked good for me over the years.  This time, I didn’t make any custom sound effects and just used BXFR, which is good for making 8-bit sound effects.

I took two photos outside of my house, which I used for the dirt texture and the rock boundaries.  I modified those images a bit in Gimp, to give them more of a uniform color.

There were a few other things I considered for the game but just didn’t have the time or gumption to implement.  The first idea was lantern powerups.  Underground would be dark, but only a small portion could be seen using a Unity spotlight.  As the player would collect more lanterns, the radius of the spotlight would increase, allowing the player to see more of the area around their character.  I also considered adding gems, which would look pretty, but I didn’t have any other idea for them aside the score.  Since the player’s “score” is how far they have dug downward, I thought adding a gem score would add unneeded complexity.  Maybe if I developed the game further, gems could be used to buy powerups or other things.

I appreciate everyone who has played the game and submitted a score to the leaderboard.  See everyone in October for Ludum Dare 49!