The state of the mechanics, and how the game functions. Update on developlment.

Billiard Royale

It's Zack Hawkins, and I am the Producer for a game called Billiard Royale. The artist is Riley Carpenter, and the coder is Pedro Dominguez. This game has underwent severe mechanical and technical changes over the course of its development, in addition to (and causing) massive changes in the scope of the project that lead us to build new mechanical systems and game rules out of necessity of time, which I think ironically enough, has lead to a more concise and fun experience than our original intended mechanics with full creative freedom due to having more time.

Billiard Royale is the result of a school project being given to our group, with the guidelines of "simple Mario Party type game with multiple players." The idea for this game was basically, the first idea that came into my head. Control billiard balls that knock each other into pockets, call it Billiard Royale. It's just that simple. 

Our original intended mechanics were this: the players would directly control the rolling of 1-4 pool cues (depending on player count) and would attempt to build up momentum over time and hit other players into the pockets, as well as hitting non-player balls (the stripes/solids on the board, placed in a triangle pattern, that can be "broken" and the billiard balls used against your opponents.) We found several issues with this formula by the time we needed to submit a build of our game with these intended mechanics completed. However, it was not at all in a playable state due to the unpredictableness of mechanics that would seemingly be so simple to implement. The core gameplay "states" of this formula would be as follows:

-The ability to roll around using WASD or the left stick on a controller, using a roller ball character control whose body moves and rolls on a center pivot. This character controller needs collision and needs to be able to transfer that momentum into a "hit" on the opponent that sends them in the other direction instead of just causing both players to be locked in place when they hit each other.
-Characters would simply lock in place when they hit each other. And this was definitely the hardest thing to figure out, as the way we had programmed in their use of movement was through translation + building up momentum over time. But what did work, was the ability to push the static NPC billiard balls based on your momentum, so figuring out how to apply that to a character controller seems more difficult, as they sort of act like "immovable objects" currently.
-Being hit wouldn't matter. The core issue with the gameplay loop that makes it unsatisfying is: even when you somehow manage to hit a ball that has the same movement speed as you and can pivot on a dime, even when you hit them with your built up speed, they can just directionally influence themselves away from the pocket and avoid being sunken, leading to massively long and frustrating games. So this brought up 3 solutions, and we decided to go with a combination of two of them.

The first solution would be that of simply implementing a timer to avoid the game from going on more than 1-2 minutes. I'm not a fan of doing just this one alone, as it wouldn't actually make the gameplay fun, just technically shorter. This is addressing a symptom of the issue but not its source. However, I do think a timer implemented into the final build would be a great idea anyway, as that insurance that the game can't go over 2 minutes is required in a game like this, I think. As its name is "Billiard Royale" that is a play on words of "Battle Royale," and so every battle royale has a way to shorten the length of the game, as players will always play defensively when given only one life.

The second solution would be to create a locked "hitstun" state, where when the player gets detected by the collision of another player after being hit, they "spin out" and lose control of their character controller, which will not allow them to directionally influence themselves away from the pocket, creating a 30-60 frame state of hitstun, depending on how hard the ball hits the other one. I think that if this game were to be made in a year, this would be an absolutely great thing to implement, however, when attempting to do these mechanics as quickly as possible because your group is already behind on having them done, this sort of thing would lead to all sorts of issues that would have to be dealt with other the course of hours. The first that come to mind are: how do you prevent both players from taking hitstun? Should both players take hitstun, is that part of the game? Is that fun? Would there have to be a way to calculate who continues going forward and who takes hitstun, based on velocity? How do we consistently transition back into the state where the player can move again and control their ball, how do we get there every time, what would we look for?

The third solution is rather simple. But before I explain it, I must put an idea in your head. Forget everything I just wrote before in those last two paragraphs, as they are bad ideas. Well, I think they're good ideas, but they're fundamentally bad ideas because they fail to understand the most basic part of Billards itself: the pool cue. The balls move, because they're hit. So take away the player control with the left stick and WASD altogether, and make it so the movement is hitting yourself with a pool cue. A simple button press and aiming your ball in a direction, you go forward. The longer you hold, the more power you have. When two players hit, it simply knocks them both back, like real pool. This is not only the best solution, but the easiest to code in a short amount of time, and we're getting there. We are almost ready to consider the core gameplay loop done!

Another thing I'd like to talk about is the change in how the scoring system would have worked. Before, players would have stocks or lives, or, by knocking out an opponent they'd gain a point. However, when questions arrived of "how would we determine who gets a point," yeah we decided to drop that one. Even if we managed to code a system that determines who touched that player last with their own billiard ball, there'd be the ability to "steal kills" from each other which never feels fair. However, if characters have a LIFE instead of infinite lives + a timer, then players who are against each other may feel more inclined to help each other out and combo with each other to ring out someone with more lives than them. So this incentivizes an even higher, infinitely so, level of gameplay with using the balls together. I think a 2v2 team mode would be great if this game were further developed in the future, and I think that mode should be the primary focus, as there's a lot you can do with that very simple concept. For now though, what we arrived on was simply making it 1 life and last man standing. After all, it is called "Billiard Royale." It'd be very easy to implement 2 lives and create a timer, so we could make some alternate game modes.

Some things that were scrapped were the easiest ones to scrap, the smaller details. In the main menu, I'd have liked it possible to select your billard ball skin, there could be custom painted skins to select for each player, as well as a "Table Select" with different rooms and settings, as well as different felt board colors, however the maps function the same. These simple additional ways to play the game are important to me, however when given so little time, these are unfortunately the things that must be cut, despite being the things I love doing the most.

Either way, Billiard Royale is coming along pretty strongly, it's just a bit behind on schedule.