Scripting on Pit Boss: Reaching MVP

Welcome back to the Pit Boss scripting dev log! We are approaching the second playtest and I'm working diligently to get all essential functionality in ASAP. We've run into a few speedbumps and have to cut down the scope of the project a bit, but are still excited to see the final product.

Character Controller

For the first playtest, a simple character controller was implemented to get a feel for how movement should work in Pit Boss. The implementation had a number of shortcomings from using simple Lerp movement, including: wall clipping, NPC climbing, difficulties on staircases, catapulting on corners, etc. To resolve these issues as quickly as possible, I decided to move the controller to a rigidbody force framework. This smoothed out the movement a lot, but currently has 3 major bugs to work out: he player will still climb NPC models on collision, my current speed limiter prevents the player from falling at a reasonable speed, and we are unable to climb steep ramps now. The latter 2 can be resolved by creating a ground-check system that disable gravity on ground and ramp it up in air, but I am still unsure what is causing the playing to climb NPCs on contact. This requires further testing.

NPCs and AI

The NPCs movement has been (more or less) fully implemented, and not just needs to initiate the casino games to start playing and place the customer on a seat when they enter. Most of this code is in place but there have been a number of design flaws that had to be corrected to get to the current state. From the first playtest, we found we could not consistently identify customer NPCs properly in our "mark" command. This was due to improper data structure usage in placing them in an array rather than using a list. Lists provided a lot of functionality we needed for searching efficiently for specific NPCs, and resolved a lot of these calling issues. I also needed to change the classes made for both the NPCs and casino games in order to properly implement multithreading, having not known that I would be unable to pass in strings to the IJobParallel system. Once the game functionality is implemented, the last addition should just be adding in sound and animation triggers to various actions in the NPC ecosystem (win, lose, cheat, etc).

Things to Add

With a short, week-long time budget, there are still a few more key functions we need to implement to reach full functionality. The first is a method of interacting with customers in a positive or negative way. I believe the easiest way to do this will be to have the interact button provide a positive signal to customers (giving a happiness/money boost at cost of casino money) and the mark button asking a customer to leave the casino (reward if it is a cheater, punishment if not). There is also the need for both an elevator and security camera room, both of which will need an interaction command to initiate, but other than the should be fairly straightforward.

What it Should Look Like for Playtest

The current goal for next week is to have players load into the casino and be prompted with goal to catch cheaters in order to keep the casino happy. The game will last 5 minutes, and difficulty will increase over time as more customer enter the casino (getting easier if players fail to keep customer happiness up as customers will leave). They will be able to move easily throughout the environment, and survey the establishment from the surveillance room. At the end of the 5 minutes, they will see the number of cheaters caught vs missed, profit for the night, and average customer happiness.

In Nuce

There is a lot of work to be done before next week, but I am confident scripting will be where it need to be for the playtest. Largely my ability to reach this deadline is reliant on receiving the proper assets for each of the above systems, but regardless there should be functional code behind each of the above systems. Until next time!