Added a new Weapon instance variable to the Player that is the equipped weapon, which is just a pointer to a weapon in the player’s acquired weapon list. The equipped weapon is initially set to null, which means the player does not have a weapon equipped.
When the equipment screen is displayed, a new ResistorKit menu is created which takes the Player’s acquired weapon names as parameters. This is a little wasteful, since memory used for the menu object has to be allocated each time the screen is displayed, so there is some room for optimization later. I’ve also added the damage values as a part of the menu item, so it’s easy to tell how much damage the weapon does for testing. One enhancement I could make is to automatically sort the weapons by damage value.
Equipment screen now allows weapon selection.
I commented out all of my socket code for now, and now the confirm button just sets the player’s equipped weapon to the object in the acquired weapons list at the index of the index of the currently selected menu item. I think it’s safe to say that the menu items and the acquired weapons list will always be in sync, because it is not possible to add or remove weapons from the list on the equipment screen. Ideally, I should make the menu accept a pointer to the acquired weapons list as a parameter, and then have a toString type message display the weapon name and damage. However, I would then lose some of the portability of the ResistorKit libraries, because not all games will have Weapon objects especially not defined the same way as mine.
At the bottom of the screen I now display the equipped weapon in yellow. I’ll probably end up making the equipment display and equipment select screens separate, but for simplicity I will leave both on the same screen for now. I still display the list of armor now with defense value, but defense has not been implemented yet.
Static weapon added since the player starts with no weapon equipped.
Now that the player has a way to equip a weapon, I have to apply that value to the projectile. Thankfully, I already added a damage instance variable to the projectile class. Therefore, I just have to assign the weapon’s damage to the projectile when it is fired. One problem is that the player does not start with any weapons, which means the player is unable to shoot. However, there is a chicken and egg problem here, because enemies don’t drop weapons until they are shot and defeated. Therefore, I programmatically added a weapon drop to the first room so that the player can equip it to defeat enemies. This was easily accomplished by calling the dropItem method when the first room is instantiated, passing the first weapon ID and the x,y coordinates as parameters. In the future I would like to have static items placed by the level editor, which would require the player to open or shoot a treasure chest. Additionally, I also had to add a check on the equipment screen to ensure that the selected weapon is in the bounds of the acquired weapon list, because index 0 in a zero sized list out of bounds and causes a crash.
One more slight glitch to fix. If the player is running and then the Start button is pressed to go to the equipment screen, then they will continue to run after returning to the game even if the directional controls are not pressed.
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.
Tonight I updated the ice gun socket, so it now has three levels of magnitude. Ice +1 will freeze an enemy for 2 seconds, Ice +2 will freeze an enemy for 4 seconds, and Ice +3 will freeze an enemy for 6 seconds. I’m thinking about expanding the types of Ice sockets. I could have a Chill socket that just slows the enemy. Also, I could have a separate Freeze socket which will allow the player to stand on the enemy without being damaged.
The fire gun socket is a new ability I added tonight. The idea behind the fire gun is to apply burn damage over a period of time. In order to do this, I had to scrap the two gun system of shooting ones and zeros. That’s because the burn damage needs to just be a fraction of the actual weapon damage. The damage over time concept does not work with the one and zero gun concept. Overall, I felt that most players wouldn’t understand the binary blasting mechanic, and it was going to be problematic to correlate the binary sequence to decimal numbers in the game. I may end up making the binary blasting concept a bonus mini-game.
The Fire +1 socket will burn the enemy for 5 damage each second for 3 seconds. The Fire +2 socket does the same except for 6 total seconds, and Fire +3 will last for 9 seconds. Currently, if an enemy is burning then it is just shaded red.
I also added Long +1, Long +2, and Long +3 sockets which increase the shot distance. To implement this, I had to add a variable that keeps track of the distance modifier to the projectile Pellet class. The base lifetime for a pellet is 20 frames, and for each increase in Long magnitude, 5 frames are added to the base lifetime value. After I get multi-sockets working, I plan on allowing the Long socket to work with the Ice and Fire sockets. However, I don’t know if I will allow Ice and Fire to be active at the same time.
