You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now our players have more motivation to control the guests near the end of the game (when they're hungry) than near the start of the game (when they're not). However one alternate gameplay mode which has been proposed is to have the players door start locked, and the guests to complete a number of objectives to unlock it, after which they're at risk of losing.
This would come with a different introduction. The service kitchen has been placed into lockdown, but this can be overriden from locations around the hotel: the plant room, the office, a terminal in the library, etc.
The players' door would have a number of lights (eg: 5) above it indicating the level of lock-down. We have a heartbeat that checks to see if guests are in one of the goal locations, and if so the number of lights goes down by one, and that location is crossed off the objectives list.
This provides a constant pressure on the players to keep the guests out of certain areas. This becomes harder as more guests are moving, and combined with door decay (#29) keeping a specific room locked down becomes increasingly challenging.
From a coding standpoint, much of this is easy to add. We already have heartbeats with the plant room lockout. Guests already have goal lists they execute, and which change with hunger. We're probably just adding a boolean to each room (is it a current goal) which gets cleared when it's completed. We can even have events which add rooms as goals, so players have to concentrate on more areas over time.
The lights above the door simply require a driver of some sort and some code to display the number of locks remaining.
It would be nice if current goals on the map were indicated visually somehow, perhaps by having an LED breathing by adjusting its PWM values over time. We'd need to test this with the current event loop to see if it looks good or if there's noticeable lag during heavy CPU usage (eg: pathfinding).
The text was updated successfully, but these errors were encountered:
Right now our players have more motivation to control the guests near the end of the game (when they're hungry) than near the start of the game (when they're not). However one alternate gameplay mode which has been proposed is to have the players door start locked, and the guests to complete a number of objectives to unlock it, after which they're at risk of losing.
This would come with a different introduction. The service kitchen has been placed into lockdown, but this can be overriden from locations around the hotel: the plant room, the office, a terminal in the library, etc.
The players' door would have a number of lights (eg: 5) above it indicating the level of lock-down. We have a heartbeat that checks to see if guests are in one of the goal locations, and if so the number of lights goes down by one, and that location is crossed off the objectives list.
This provides a constant pressure on the players to keep the guests out of certain areas. This becomes harder as more guests are moving, and combined with door decay (#29) keeping a specific room locked down becomes increasingly challenging.
From a coding standpoint, much of this is easy to add. We already have heartbeats with the plant room lockout. Guests already have goal lists they execute, and which change with hunger. We're probably just adding a boolean to each room (is it a current goal) which gets cleared when it's completed. We can even have events which add rooms as goals, so players have to concentrate on more areas over time.
The lights above the door simply require a driver of some sort and some code to display the number of locks remaining.
It would be nice if current goals on the map were indicated visually somehow, perhaps by having an LED
breathing
by adjusting its PWM values over time. We'd need to test this with the current event loop to see if it looks good or if there's noticeable lag during heavy CPU usage (eg: pathfinding).The text was updated successfully, but these errors were encountered: