Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Guest goals and alternate gameplay #30

Open
pjf opened this issue Oct 9, 2016 · 0 comments
Open

Guest goals and alternate gameplay #30

pjf opened this issue Oct 9, 2016 · 0 comments

Comments

@pjf
Copy link
Member

pjf commented Oct 9, 2016

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant